Bug 22995 – REGRESSION: radar loops don't animate

• Component: Images
• Status: RESOLVED FIXED

Bug #22108 was marked resolved related to the problem of radar loops not animating but it has never worked for me. The claim was it was fixed with version r39309 but I don't get any animations from this version or any subsequent versions.

Is there some additional work around that is needed?

[Alexey Proskuryakov]

Confirmed with r39437. On first load, there is no animation - and on a reload, animation seems to work, but a lot of errors are printed to console:

Fri Dec 26 12:27:17 ap-mbp.local Safari[31961] <Error>: CGImageSourceUpdateData image source was already finalized

No such problem on shipping Safari/WebKit, although the behavior is not very good either, with a lot of flashing.

[Robert Blaut]

*** Bug 21753 has been marked as a duplicate of this bug. ***

[Robert Blaut]

*** Bug 23000 has been marked as a duplicate of this bug. ***

[Robert Blaut]

*** Bug 22646 has been marked as a duplicate of this bug. ***

[Robert Blaut]

*** Bug 22366 has been marked as a duplicate of this bug. ***

[Peter Kasting]

The errors to console would be fixed by the patch on bug 22929.

I don't know why this isn't animating.  I am almost at the point of wanting Safari to just use the open source decoders instead of the CG ones since they're both more performant and less buggy :( (of course, they lack color profile handling, etc...)

Just downloaded and installed r39524. Went to weather.gov to try animating radar loops but no luck. On a whim, I control-clicked the image and choose the selection 'Inspect Element'.

The window that pops up shows html code and behind this I noticed that the radar loop had started animating. I closed the Inspect Element window and was able to turn the animation on and off with no problems. I was also able to reload the page and start the animation again. CPU usage was 1 to 5 %.

If I click on a different part of the map to try a different radar loop, some will work and some don't but they always start animating after I ctrl-click and select 'Inspect Element'.

Weird, huh?

[Jim Oase]

