Bug 121244 – Image doesn't always repaint at high quality in all tiles after a live resize

• Component: Images
• Status: RESOLVED FIXED

[Tim Horton]

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.

[Tim Horton]

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.

[Tim Horton]

Created attachment 211455 [details]
patch

[Darin Adler]

Comment on attachment 211455 [details]
patch

Is there any way to keep this optimization for cases where sit is valid?

[Tim Horton]

(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.

[Tim Horton]

(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!

[Tim Horton]

http://trac.webkit.org/changeset/155664

[Tim Horton]

Bug to reinstate it if someone decides that's a good idea is https://bugs.webkit.org/show_bug.cgi?id=121269

[Radar WebKit Bug Importer]

<rdar://problem/14981492>