34006 - Animating GIFs should use immediate redraw, not invalidate

Status: RESOLVED WONTFIX

(Core :: Layout, defect, P4)

Description

[Simon Fraser [no longer active]]

Currently, as we animate GIFs, we invalidate the frame, then wait for an update 
event from the OS (on Mac, at least) before we redraw the image with a new frame.

This is inefficient, and leads to irregular updates, and choppy animation, 
because there is an inevitable delay going through the OS for the update event. I 
think we should redraw animated GIFs directly.

Since the throbber is such a GIF and spins while the page is loading, this could 
be quite a performance win.

Comment 1

[dcone (gone)]

I think this is a design change.. and a viewmanager change.  I will give this to 
Kevin disposition. 

Comment 2

[Kevin McCluskey (gone)]

Moving to M18

Comment 3

[Kevin McCluskey (gone)]

This will not help unless the animation is set up to use a precise timer 
(NS_TYPE_REPEATING_PRECISE).  If a precise timer is not used, then all of the 
events in the message queue should be processed before the timer events.

For animated GIF's we can not use precise timers because they would fire at the 
expense of everything else including user interactions . (i.e it would take 
longer to load the page because the app is spending all of its time animating 
the GIF's.) 

Comment 4

[Kevin McCluskey (gone)]

This bug is marked "future" because it is not critical for RTM (Release To 
Manufacturing). If anyone believes it is critical, please explain why in
this bug. 

Comment 5

[Steve Dagley]

Is libpr0n going to help us with this?

Comment 6

[saari (gone)]

Well, the current libpr0n code does not use a percise timer, so we'll have the
same issue. Now that we don't redecode animation frames it may not be the end of
the world to make the timer percise, we're doing a lot less work now that we did
before.

That still leaves the issue of layout/view manager being able to just draw
without an invalidate. I don't know that view manager is currently smart enough
to deal with this in the case of things floating over an animation that
shouldn't be drawn over. Maybe it is, I don't know.

Comment 7

[Kevin McCluskey (gone)]

"That still leaves the issue of layout/view manager being able to just draw
without an invalidate. I don't know that view manager is currently smart enough
to deal with this in the case of things floating over an animation that
shouldn't be drawn over. Maybe it is, I don't know."

The view manager can be asked to draw without an invalidate by passing the flag
NS_VMREFRESH_IMMEDIATE to UpdateView. It will go through the same code that
happens if an invalidate is performed and it's corresponding paint is processed
later so there will not be a problem for things floating over the animation.

I have serious reservations about using the precise timers to control the
animation. On WIN32 at least, the precise timers will starve other events. If
you have a page with a large number of animated gif's we may end up animating
the "gif's" precisely at the expense of all other events. This could slow down
page loading and make Mozilla less interactive. Precise timers should only be
used for doing very quick operations. Calling UpdateView on the viewmanager
could be very expensive depending on the complexity of the page. It may need to
re-render a fairly substantial portion of the page if the animated gif's is
"layered" with other HTML elements.

Doing an immediate refresh without doing precise timer will not be helpful
either, since the timers which will cause the next frame to appear are not fired
unless other events have been processed.

Is this still a problem on the Mac? I don't see any problems on WIN32 and Linux.
 The Gif animations appear to constant frame rate once the page has loaded.  

Could there be a problem in our timer implementation on the Mac?

Comment 8

[basic]

timer code has changed I think, is this still an issue?

Comment 9

[Kevin McCluskey (gone)]

Build moving all existing future-P3 bugs to future-P4.

Comment 10

[Simon Paquet [:sipaq]]

This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Comment 11

[Simon Fraser [no longer active]]

No longer matters on OS X.