Implement Global Paint Timer




9 years ago
5 months ago


(Reporter: BenWa, Unassigned)



Firefox Tracking Flags

(Not tracked)




9 years ago
A global paint timer is needed to replace individual nsITimer. 'nsPaintTimer' will allow observers to receive callbacks that can be used to invalidate frames for repainting.

This is primarily needed for the NPAPI CoreAnimation drawing model but will be general enough to facilitate other repainting.


9 years ago
Blocks: 497225
Depends on: 537339
How will this differ from the timers that drive nsRefreshDriver?
(In reply to comment #1)
> How will this differ from the timers that drive nsRefreshDriver?

Ideally they would be shared.
why don't we just use nsRefreshDriver?
One problem is that nsRefreshDriver is per-presshell and painting isn't really. Especially with bug 130078 fixed.
(In reply to comment #3)
> why don't we just use nsRefreshDriver?

Perhaps we should. nsRefershDriver doesn't currently have a way to schedule a paint in the future.

Comment 6

9 years ago
Perhaps I just extend nsRefreshDriver to provide this functionality instead of creating a new class.

So the thing is that we want refresh-driver stuff to be per-presshell, or at least per-tab.  In particular, we want to throttle reflows and restyles in background tabs....

For this global paint timer we need here, what would the API look like?  Who would start this timer?  When would it stop?

Comment 8

9 years ago
Well currently the primary use would be for invalidating the plugin's frame for a plugin using Core Animation. We're given by the renderer that the next frame should be rendered in X milliseconds.

The API should allow the plugins to register a callback in X milliseconds. All registered callback would be stored in a priority queue and only one timer would be used to service all callback requests. I will attach a suggested header before I begin implementing.
Do we intend to honor that X value even if the plugin is not in a currently-visible tab?

Comment 10

9 years ago
Yes, Joe had discuss that this could later be used for animating GIFs. The callback would still have to be honored to perform the necessary internal updates even if no actual painting will be performed.
Wait.  Why?  The whole point with animated gifs, I thought, was that the ones we don't need to paint we wouldn't update!
I'd prefer we continue updating animated gifs in the background, even if we don't paint it to the screen. But I could probably be convinced otherwise. (We can't do that for plugins, though, because for example videos need to keep playing in the background.)

One other issue, though, is that I understand the refresh driver requires a presshell, which I don't believe we have when we navigate directly to an image. That same issue will exist if we navigate directly to, say, an swf file.
We do have presshells in those situations. We wrap a fake document around the content.
> I'd prefer we continue updating animated gifs in the background

Why?  It's expensive, and if a gif is animating in a forest and no one is there to see it... why should it animate?

> We can't do that for plugins, though

Yeah, this is why we're still firing the plugin idle timers on Mac and not doing it from the refresh driver.  Though note that we throttle those for plugins that have a 0x0 cliprect...

So maybe my real problem here is not understanding exactly what you need out of this paint timer.  Is that explained somewhere?

And just to explain what I want out of all this:

1)  All painting/reflow/restyling for a given document should ideally come off
    the same notification.  Anything else breaks the batching we want to do and
    leads to extra complexity.  That's the world we're in now, and we've been
    trying to get away from it.
2)  If there's nothing that needs to be repainted in the future, we shouldn't
    have a timer firing (so e.g. running everything off a permanent always-on
    timer is not ok).
3)  Painting/reflow/restyling in background tabs needs to throttled.  The only
    caveat is that plug-in internal timelines need to update correctly and any
    audio that's playing needs to keep playing (sad, but that's where we are).

Comment 15

9 years ago
We will be using DisplayLink for Core Animation, see bug 552020. Joe do you still want this implemented?


9 years ago
No longer blocks: 497225

Comment 16

8 years ago
I'm closing this, I think it has been superseded by retain layers. Re-open it if I'm mistaken.


8 years ago
Last Resolved: 8 years ago
Resolution: --- → INVALID
AFAIK we still don't have something like this, and I believe it could be useful.
Resolution: INVALID → ---
Definitely. We need to bring all animation under the control of nsRefreshDriver or some derivative of it.


6 years ago
Last Resolved: 8 years ago6 years ago
Resolution: --- → WORKSFORME


5 months ago
Product: Core → Core Graveyard


5 months ago
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.