Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
When ImageBitmap::PrepareForDrawTarget is called, we must ensure
that the surface returned is acceptable to the given DrawTarget. If
it is not, then we need to recreate the surface from mData. We must
also ensure similar when we are creating a new ImageBitmap from
another ImageBitmap, as we don't know in what context it may be
used.
Similarly, we need to ensure we produce DataSourceSurface compatible
surfaces when we need to both crop and premultiply.
Additionally, we now no longer clear mPictureRect or mAlphaType
when we set mSurface with the cached, cropped data. Since we may
need to clear the cached surface, we need to know the original crop
rect and alpha.
Differential Revision: https://phabricator.services.mozilla.com/D188056
XPCOMShutdownThreads is the phase just after XPCOMShutdown and XPCOMShutdown is when we destory the ImageBitmapShutdownObserver, so we need to not create a new ImageBitmapShutdownObserver if we are in XPCOMShutdown or later.
Differential Revision: https://phabricator.services.mozilla.com/D186852
In general the canvas size and the surface size should match. However if
we are in the process of updating an OffscreenCanvas's size, it is
possible we may return a surface with a different size if an ImageBitmap
is created, or we draw using, the placeholder HTMLCanvasElement. In that
case we should ensure the surface we yield is the same size as the
current intrinsic size of the HTMLCanvasElement.
Differential Revision: https://phabricator.services.mozilla.com/D186376
Use on shutdown observer and manager a hashtable of all imagebitmaps. Observers are managed using an array, which is slow for large numbers of observers.
Differential Revision: https://phabricator.services.mozilla.com/D181432
Use on shutdown observer and manager a hashtable of all imagebitmaps. Observers are managed using an array, which is slow for large numbers of observers.
Differential Revision: https://phabricator.services.mozilla.com/D181432
New flag added to nsLayoutUtils to ensure any exif specified orientation
is applied to surfaces obtained from HTMLImage elements irrespective of the
presence of the element in the DOM. For use in createImageBitmap where from-image is
the required behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D168356
Just need to pass the resizeWidth/Height down into SurfaceFromElement for html image elements so we can ask for a frame of the right size from the image.
We have to annotate the new test that I add as failing, just like all of the existing tests, because we don't yet support the resizeQuality option, so we fail that part of the test and pass all of the rest of it. The part that we are fixing here passes.
Differential Revision: https://phabricator.services.mozilla.com/D147739
Two issues:
The result of scaling & premultiply is order critical, the previous order for ImageData was scale > premultiply, the other image sources were premultiplied by default so didn't expose this issue. Reorder in the ImageData and common code paths (the original order followed the w3c spec order of operations - maybe the spec needs amending).
The ImageData path did not set the premultiplied flag of the resulting ImageBitmap correctly so the image would be premultiplied again in PrepareForDrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D139700
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
Emilio Cobos Álvarez
Peter Van der Beken
Andrew Osmond
Cosmin Sabou
Timothy Nikkel
Cristian Tuns
Noemi Erli
Angus Sawyer
Chun-Min Chang
Randell Jesup
Butkovits Atila
Lee Salzman
Alexandru Michis
Sylvestre Ledru
Steve Fink
Olli Pettay
Karl Tomlinson
Simon Giesecke