832400 - Downscaled image flickers

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Tim Taubert [:ttaubert] (inactive)]

Not sure what's really happening but I assume the issue is related to downscaling? If I view the given image in its own tab there is no flickering.

The flickering image is:
https://img.youtube.com/vi/hWhs2cIj7Cw/hqdefault.jpg

The web page where the flickering occurs:
https://www.khanacademy.org/math/linear-algebra

It's the image to the left of 'Vectors and spaces'. The other two images flicker a little but only once when loading the page.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Confirmed with 
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130119 Firefox/21.0 ID:20130119030922
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20130119 Firefox/20.0 ID:20130119042019
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 ID:20130116072953

WFM with
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 ID:20130116073211

Disabling HWA makes no Difference.
Setting image.high_quality_downscaling.enabled;false helps.

Comment 2

[Alex Keybl [:akeybl]]

Please re-nominate if this occurs for more than a single image. For now, this isn't a severe issue.

Comment 3

[Onno]

Also flickering with the car testcase:
https://bugzilla.mozilla.org/attachment.cgi?id=428179

However, flickering is only occuring once: the image seems to refresh (redrawn), even after it looks already fine.

Comment 4

[Mayank Bansal]

i have been been seeing some images that flicker on loading, though nothing like the continuous flicker of comment 0.

Comment 5

[Mats Palmgren (inactive)]

I've seen this problem on some web sites, most notably http://www.anandtech.com/ .
It occurs a few seconds after loading the page, which accentuates the problem
since I've already started reading the page at that point and the flicker draws
my attention to it.  It's 100% reproducible at that URL, using Shift+Reload,
or when switching between tabs.  (it might be easier to see the problem if you
use AdBlockPlus to make the page load faster and with fewer images)

Personally, I think image flickering is a worse problem than pixelation in the
image, at least on this page.

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

This isn't reproducing for me with that link from comment 3, adding qawanted to see if a wider range of images can be turned up that might give 100% reproducibility (or is this platform specific?).  Please renominate if this becomes something that might be affecting a wider range of users since at the moment it looks rather minor.

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

I should say this wasn't reproducing on FF20b6 - Mac OS X Mountain Lion

Comment 8

[mjh563]

Attachment: Testcase showing rendering issue on image resize

I've found another image where this is really noticeable. In the testcase, click the button to resize the image. Each time you do that, it's displayed at the new size and then re-rendered slightly differently a fraction of a second later.

It happens 100% of the time for me if I load the page and bypass the cache (Ctrl+F5), or if I switch to the tab. It doesn't happen reliably when I reload the page by pressing F5.

Tested in 20 beta and a recent nightly using Linux.

Comment 9

[mjh563]

By the way, the issue is not (as far as I can see) reproducible for me at the URLs given in comment 0 and comment 5. It is reproducible with the car testcase from comment 3 though.

Comment 10

[Joe Drew (not getting mail)]

FWIW this doesn't happen on OS X at all, mostly because high-quality downscaling isn't enabled there (and even if it was, it's hard to tell the difference between Quartz' high quality scaling and our own).

Comment 13

[mjh563]

I suspect bug 864233 is also a dupe of this.

Comment 14

[Joe Drew (not getting mail)]

Very possibly, though let's wait to hear back from the reporter on that.

Comment 15

[Joe Drew (not getting mail)]

This is caused by the thumbnailing service asking for the image to be painted at a different scale. Ideally we would totally ignore thumbnail-scaling paints w.r.t. high quality downscaling, but that turns out to be sort of difficult to do - we can figure out when we're painting to a window, but actually plumbing that data through to RasterImage::Draw() seems more difficult.

I'm open to suggestions from Timothy Nikkel or Tim Taubert, but in the mean time I think I'm going to work on supporting multiple high quality scaling requests (bug 795072), which would separately solve this problem by working around it.

Comment 16

[Timothy Nikkel (:tnikkel)]

We already have a similar flag that goes the same path you need (from display list builder to img lib Draw call): aBuilder->ShouldSyncDecodeImages(). So it shouldn't be too hard afterall.

Comment 17

[Tim Taubert [:ttaubert] (inactive)]

I don't know much about the internals of drawWindow(). The thumbnail service and a couple more components use it. It's also probably used by a lot of add-ons out there. I think we somehow need to fix this while still allowing to capture downscaled thumbnails with drawWindow().

Comment 19

[Joe Drew (not getting mail)]

Attachment: add imgIContainer::PAINTING_TO_WINDOW

Timothy's suggestion was very, very helpful. This patch fixes this bug!

Comment 20

[Timothy Nikkel (:tnikkel)]

Comment on attachment 741457 [details] [diff] [review]
add imgIContainer::PAINTING_TO_WINDOW

This will handle <img> and <xul:image> images but not other users of Draw(), like CSS images. Is that what we want?

Comment 21

[Joe Drew (not getting mail)]

(In reply to Timothy Nikkel (:tn) from comment #20)
> Comment on attachment 741457 [details] [diff] [review]
> add imgIContainer::PAINTING_TO_WINDOW
> 
> This will handle <img> and <xul:image> images but not other users of Draw(),
> like CSS images. Is that what we want?

Most others don't actually listen to invalidation AFAICT, so doing a high-quality downscale for them would be counterproductive. But if I'm wrong, I would love to know it!

Comment 22

[Timothy Nikkel (:tnikkel)]

(In reply to Joe Drew (:JOEDREW! \o/) from comment #21)
> (In reply to Timothy Nikkel (:tn) from comment #20)
> > Comment on attachment 741457 [details] [diff] [review]
> > add imgIContainer::PAINTING_TO_WINDOW
> > 
> > This will handle <img> and <xul:image> images but not other users of Draw(),
> > like CSS images. Is that what we want?
> 
> Most others don't actually listen to invalidation AFAICT, so doing a
> high-quality downscale for them would be counterproductive. But if I'm
> wrong, I would love to know it!

Oh, okay. So are we currently doing downscales for image consumers that don't listen for invalidation and are hence wasted effort then?

Comment 23

[Joe Drew (not getting mail)]

(In reply to Timothy Nikkel (:tn) from comment #22)
> Oh, okay. So are we currently doing downscales for image consumers that
> don't listen for invalidation and are hence wasted effort then?

Or entirely counterproductive, i.e. this bug.

Comment 24

[Timothy Nikkel (:tnikkel)]

(In reply to Joe Drew (:JOEDREW! \o/) from comment #23)
> (In reply to Timothy Nikkel (:tn) from comment #22)
> > Oh, okay. So are we currently doing downscales for image consumers that
> > don't listen for invalidation and are hence wasted effort then?
> 
> Or entirely counterproductive, i.e. this bug.

Oh right. In that case the name of the imgIContainer::PAINTING_TO_WINDOW flag is a lie, it's true meaning is "allow high quality downscales".

Comment 25

[Joe Drew (not getting mail)]

Sure, for now. :)

Comment 26

[Joe Drew (not getting mail)]

Attachment: add imgIContainer::HIGH_QUALITY_SCALING

In addition to renaming this flag, this patch uses it for CSS images, which already had most of the plumbing done.

Comment 27

[Timothy Nikkel (:tnikkel)]

Comment on attachment 742000 [details] [diff] [review]
add imgIContainer::HIGH_QUALITY_SCALING

The one type of images that this patch does not cover that I think might want high quality downscaling are svg images. But I think this patch is fine and can land, svg images can be done at a later time if the need arises.

Comment 28

[Joe Drew (not getting mail)]

 https://hg.mozilla.org/integration/mozilla-inbound/rev/2a4a6de0cd6b

Comment 29

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/2a4a6de0cd6b