It looks like there was never a prototype for ImageBitmap's BindingJSObjectMallocBytes function.
Even though it was defined and expected to associate ImageBitmap's internally allocated surface
memory for the GC to track, the bindings generator never actually tried to call it because the
lack of the prototype caused the default non-specialized version of this function to be called
instead. With the protoype in place, this actually gets called and the GC is able to properly
clean out ImageBitmap's in a more timely fashion.
Differential Revision: https://phabricator.services.mozilla.com/D216250
Instead of holding SendShutdownToWorkerThread::mWorkerPrivate, hold WorkerPrivate::mControlEventTarget for SendShutdownToWorkerThread dispatching.
Depends on D213943
Differential Revision: https://phabricator.services.mozilla.com/D213944
Remove mWorkerPrivate from WorkerMainThreadRunnable. Instead, using a ThreadSafeWorkerRef to keep Worker alive until the created syncLoop is destroyed.
In general, WorkerMainThreadRunnable::mWorkerPrivate is only used for dispatching the MainThreadStopSyncLoopRunnable back to the Worker thread. Because of the syncLoop, the Worker is supposed to be kept alive until the created syncLoop is destroyed.
RefPtr<ThreadSafeWorkerRef> WorkerMainThreadRunnable::mWorkerRef is introduced to ensure a valid WorkerPrivate during WorkerMainThreadRunnable's execution.
WorkerMainThreadRunnable::mWorkerRef is allocated just before creating a syncLoop in WorkerMainThreadRunnable::Dispatch. And released after the created syncLoop::Run() finishes.
Depends on D212556
Differential Revision: https://phabricator.services.mozilla.com/D212557
Every use of ScaleDataSourceSurface checks for a null result and just spits out
a warning. So here it seems reasonable to check the input is valid, and if not,
just spit out that null result. This should give us more consistent behavior
between debug and opt builds.
Differential Revision: https://phabricator.services.mozilla.com/D212501
WorkerRunnable no longer keeps a raw pointer(mWorkerPrivate) for the associated WorkerPrivate in this patch.
Removing the WorkerRunnable::mWorkerPrivate needs to fix the following problems.
1. Thread assertions in WorkerRunnable::Dispatch()
To fix this problem, the associated WorkerPrivate is as a parameter and passed to WorkerRunnable::Dispatch() for the dispatching thread assertions. This associated WorkerPrivate is also propagated to PreDispatch() and PostDispatch() for the children classes of WorkerRunnable()
2. Get the associated WorkerPrivate in WorkerRunnable::Run() for environment setup(GlobabObject, JSContext setting for the runnable)
- For WorkerThreadRunnable
Since WorkerThreadRunnable is supposed to run on the worker thread, it does not need to keep a raw pointer to WorkerPrivate as its class member. GetCurrentThreadWorkerPrivate() should always get the correct WorkerPrivate for WorkerThreadRunnable.
- For WorkerParentThreadRunnable
WorkerParentRef is introduced to keep a RefPtr<WorkerPrivate> for WorkerParentThreadRunnable instead of using a raw pointer.
Checking the associated WorkerPrivate existence by WorkerParentRef at the beginning of WorkerParentThreadRunnable::Run(). If the Worker has already shut down, WorkerParentThreadRunnable cannot do anything with the associated WorkerPrivate, so WorkerParentThreadRunnable::Run() will return NS_OK directly but with a warning.
The associated WorkerPrivate is also passed into WorkerRun(), PreRun(), and PostRun(), so the majority of implementations of child classes of WorkerRunnable do not need to be changed.
If there are any cases in which the child classes of WorkerThreadRunnable/WorkerParentThreadRunnable want to keep the associated WorkerPrivate, they should use WorkerRefs instead of raw pointers.
Depends on D205679
Differential Revision: https://phabricator.services.mozilla.com/D207039
This is the first step in splitting the parent thread runnable out of WorkerRunnable.
To reuse the runnable dispatching codes in Worker, we still need a base class for runnable on the worker thread and the parent thread.
In this patch, we rename the original WorkerRunnable to WorkerThreadRunnable and make WorkerRunnable to be WorkerThreadRunnable's parent class.
In the second patch, we will create WorkerParentThreadRunnable and its sub-classes, split from WorkerThreadRunnable for runnable on the Worker's parent thread.
And in the third patch, we will re-structure the content of WorkerParentThreadRunnable to remove unnecessary members.
Differential Revision: https://phabricator.services.mozilla.com/D205178
In bug 1883435 comment 2 chutten mentions that including
nsGlobalWindowInner.h from GleanMetrics.h causes a stylo build failure.
This is because nsGlobalWindowInner.h itself brings a bunch of DOM
bindings template soup that bindgen isn't great at dealing with.
That can be fixed in various ways. However, there is a simpler fix,
which is not including GleanMetrics at all.
It's trivial to do, and given it's a massive autogenerated file, and
Document.h is a very common header, it's worth doing this if only for
build times.
Fix a bunch of unused includes while at it.
Differential Revision: https://phabricator.services.mozilla.com/D203625
CreateImageBigmapFromBlob is a behavior across the owning thread and the main thread. It starts from the owning thread, completes the IO on the main thread, and returns to the owning thread in the end.
However, when CreateImageBitmapFromBlob is in a nested worker, it uses CreateImageBitmapFromBlobRunnable to return to the owning thread. And It hits the assertion of WorkerRunnable::PreDispatch(), which supposes the runnable should be dispatched from its parent thread.
According to the design of CreateImageBigmapFromBlob, it should not be restricted by the assertion of WorkerRunnable::PreDispatch(), and it should always be dispatched back to the owning thread. Therefore, This patch overrides PreDispatch() and PostDispatch() of CreateImageBitmapFromBlobRunnable so that it can work correctly.
Differential Revision: https://phabricator.services.mozilla.com/D193553
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
