NEW 174459
[GTK] Several image related tests are timing out since r222264
https://bugs.webkit.org/show_bug.cgi?id=174459
Summary [GTK] Several image related tests are timing out since r222264
Miguel Gomez
Reported 2017-07-13 07:58:21 PDT
fast/images/async-image-background-image-repeated.html [ Timeout ] fast/images/async-image-background-image.html [ Timeout ] fast/images/async-image-body-background-image.html [ Timeout ] fast/images/sprite-sheet-image-draw.html [ Timeout ] fast/images/async-image-multiple-clients-repaint.html [ Timeout ] Except fast/images/async-image-multiple-clients-repaint.html, which was failing since r219364, all of these tests started to timeout since r219438.
Attachments
Said Abou-Hallawa
Comment 1 2017-07-13 09:08:00 PDT
This is happening because the WebView needs to send GraphicsLayerPaintFlags::AllowAsyncImageDecoding when painting the page if it is not printing or snapshotting. GTK needs to do something similar to what mac does in: Source/WebKit/mac/WebView/WebFrame.mm Source/WebKit2/Shared/mac/RemoteLayerBackingStore.mm
Michael Catanzaro
Comment 2 2017-07-13 10:32:30 PDT
Thanks Said. Miguel, is this something you could tackle?
Miguel Gomez
Comment 3 2017-07-13 12:19:35 PDT
(In reply to Michael Catanzaro from comment #2) > Thanks Said. > > Miguel, is this something you could tackle? I'll add it to my todo list.
Miguel Gomez
Comment 4 2017-07-13 12:22:03 PDT
(In reply to Said Abou-Hallawa from comment #1) > This is happening because the WebView needs to send > GraphicsLayerPaintFlags::AllowAsyncImageDecoding when painting the page if > it is not printing or snapshotting. GTK needs to do something similar to > what mac does in: > > Source/WebKit/mac/WebView/WebFrame.mm > Source/WebKit2/Shared/mac/RemoteLayerBackingStore.mm BTW, thanks for the tip Said :)
Michael Catanzaro
Comment 5 2017-07-20 08:47:30 PDT
(In reply to Miguel Gomez from comment #0) > fast/images/async-image-background-image-repeated.html [ Timeout ] > fast/images/async-image-background-image.html [ Timeout ] I've moved these timeout expectations elsewhere in the file, so be sure to remove them when this bug is closed.
Ms2ger (he/him; ⌚ UTC+1/+2)
Comment 6 2017-08-04 00:09:30 PDT
(In reply to Miguel Gomez from comment #0) > fast/images/async-image-multiple-clients-repaint.html [ Timeout ] I unmarked this in r220218; it seems to have stopped timing out in r219876.
Miguel Gomez
Comment 7 2017-08-09 03:09:42 PDT
I've been investigating the status of this at r220393. Specially since r219876, which changed the way to decide whether sync or async decoding is going to be performed. Now the timeouts are gone and the situation is: fast/images/async-image-background-image.html is now passing fast/images/async-image-multiple-clients-repaint.html is passing as well (as Ms2ger mentioned) and fast/images/async-image-background-image-repeated.html fast/images/async-image-body-background-image.html fast/images/sprite-sheet-image-draw.html are now failing with ImageOnlyFailure. This fail happens because these tests use an image with a size of 200x33100, which basically is too big to be rendered with cairo, so the result is an empty page. In order to fix these tests we need to use a smaller image. Said, is it a problem if I replace the image (sprite-sheet-red-green-blue.png) with a slightly smaller one? I think 200x30000 should be ok for us and it would still be large enough to be used for large image decoding tests. I'll update the affected tests as well, of course.
Ms2ger (he/him; ⌚ UTC+1/+2)
Comment 8 2017-08-14 02:45:53 PDT
*** Bug 171972 has been marked as a duplicate of this bug. ***
Miguel Gomez
Comment 9 2017-09-21 02:05:55 PDT
In r222264 we disabled the decoding for image bigger than 32768, as cairo won't be able to render them. This caused some tests to start timing out: fast/images/async-image-background-image-repeated.html [ Timeout ] fast/images/sprite-sheet-image-draw.html [ Timeout ] fast/images/async-image-body-background-image.html [ Timeout ] fast/images/async-image-multiple-clients-repaint.html [ Timeout ] I'm using this bug to track those as those tests are the ones that were handled by this bug already.
Note You need to log in before you can comment on or make changes to this bug.