Use of async and sync image decodes can cause duplicates in the SurfaceCache
Categories
(Core :: Graphics: ImageLib, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox103 | --- | fixed |
People
(Reporter: aosmond, Assigned: aosmond)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
We may trigger an async decode for a raster image through the prediction logic:
And then we may trigger a sync decode due to the decoding
attribute on the image.
If the async decode hasn't produce any frame data yet, then we will enter the if block and request another frame to be decoded:
We should do better here. Perhaps if we could create the first frame's imgFrame immediately when the Decoder is initialized for non-metadata decodes? We should know what size we need. That would allow us to avoid the case where there is no frame data, and then we can't block on:
We should also consider returning TEMPORARY_ERROR or NOT_READY if we try to sync decode and we have yet to load all the data from the network. This would ensure sync decodes either return an error or return all of the pixel data.
Assignee | ||
Comment 1•2 years ago
|
||
This can also impact CI which uses sync decoding.
Assignee | ||
Comment 2•2 years ago
|
||
If we do trigger a sync decode, but we don't have all the source data, we don't enter the if block for the sync path:
And trigger another async path. That can exacerbate the issues mentioned in the original description, as we would not have triggered a new async decode if the sync decode was not set, but do if it is.
Assignee | ||
Comment 3•2 years ago
|
||
When we request a sync decode, there is an outstanding pending async
decode, but we don't have all the network data, we would end up
triggering an extra async decode. This patch ensures that we only
trigger sync decodes if they will actually execute as async.
Comment 5•2 years ago
|
||
bugherder |
Description
•