Closed Bug 1980264 Opened 10 months ago Closed 7 months ago

Canvas randomization is too slow

Categories

(Core :: Graphics: Canvas2D, enhancement)

enhancement

Tracking

()

RESOLVED FIXED
145 Branch
Tracking Status
firefox143 - ---
firefox145 --- fixed

People

(Reporter: tjr, Assigned: fkilic)

References

Details

Attachments

(7 files, 7 obsolete files)

48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review

In Bug 1980261 we profiled some private canvas rendering examples that were causing bad performance due to randomization. It's been a long-standing problem that we calculate the canvaskey over the entire image data, causing us to read all the image data multiple times - we can make this more efficient moving it later in the pipeline. We should to implement it under a separate RFPTarget (call it 'Efficient' or something) so we can pull the escape cord if we misjudged things.

Depends on: 1980594

The severity field is not set for this bug.
:lsalzman, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(lsalzman)

We are targeting next cycle for this.

Type: defect → enhancement
Flags: needinfo?(lsalzman)

The other place we return ImageExtraction::Randomize we have a
permission check - if you've granted the canvas permission
the result should not be randomized. It was missing in this
location though.

ImageExtractionResult can be one of three values, soon to be four,
so do not call its result 'spoofing' as that's too specific.

Image Encoders will be able to make use of a metadata
(aka randomization) key that will influence the resulting output
image.

This patch just adds that variable into all the API surfaces it
will need to be in to be accessible at the correct layer where
we will use it.

In the RFPService we expose functions that let us get the
Randomization Key for a context, and then later to take that
key and mix it with the existing image data hash.

At the hottest paths for image randomization, switch from using
the old randomization to the new, more efficient version.

As we read the resulting image, hash the bytes (eliminating the
need to read them twice), then modify the resulting image based
on the randomization key and the image hash.

These weren't breaking things before, but they were incorrect and now they broke things.

Attachment #9517599 - Attachment description: WIP: Bug 1980264: Plumb metatadata down to the Image Encoders → Bug 1980264: Plumb metatadata down to the Image Encoders
Attachment #9517601 - Attachment description: WIP: Bug 1980264: Wire up an alternate efficient randomization layer → Bug 1980264: Wire up an alternate efficient randomization layer
Attachment #9517603 - Attachment description: WIP: Bug 1980264: Implement a streaming randomization approach for PNG images → Bug 1980264: Implement a streaming randomization approach for PNG images

The other place we return ImageExtraction::Randomize we have a
permission check - if you've granted the canvas permission
the result should not be randomized. It was missing in this
location though.

ImageExtractionResult can be one of three values, soon to be four,
so do not call its result 'spoofing' as that's too specific.

Image Encoders will be able to make use of a metadata
(aka randomization) key that will influence the resulting output
image.

This patch just adds that variable into all the API surfaces it
will need to be in to be accessible at the correct layer where
we will use it.

In the RFPService we expose functions that let us get the
Randomization Key for a context, and then later to take that
key and mix it with the existing image data hash.

At the hottest paths for image randomization, switch from using
the old randomization to the new, more efficient version.

As we read the resulting image, hash the bytes (eliminating the
need to read them twice), then modify the resulting image based
on the randomization key and the image hash.

These weren't breaking things before, but they were incorrect and now they broke things.

Attached file Bug 1980264: Add a test r?timhuang (obsolete) —

Comment on attachment 9517827 [details]
Bug 1980264: Clang Formatting and a missing Permission Check r?timhuang

Revision D265364 was moved to bug 1980261. Setting attachment 9517827 [details] to obsolete.

Attachment #9517827 - Attachment is obsolete: true

Comment on attachment 9517828 [details]
Bug 1980264: Rename a variable to be more generic r?timhuang

Revision D265365 was moved to bug 1980261. Setting attachment 9517828 [details] to obsolete.

Attachment #9517828 - Attachment is obsolete: true

Comment on attachment 9517829 [details]
Bug 1980264: Plumb metatadata down to the Image Encoders

Revision D265366 was moved to bug 1980261. Setting attachment 9517829 [details] to obsolete.

Attachment #9517829 - Attachment is obsolete: true

Comment on attachment 9517830 [details]
Bug 1980264: Wire up an alternate efficient randomization layer

Revision D265367 was moved to bug 1980261. Setting attachment 9517830 [details] to obsolete.

Attachment #9517830 - Attachment is obsolete: true

Comment on attachment 9517831 [details]
Bug 1980264: Implement a streaming randomization approach for PNG images

Revision D265368 was moved to bug 1980261. Setting attachment 9517831 [details] to obsolete.

Attachment #9517831 - Attachment is obsolete: true

Comment on attachment 9517832 [details]
Bug 1980264: Test Infra Fixes r?timhuang

Revision D267088 was moved to bug 1980261. Setting attachment 9517832 [details] to obsolete.

Attachment #9517832 - Attachment is obsolete: true

Comment on attachment 9517833 [details]
Bug 1980264: Add a test r?timhuang

Revision D267271 was moved to bug 1980261. Setting attachment 9517833 [details] to obsolete.

Attachment #9517833 - Attachment is obsolete: true

Going to try and stick this - there were intermittent failures in try; but all of them worked on at least one run, and were completely unrelated tests so I think they're unrelated.

Backed out for causing xpcshell failures on test_encoder_png.js

Backout link

Push with failures

Failure log

Flags: needinfo?(mozbugzilla)
Regressions: 1992667
See Also: → 1992710
Blocks: fpp2
Blocks: 1993304
QA Whiteboard: [qa-triage-done-c146/b145]
Flags: needinfo?(mozbugzilla)
See Also: → 2022615
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: