Bug 121244 - Image doesn't always repaint at high quality in all tiles after a live resize
Summary: Image doesn't always repaint at high quality in all tiles after a live resize
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Images (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Tim Horton
URL:
Keywords: InRadar
Depends on:
Blocks: 121207
  Show dependency treegraph
 
Reported: 2013-09-12 11:51 PDT by Tim Horton
Modified: 2013-09-12 17:41 PDT (History)
8 users (show)

See Also:


Attachments
repro (280.18 KB, text/html)
2013-09-12 11:51 PDT, Tim Horton
no flags Details
patch (2.08 KB, patch)
2013-09-12 11:58 PDT, Tim Horton
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Horton 2013-09-12 11:51:30 PDT
Created attachment 211454 [details]
repro

The easiest repro I have is:

With the attached file, in Safari (with tiled drawing on), make the window the minimum width and the height of your screen.
Rapidly resize the window from minimum width to the width of your screen, and let go.
You will likely see the image painted at low-quality (see screenshot) and it never recovers.
Refresh or force a repaint, and the image is painted at the correct (high) quality.

I have a fix.
Comment 1 Tim Horton 2013-09-12 11:55:14 PDT
The issue is that ImageQualityController removes the image from its low-quality-images list from shouldPaintAtLowQuality, if this is the first paint outside of a live resize, but does not force the image to repaint in its entirety. This is OK in some drawing models because it is unlikely that we are painting less than the whole image, but with tiled drawing we are frequently drawing just a portion of the image (or maybe into new tiles?); there's no guarantee we've invalidated the whole thing.

So, instead of removing the image from the list (and thus stopping the high-quality-repaint timer), let it get repaint()ed through the usual path instead of short-circuiting.

I have tried to make a test with no success.
Comment 2 Tim Horton 2013-09-12 11:58:59 PDT
Created attachment 211455 [details]
patch
Comment 3 Darin Adler 2013-09-12 12:35:30 PDT
Comment on attachment 211455 [details]
patch

Is there any way to keep this optimization for cases where sit is valid?
Comment 4 Tim Horton 2013-09-12 16:01:17 PDT
(In reply to comment #3)
> (From update of attachment 211455 [details])
> Is there any way to keep this optimization for cases where sit is valid?

Maybe? I need to know if the current repaint is going to repaint the whole renderer.
Comment 5 Tim Horton 2013-09-12 17:29:35 PDT
(In reply to comment #3)
> (From update of attachment 211455 [details])
> Is there any way to keep this optimization for cases where sit is valid?

In a very simplistic normal case, you won't repaint until the HQ paint timer fires, so you never even enter shouldPaintAtLowQuality at the problematic time (between the live resize finishing and the timer firing). Only if something else is dirtying the image (which, to perform this optimization, would have to dirty the entire image) - or in the tiled drawing case, painting into a freshly created tile - do we get here and even have the opportunity to do this optimization.

I don't think my somewhat messy attempt at reinstating this optimization in the few cases where it might help and not break anything is worth it at the moment (unless someone disagrees!), but I'll definitely file a bug.

Thanks, Darin!
Comment 6 Tim Horton 2013-09-12 17:32:24 PDT
http://trac.webkit.org/changeset/155664
Comment 7 Tim Horton 2013-09-12 17:34:36 PDT
Bug to reinstate it if someone decides that's a good idea is https://bugs.webkit.org/show_bug.cgi?id=121269
Comment 8 Radar WebKit Bug Importer 2013-09-12 17:41:54 PDT
<rdar://problem/14981492>