Bug 200577 – Problems playing animated images in Mac high-sierra

• Status: RESOLVED
• Resolution: INVALID
• Component: WebCore Misc.

[Carlos Alberto Lopez Perez]

When working on bug 74779 I discovered that all the test cases I wrote (I tested the cases in bug 200537 to not spam the other)  were failing on the EWS for Mac (which happens to run MacOS high-sierra), but this test cases are working fine on the  Mac machine I have access to (that runs on Mojave).

This tests also work fine on other ports (GTK and AppleWin).

So now I believe there is an issue in high-sierra that causes that playing animated images to be broken.

The issue I see is that the animated image doesn't play beyond the first 2 or 4 frames. It gets stuck playing.

I'm attaching a patch with  3 simple test cases that pass fine on Mojave and WebKitGTK and AppleWin, but will fail here on the EWS because it runs high-sierra.

I don't have the resources to investigate this, so I'm reporting this with the hope someone else can have a look.

[Carlos Alberto Lopez Perez]

Created attachment 375924 [details]
Patch

patch for testing. It includes 3 test cases that will fail on mac high-sierra but work on mojave or other ports

[Carlos Alberto Lopez Perez]

Created attachment 375925 [details]
Patch

same than above, just fix timeout value in a test

[EWS Watchlist]

Comment on attachment 375925 [details]
Patch

Attachment 375925 [details] did not pass mac-ews (mac):
Output: https://webkit-queues.webkit.org/results/12885592

New failing tests:
fast/images/draw-animated-image-simple-no-repeat.html
fast/images/count-animated-image-frames-simple-timer.html
fast/images/count-animated-image-frames-decode-and-webkitImageFrameReady.html

[EWS Watchlist]

Created attachment 375931 [details]
Archive of layout-test-results from ews103 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[Simon Fraser (smfr)]

This might be related to [window setAutodisplay:NO] in DumpRenderTree that will prevent the repaint-based advancement of animated images.

A hack would be to add a composited element on the page to turn autodisplay on.

[Carlos Alberto Lopez Perez]

(In reply to Simon Fraser (smfr) from comment #5)
> This might be related to [window setAutodisplay:NO] in DumpRenderTree that
> will prevent the repaint-based advancement of animated images.
> 
> A hack would be to add a composited element on the page to turn autodisplay
> on.

I had no idea this was a thing.

Let's try it.

[Carlos Alberto Lopez Perez]

Created attachment 375935 [details]
Patch

Add <div style="will-change: transform"> to the 3 tests

[Simon Fraser (smfr)]

We should really add testRunner.setWindowAutodisplay() or something.

[Carlos Alberto Lopez Perez]

(In reply to Carlos Alberto Lopez Perez from comment #6)
> (In reply to Simon Fraser (smfr) from comment #5)
> > This might be related to [window setAutodisplay:NO] in DumpRenderTree that
> > will prevent the repaint-based advancement of animated images.
> > 
> > A hack would be to add a composited element on the page to turn autodisplay
> > on.
> 
> I had no idea this was a thing.
> 
> Let's try it.

This fixed the issue I was having :)

What its the rationale for having a default of [window setAutodisplay:NO] in DRT? Just curious.

[Simon Fraser (smfr)]

(In reply to Carlos Alberto Lopez Perez from comment #9)
> (In reply to Carlos Alberto Lopez Perez from comment #6)
> > (In reply to Simon Fraser (smfr) from comment #5)
> > > This might be related to [window setAutodisplay:NO] in DumpRenderTree that
> > > will prevent the repaint-based advancement of animated images.
> > > 
> > > A hack would be to add a composited element on the page to turn autodisplay
> > > on.
> > 
> > I had no idea this was a thing.
> > 
> > Let's try it.
> 
> This fixed the issue I was having :)
> 
> What its the rationale for having a default of [window setAutodisplay:NO] in
> DRT? Just curious.

Historically, it increased performance, and made testing more predictable (you only paint when you explicitly ask for it).

[Carlos Alberto Lopez Perez]

(In reply to Simon Fraser (smfr) from comment #10)
> > What its the rationale for having a default of [window setAutodisplay:NO] in
> > DRT? Just curious.
> 
> Historically, it increased performance, and made testing more predictable
> (you only paint when you explicitly ask for it).

I see.

But I have to say that I find really confusing that a test can behave differently in WK2 and WK1 due to this setting.

Maybe the default should be the other way around, so only tests that really need this disabled have to manually opt-in.

In any case, I'm not going to argue/push about changing this as I'm not really interested into WebKit1 development.

I'm closing this as an invalid bug.

Thanks!