Downscaled image flickers

RESOLVED FIXED in mozilla23

Status

()

defect
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: ttaubert, Assigned: joe)

Tracking

({qawanted, regression})

19 Branch
mozilla23
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox19-, firefox20-, firefox21-, firefox22-)

Details

()

Attachments

(2 attachments, 1 obsolete attachment)

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.
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.
Blocks: 486918
Keywords: regression
OS: Linux → All
Hardware: x86_64 → All
Version: Trunk → 19 Branch
Please re-nominate if this occurs for more than a single image. For now, this isn't a severe issue.

Comment 3

6 years ago
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

6 years ago
i have been been seeing some images that flicker on loading, though nothing like the continuous flicker of comment 0.
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.
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.
I should say this wasn't reproducing on FF20b6 - Mac OS X Mountain Lion

Comment 8

6 years ago
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.

Updated

6 years ago
Attachment #731259 - Attachment mime type: text/plain → text/html

Comment 9

6 years ago
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.
Assignee

Comment 10

6 years ago
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).
Assignee

Updated

6 years ago
Duplicate of this bug: 857970
Assignee

Updated

6 years ago
Duplicate of this bug: 857473

Comment 13

6 years ago
I suspect bug 864233 is also a dupe of this.
Assignee

Comment 14

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

Comment 15

6 years ago
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.
Assignee

Updated

6 years ago
Flags: needinfo?(ttaubert)
Flags: needinfo?(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.
Flags: needinfo?(tnikkel)
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().
Flags: needinfo?(ttaubert)
Assignee

Updated

6 years ago
Duplicate of this bug: 864233
Assignee

Comment 19

6 years ago
Timothy's suggestion was very, very helpful. This patch fixes this bug!
Attachment #741457 - Flags: review?(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?
Assignee

Comment 21

6 years ago
(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!
(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?
Assignee

Comment 23

6 years ago
(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.
(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".
Assignee

Comment 25

6 years ago
Sure, for now. :)
Assignee

Comment 26

6 years ago
In addition to renaming this flag, this patch uses it for CSS images, which already had most of the plumbing done.
Attachment #741457 - Attachment is obsolete: true
Attachment #741457 - Flags: review?(tnikkel)
Attachment #742000 - Flags: review?(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.
Attachment #742000 - Flags: review?(tnikkel) → review+
https://hg.mozilla.org/mozilla-central/rev/2a4a6de0cd6b
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
You need to log in before you can comment on or make changes to this bug.