Bug 174459
| Summary: | [GTK] Several image related tests are timing out since r222264 | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Miguel Gomez <magomez> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | bugs-noreply, cgarcia, mcatanzaro, Ms2ger, sabouhallawa |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Miguel Gomez
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 | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Said Abou-Hallawa
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
Thanks Said.
Miguel, is this something you could tackle?
Miguel Gomez
(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
(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
(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)
(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
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)
*** Bug 171972 has been marked as a duplicate of this bug. ***
Miguel Gomez
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.