As per the spec, we should allow one to create ImageBitmaps, and call
CanvasRenderingContext2D's drawImage and createPattern using an
OffscreenCanvas.
Differential Revision: https://phabricator.services.mozilla.com/D133808
Note: if the original imageBitmap has been use for display, the source surface will have been cropped and
the original cropping IntRect has been lost, in this case use cropped mSurface instead of mdata.
If some of the new clip rect falls outside the source we have to crop the source if it hasn't been cropped.
Q: Should I attempt to get tests for this added to WPT?
Differential Revision: https://phabricator.services.mozilla.com/D124607
When an ImageBitmap needed to be cropped to prepare itself for a DT, it would
accidentally convert to the DT's format, which could cause issues if the DT
was opaque while the source surface was an alpha format.
Differential Revision: https://phabricator.services.mozilla.com/D132912
ImageBitmap::PrepareForDrawTarget overwrites its surface's contents when premultiplying the
data. This code pattern seems to stem all the way back to bug 1239752. It doesn't seem like
we have much control over where this surface comes from, and we have no strong guarantees
that this surface isn't shared by multiple consumers. As such, overwriting the data could
result in another consumer getting premultiplied data in the surface that it didn't expect.
We should just always be cloning the surface first before premultiplying unless we can
otherwise prove the surface isn't shared.
* * *
Bug 1739454 - Remove reftest-wait in reftest. r?emilio
Differential Revision: https://phabricator.services.mozilla.com/D131583
CLOSED TREE
Backed out changeset 3accfa522abb (bug 1739454)
Backed out changeset 18fdb7a13e63 (bug 1739454)
Backed out changeset 1de7d723923a (bug 1739454)
ImageBitmap::PrepareForDrawTarget overwrites its surface's contents when premultiplying the
data. This code pattern seems to stem all the way back to bug 1239752. It doesn't seem like
we have much control over where this surface comes from, and we have no strong guarantees
that this surface isn't shared by multiple consumers. As such, overwriting the data could
result in another consumer getting premultiplied data in the surface that it didn't expect.
We should just always be cloning the surface first before premultiplying unless we can
otherwise prove the surface isn't shared.
Differential Revision: https://phabricator.services.mozilla.com/D131583
See bug 1716641 comment 4 for a way this can happen.
I don't know what the best way to add a test for this is / whether it's
worth adding one?
Differential Revision: https://phabricator.services.mozilla.com/D118307
This allows it to be forward-declared (while a nested class cannot be),
such that headers files that use RectCallback by pointer or reference
do not need to include nsLayoutUtils.h.
This avoids including nsLayoutUtils.h in nsRange.h.
Differential Revision: https://phabricator.services.mozilla.com/D91685
Along with a dependent struct DirectDrawInfo.
This allows nsImageRenderer.h and CanvasRenderingContext2D.h to
avoid including nsLayoutUtils.h.
For nsImageRenderer.h in particular, a forward declaration is
not sufficient as nsImageRenderer stores SurfaceFromElementResult
by value.
A couple of method definitions elsewhere are moved out of line
to keep things compiling without including nsLayoutUtils.h in
additional headers.
Differential Revision: https://phabricator.services.mozilla.com/D91684
This change adds support for CanvasContext presenting WebGPU via CPU readback.
The presentation is handled mostly on GPU process side by managing a list of staging buffers
and copying the contents into a WR external image (backed by an external buffer).
Differential Revision: https://phabricator.services.mozilla.com/D68032
This change adds support for CanvasContext presenting WebGPU via CPU readback.
The presentation is handled mostly on GPU process side by managing a list of staging buffers
and copying the contents into a WR external image (backed by an external buffer).
Differential Revision: https://phabricator.services.mozilla.com/D68032
This change adds support for CanvasContext presenting WebGPU via CPU readback.
The presentation is handled mostly on GPU process side by managing a list of staging buffers
and copying the contents into a WR external image (backed by an external buffer).
Differential Revision: https://phabricator.services.mozilla.com/D68032
