Some paths may contain so many types that their vertex representation far exceeds their
software rasterized representation in memory size. As a sanity-check, we should just set
a hard limit on the maximum allowed complexity of a path that we attempt to supply to
wpf-gpu-raster. Beyond that, we will instead just rasterize in software and upload
to a texture which can be more performant.
Differential Revision: https://phabricator.services.mozilla.com/D162481
By default, BorrowSnapshot is pessimistic and forces DrawTargetWebgl to return a data snapshot on
the assumption that the snapshot might be used off thread. However, if we actually know the DrawTarget
we're going to be drawing the snapshot to, then we can check if they're both DrawTargetWebgls with
the same internal SharedContext. In that case, we can use a SourceSurfaceWebgl snapshot which can
pass through a GPU texture to the target. This requires us to plumb the DrawTarget down through
SurfaceFromElement all the way to DrawTargetWebgl to make this decision.
Differential Revision: https://phabricator.services.mozilla.com/D162176
We have only one path cache shared among all DrawTargetWebgl's, so it can get
bogged down with entries very quickly and needs to have a quite large number
of buckets to compensate.
Differential Revision: https://phabricator.services.mozilla.com/D161956
This adds a path vertex buffer where triangle list output from WGR is stored.
Each PathCacheEntry can potentially reference a range of vertexes in this buffer
corresponding to triangles for that entry. When this buffer is full, it gets
orphaned and clears corresponding cache entries, so that it can start anew.
Differential Revision: https://phabricator.services.mozilla.com/D161479
This adds a path vertex buffer where triangle list output from WGR is stored.
Each PathCacheEntry can potentially reference a range of vertexes in this buffer
corresponding to triangles for that entry. When this buffer is full, it gets
orphaned and clears corresponding cache entries, so that it can start anew.
Differential Revision: https://phabricator.services.mozilla.com/D161479
Some canvas users attempt to set .width=.width to have the canvas reset as a
side-effect. When this happens, we throw out the buffer provider on reset. However,
this makes it impossible to do any sort of profiling for accelerated canvas inside
the buffer provider since its state is continually reset every frame in these
sorts of use-cases.
To work around this, we make our best attempt to keep the buffer provider around
so long as the size remains the same. The only caveat is that we still need to
keep the side-effect of clearing the buffer when this happens so that the
behavior is similar regardless.
Differential Revision: https://phabricator.services.mozilla.com/D161615
GPUVideoTextureClient of SurfaceDescriptorD3D10 needs to be kept alive until WebGLParent::RecvTexImage() is handled by parent side.
Confirmed that test_conformance__textures__misc__texture-npot-video.html test failure was addressed.
Differential Revision: https://phabricator.services.mozilla.com/D161015
FontFaceSetWorkerImpl::GetURLExtraData should generally not return a
null pointer, but if it failed to initialize because the worker was
shutdown during FontFaceSetWorkerImpl initialization, then it may never
be created. This patch ensures we check for this race and handle it
appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D161476
There was still a timing that hit the assert. When ClientWebGLContext::Event_webglcontextrestored() was called just before ClientWebGLContext::UpdateWebRenderCanvasData() the assert was failed.
Differential Revision: https://phabricator.services.mozilla.com/D161243
Per offline discussion with Kesley, we decided to disable seamless
looping for these tests first, and then spend time to figure the gfx
side crash due to not be able to manage texture's lifetime correctly.
For reference, the failed test is
`test_conformance__textures__misc__texture-corner-case-videos.html`.
Differential Revision: https://phabricator.services.mozilla.com/D160701
[Int]CoordTyped no longer inherits Units because otherwise
instances of [Int]IntPointTyped may get one Base subobject because
it inherits Units, and others because of BasePoint's Coord members,
which end up increasing the [Int]CoordTyped's objects size (since
according to the ISO C++ standard, different Base subobject are
required to have different addresses).
Differential Revision: https://phabricator.services.mozilla.com/D160713
Originally, we special-cased shmems to try to send them directly
without a copy.
Unfortunately, ipc::Shmem doesn't support that, so we
allocated a new shmem on PWebGL and sent that.
However, we didn't include shmem-cleanup steps in RecvTexImage, so we
leaked the shmem.
We would be tempted to check inside the Desc in RecvTexImage and cleanup that
shmem, *however* RawTexImage from dtwebgl also uses this path, and its shmems
are UnsafeShmems, which are *not* supposed to be cleaned up.
Rather than adding e.g. a bool to differentiate them, let's just explicitly do
the cleanup in the caller that knows it needs to clean up.
One pattern I want to use more often for cross-process lifetimes is:
```
foo = new RefcountedResource();
SendUseAsync(foo);
SendPing()->Then([foo]() {});
```
By the time we the promise from SendPing is resolved, we know the remote side is
done with `foo`, and so our trivial capturing lambda will take care of releasing
it on the Send side. It's straightforward and safe, and the lifetimes have one
extra return-trip of latency, but that's almost always fine.
Differential Revision: https://phabricator.services.mozilla.com/D160996
C++20 deprecates some operations between enums and floating point types:
https://clang.llvm.org/docs/DiagnosticsReference.html#wenum-float-conversion
dom/canvas/CanvasRenderingContext2D.cpp:4743:58 [-Wenum-float-conversion] arithmetic between enumeration type 'VideoInfo::Rotation' and floating-point type 'double'
dom/events/EventStateManager.cpp:6656:35 [-Wenum-float-conversion] comparison of floating-point type 'double' with enumeration type 'mozilla::EventStateManager::(unnamed enum at dom/events/EventStateManager.h:342:3)'
dom/events/EventStateManager.cpp:6664:35 [-Wenum-float-conversion] comparison of floating-point type 'double' with enumeration type 'mozilla::EventStateManager::(unnamed enum at dom/events/EventStateManager.h:342:3)'
gfx/thebes/gfxTextRun.cpp:2992:24 [-Wenum-float-conversion] comparison of floating-point type 'gfxFloat' (aka 'double') with enumeration type 'gfxFontGroup::(unnamed enum at gfx/thebes/gfxTextRun.h:1035:3)'
layout/generic/nsVideoFrame.cpp:59:58 [-Wenum-float-conversion] arithmetic between enumeration type 'VideoInfo::Rotation' and floating-point type 'double'
layout/painting/nsCSSRenderingBorders.cpp:2752:27 [-Wenum-float-conversion] arithmetic between enumeration type 'mozilla::Corner' and floating-point type 'double'
Differential Revision: https://phabricator.services.mozilla.com/D158867
The UniformData call accepts a Range<uint8_t>. When serialized by ClientWebGLContext,
however, the data is only serialized to the alignment of the supplied uint8_t type.
The HostWebGLContext may then alias it to a Range<uint32_t> or similar, while the data
was only aligned to 1-byte alignment. On some platforms such as ARM, these unaligned
accesses can cause a SIGBUS.
As a temporary workaround, we will now pessimistically align such ranges as if they
might be accessed as any possible data type with kUniversalAlignment.
Differential Revision: https://phabricator.services.mozilla.com/D160289
The UniformData call accepts a Range<uint8_t>. When serialized by ClientWebGLContext,
however, the data is only serialized to the alignment of the supplied uint8_t type.
The HostWebGLContext may then alias it to a Range<uint32_t> or similar, while the data
was only aligned to 1-byte alignment. On some platforms such as ARM, these unaligned
accesses can cause a SIGBUS.
As a temporary workaround, we will now pessimistically align such ranges as if they
might be accessed as any possible data type with kUniversalAlignment.
Differential Revision: https://phabricator.services.mozilla.com/D160289
If we have stroked paths whose bounds cover a lot of screen area, that can lead
to a lot of empty area in the interior that bloats the path cache textures up
with unused pixels that still need to be uploaded. Try to avoid this by not
trying to accelerate paths with the path cache that take up a large amount
of screen area.
Differential Revision: https://phabricator.services.mozilla.com/D160023
