Closed
Bug 1238337
Opened 8 years ago
Closed 8 years ago
don't do a predictive image decode if the predicted size is likely to be wrong
Categories
(Core :: Layout: Images, Video, and HTML Frames, defect)
Core
Layout: Images, Video, and HTML Frames
Tracking
()
RESOLVED
FIXED
mozilla47
Tracking | Status | |
---|---|---|
firefox47 | --- | fixed |
People
(Reporter: tnikkel, Assigned: tnikkel)
References
Details
Attachments
(1 file, 1 obsolete file)
2.62 KB,
patch
|
seth
:
review+
MatsPalmgren_bugz
:
review+
|
Details | Diff | Splinter Review |
Observed this while debugging something else. nsImageFrame::ComputeSize calls EnsureIntrinsicSizeAndRatio, there's no mImage yet, so it gives the intrinsic size the size of the icon it would draw. And then if we don't have a css specified size we reflow at that size and request a decode at that size.
Assignee | ||
Comment 1•8 years ago
|
||
Attachment #8706074 -
Flags: review?(seth)
Assignee | ||
Comment 2•8 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #0) > nsImageFrame::ComputeSize calls EnsureIntrinsicSizeAndRatio, there's no > mImage yet, so it gives the intrinsic size the size of the icon it would > draw. And then if we don't have a css specified size we reflow at that size > and request a decode at that size. Actually, that's not the problem. The useless decode request was coming via OnLoadComplete->NotifyNewCurrentRequest. We would first get OnSizeAvailable called, this would request a reflow because we got a new intrinsic ration. Then OnLoadComplete would be called, and it would (wrongly) do a predictive decode because the intrinsic size hadn't changed. This is a bug in bug 1151359. The first patch fixed the problem because both things in the previous paragraph happened between the reflow at the initial ("wrong") size, and the reflow at the final size.
Blocks: 1151359
Assignee | ||
Comment 3•8 years ago
|
||
Attachment #8706074 -
Attachment is obsolete: true
Attachment #8706074 -
Flags: review?(seth)
Attachment #8706075 -
Flags: review?(seth)
Assignee | ||
Comment 4•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=cc96e1114d36
Assignee | ||
Comment 5•8 years ago
|
||
Comment on attachment 8706075 [details] [diff] [review] patch Mats, do you think you could review? Feel free to decline.
Attachment #8706075 -
Flags: review?(mats)
Comment 6•8 years ago
|
||
Comment on attachment 8706075 [details] [diff] [review] patch Looks reasonable to me, although I'm only vaguely familiar with this code. One observation though, most of the code in this method is looks identical to the code in OnSizeAvailable. Did you intentionally not update that method?
Attachment #8706075 -
Flags: review?(mats) → review+
Assignee | ||
Comment 7•8 years ago
|
||
Yeah, the code in OnSizeAvailable is very similar, but slightly different. OnSizeAvailable doesn't have the InvalidateFrame() call so the structure would be slightly different. Since there are a lot of subtleties in this code I wanted to keep this fix focused.
Comment 9•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/b6ae2095c564
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox47:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Comment 10•8 years ago
|
||
Comment on attachment 8706075 [details] [diff] [review] patch Review of attachment 8706075 [details] [diff] [review]: ----------------------------------------------------------------- r+ FWIW.
Attachment #8706075 -
Flags: review?(seth) → review+
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•