(In reply to comment #7)
> Just downloaded and installed r39524. Went to weather.gov to try animating
> radar loops but no luck. On a whim, I control-clicked the image and choose the
> selection 'Inspect Element'.
> 
> The window that pops up shows html code and behind this I noticed that the
> radar loop had started animating. I closed the Inspect Element window and was
> able to turn the animation on and off with no problems. I was also able to
> reload the page and start the animation again. CPU usage was 1 to 5 %.
> 
> If I click on a different part of the map to try a different radar loop, some
> will work and some don't but they always start animating after I ctrl-click and
> select 'Inspect Element'.
> 
> Weird, huh?
> 
I duplicated this operation the first couple times I tried it (using the same build as above), then the could not get animation again.  I have just loaded  WebKit-SVN-r39553 and still can not get animation to function even using the above technique.  

Maybe this site doesn't like me.

[Jim Oase]

(In reply to comment #7)
> Just downloaded and installed r39524. Went to weather.gov to try animating
> radar loops but no luck. On a whim, I control-clicked the image and choose the
> selection 'Inspect Element'.
> 
> The window that pops up shows html code and behind this I noticed that the
> radar loop had started animating. I closed the Inspect Element window and was
> able to turn the animation on and off with no problems. I was also able to
> reload the page and start the animation again. CPU usage was 1 to 5 %.
> 
> If I click on a different part of the map to try a different radar loop, some
> will work and some don't but they always start animating after I ctrl-click and
> select 'Inspect Element'.
> 
> Weird, huh?
> 

I reported earlier that I tried the above and the first couple of times it animation started just as reported above.  Then i could not get it to work again, even after load the latest build.

This afternoon I tried it again.  This time I clicked on the xxxx.gif and waited.  Animation finally began.

I am going with "Weird, huh?"

[Peter Kasting]

Has the fix for bug 23082 fixed this as well?

[Robert Blaut]

(In reply to comment #10)
> Has the fix for bug 23082 fixed this as well?
> 

No, it doesn't work for me in WebKit r39572 on Mac OS X.

[Jim Oase]

The bug still exists as of  WebKit-SVN-r39572 

Animation can be made operate most of the time using the instructions in comment #7, right click on the map, click inspect element, wait, click on the highlighted line, wait some more and most times the animation will begin to work.

I still haven't found the magic sequence that makes animation work immediately.

Jim

[Jim Oase]

Radar loop animation still does not work with build WebKit-SVN-r39671

Animation can be made to work using the Inspect Element scheme [e-mail] discovered... listed in the comment section.

When animation is working, using the inspect elements scheme, scrolling becomes erratic when using the scroll ball on my super mouse.

Scrolling has been a problem and been fixed with this site before.

Jim

[Simon Fraser (smfr)]

I think I see the issue. You get into a state where you've got frame 0, and are waiting until frame 1 is decoded. frameIsCompleteAtIndex(1) has been called before the frame is ready, so frame 1 has m_frame == 0, but m_haveMetadata == true.

Now you keep calling frameIsCompleteAtIndex(1) over and over via startAnimation(). frameIsCompleteAtIndex() never calls cacheFrame again, because m_haveMetadata is true, so it does nothing (and m_isComplete stays at false). So you never make progress.

Someone needs to call cacheFrame() if m_frame is still 0. Something like this:

diff --git a/WebCore/WebCore.xcodeproj/project.pbxproj b/WebCore/WebCore.xcodeproj/project.pbxproj
diff --git a/WebCore/platform/graphics/BitmapImage.cpp b/WebCore/platform/graphics/BitmapImage.cpp
index 779787e..2eed9c6 100644
--- a/WebCore/platform/graphics/BitmapImage.cpp
+++ b/WebCore/platform/graphics/BitmapImage.cpp
@@ -287,6 +287,8 @@ void BitmapImage::startAnimation(bool catchUpIfNecessary)
 
     // Don't advance the animation to an incomplete frame.
     size_t nextFrame = (m_currentFrame + 1) % frameCount();
+    // Update the state of the frame by asking for it
+    (void)frameAtIndex(nextFrame);
     if (!frameIsCompleteAtIndex(nextFrame))
         return;
 

[Simon Fraser (smfr)]

Also, how can you trust the frame duration, alpha and size in BitmapImage::cacheFrame() if you don't have a frame yet? Seems like this method is over-zealous in thinking that it has valid metadata.

[Simon Fraser (smfr)]

Here's a good test URL for animated GIFs:
http://www.neogaf.com/forum/showthread.php?t=294041

[Peter Kasting]

Created attachment 26552 [details]
patch v1

This isn't tested, but if smfr is correct about the cause of the flakiness (and it certainly looks like a problem to me too), this should fix it, and in a more robust way than the proposed workaround of forcing the frame to re-cache in startAnimation().

This clears the frame's metadata if we get more data for it.  This should match fairly well with when the metadata _can_ actually change (it's just slightly aggressive in clearing the metadata, but not in a way that will have any real effect).

[Dave Hyatt]

Comment on attachment 26552 [details]
patch v1

r=me

[Peter Kasting]

Fixed, I hope, in r39751.

[Robert Blaut]

*** Bug 23224 has been marked as a duplicate of this bug. ***

I just installed r39790. Radar loops work for me!

[Jim Oase]

The radar animation loop works.....But....... now initial scrolling with a super mouse ball is delayed and jerky.     ARGH!!!

Takes a bite for animation to start.
After animation starts slowly scroll continuously east.
The picture will not move at first... then jerk to the correct location and in that axis work smoothly from then on.
Change axis to north/south and repeat the scroll process.
Again the picture will not move at first then jerk to the correct location

[Simon Fraser (smfr)]

Jim: please file a new bug on the performance problem, and, if you can, try to identify the nightly build where it first occurred.