Closed
Bug 1143509
Opened 10 years ago
Closed 10 years ago
Unlock surfaces for downscale-during-decode before creating a new decoder
Categories
(Core :: Graphics: ImageLib, defect)
Core
Graphics: ImageLib
Tracking
()
RESOLVED
FIXED
mozilla39
Tracking | Status | |
---|---|---|
firefox39 | --- | fixed |
People
(Reporter: seth, Assigned: seth)
References
Details
Attachments
(1 file)
(deleted),
patch
|
dholbert
:
review+
|
Details | Diff | Splinter Review |
Originally the patch in bug 1122446, which made us unlock existing surfaces for a downscale-during-decode image when decoding, was written in the expectation that bug 1117607 would have already landed, making us allocate all frames of an image (even the first) asynchronously.
However, bug 1117607 did not end up landing. The result is that the behavior is different than expected: originally, the intention was that all versions of the image *except* the one we just started decoding would become unlocked. However, with things as they stand, all versions *including* the one we just started decoding are unlocked. That means that we can end up with images that are locked, but none of their surfaces are locked, and that's not great.
Fixing this is easy - we just need to move the UnlockSurfaces() call before we call CreateDecoder(), so that the new surface is allocated after UnlockSurfaces() gets called.
Updated•10 years ago
|
Attachment #8577797 -
Flags: review?(dholbert) → review+
Assignee | ||
Comment 2•10 years ago
|
||
Thanks for the review! Pushed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a86ab0a7bce7
Comment 3•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
status-firefox39:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in
before you can comment on or make changes to this bug.
Description
•