Background browser media updates are excessive

[cosmic-linden]

Split from #5672 as this seems likely unrelated to the FPS spikes I'm seeing.

doMediaTexUpdate is called with unexpected frequency for preloaded browser floaters that have never been opened. Ideally, this should not be called at all unless the webpage is visible or preloading. Furthermore, LLPluginClassMedia::receivePluginMessage is called even more frequently, which suggests that the plugin is updating graphically at an even faster rate.

---

This repo is using Opire - what does it mean? 👇

💵 Everyone can add rewards for this issue commenting /reward 100 (replace 100 with the amount).
🕵️‍♂️ If someone starts working on this issue to earn the rewards, they can comment /try to let everyone know!
🙌 And when they open the PR, they can comment /claim #5702 either in the PR description or in a PR's comment.

🪙 Also, everyone can tip any user commenting /tip 20 @cosmic-linden (replace 20 with the amount, and @cosmic-linden with the user to tip).

📖 If you want to learn more, check out our documentation.

[cosmic-linden]

Plot twist: It's not the plugin idle loop that's causing spurious update messages. mCEFLib->update() (i.e. CefDoMessageLoopWork()) gets called once per frame, with appropriate timing. So, for some reason the viewer is receiving redundant messages for the rect update event message. Maybe other messages are affected. This may be less of an indicator of excess browser work in the plugin, but still has downstream effects on viewer work due to handling of the updates.

[cosmic-linden]

Huh, dullahan does memcpy of full browser window regardless of dirty rect info, multiple times a frame. The multiple updates are coming directly from CEF, but hard to say for now if that's due to CEF doing multiple full update cycles, or just breaking up the paint into multiple pieces. I wonder if this overhead is variable depending on the web content.

We can, at minimum, coalesce into a single rect update message being sent up to the viewer. This doesn't fully address the weirdness on the dullahan/CEF side, but would likely be pretty safe.

[cosmic-linden]

This is starting to sound related to #5597 , so I'm going to look at that to see if anything has changed there which could impact this optimization path.

[cosmic-linden]

Roxie's PR #5597 uses onAcceleratedPageChangedCallback, which appears to be an alternative code path, so it would need to be vetted separately.

[cosmic-linden]

Marking as closed because, aside from the priority fix which has already been merged, most of my investigation is likely irrelevant in light of upcoming CEF updates.