549980 - Implement Global Paint Timer

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Benoit Girard (:BenWa)]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

How will this differ from the timers that drive nsRefreshDriver?

Comment 2

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #1)
> How will this differ from the timers that drive nsRefreshDriver?

Ideally they would be shared.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

why don't we just use nsRefreshDriver?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

One problem is that nsRefreshDriver is per-presshell and painting isn't really. Especially with bug 130078 fixed.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

(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

[Benoit Girard (:BenWa)]

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

Comment 7

[Boris Zbarsky [:bzbarsky]]

Hmm.

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

[Benoit Girard (:BenWa)]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Do we intend to honor that X value even if the plugin is not in a currently-visible tab?

Comment 10

[Benoit Girard (:BenWa)]

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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Wait.  Why?  The whole point with animated gifs, I thought, was that the ones we don't need to paint we wouldn't update!

Comment 12

[Joe Drew (not getting mail)]

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.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We do have presshells in those situations. We wrap a fake document around the content.

Comment 14

[Boris Zbarsky [:bzbarsky]]

> 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

[Benoit Girard (:BenWa)]

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

Comment 16

[Benoit Girard (:BenWa)]

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

Comment 17

[Jeff Muizelaar [:jrmuizel]]

AFAIK we still don't have something like this, and I believe it could be useful.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Definitely. We need to bring all animation under the control of nsRefreshDriver or some derivative of it.