Closed
Bug 832400
Opened 12 years ago
Closed 12 years ago
Downscaled image flickers
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
RESOLVED
FIXED
mozilla23
People
(Reporter: ttaubert, Assigned: joe)
References
()
Details
(Keywords: qawanted, regression)
Attachments
(2 files, 1 obsolete file)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
tnikkel
:
review+
|
Details | Diff | Splinter Review |
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•12 years ago
|
||
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
tracking-firefox19:
--- → ?
Keywords: regression
OS: Linux → All
Hardware: x86_64 → All
Version: Trunk → 19 Branch
Comment 2•12 years ago
|
||
Please re-nominate if this occurs for more than a single image. For now, this isn't a severe issue.
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•12 years ago
|
||
i have been been seeing some images that flicker on loading, though nothing like the continuous flicker of comment 0.
Comment 5•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
I should say this wasn't reproducing on FF20b6 - Mac OS X Mountain Lion
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.
Attachment #731259 -
Attachment mime type: text/plain → text/html
Assignee | ||
Comment 10•12 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: nobody → joe
Comment 13•12 years ago
|
||
I suspect bug 864233 is also a dupe of this.
Assignee | ||
Comment 14•12 years ago
|
||
Very possibly, though let's wait to hear back from the reporter on that.
Assignee | ||
Comment 15•12 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•12 years ago
|
Flags: needinfo?(ttaubert)
Flags: needinfo?(tnikkel)
Comment 16•12 years ago
|
||
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)
Reporter | ||
Comment 17•12 years ago
|
||
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 | ||
Comment 19•12 years ago
|
||
Timothy's suggestion was very, very helpful. This patch fixes this bug!
Attachment #741457 -
Flags: review?(tnikkel)
Comment 20•12 years ago
|
||
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•12 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!
Comment 22•12 years ago
|
||
(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•12 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.
Comment 24•12 years ago
|
||
(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•12 years ago
|
||
Sure, for now. :)
Assignee | ||
Comment 26•12 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 27•12 years ago
|
||
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+
Assignee | ||
Comment 28•12 years ago
|
||
Comment 29•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
You need to log in
before you can comment on or make changes to this bug.
Description
•