Support alpha on stroked paths
Categories
(Core :: Graphics: Canvas2D, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox116 | --- | fixed |
People
(Reporter: lsalzman, Assigned: lsalzman)
References
(Blocks 2 open bugs, Regressed 2 open bugs)
Details
(Whiteboard: [sp3])
Attachments
(2 files)
The AAStroke library can't probably deal overlap in the generated triangle meshes. This means every time a Canvas2D user tries to stroke a path, and they request alpha < 1, we fall back to software.
Assignee | ||
Comment 1•2 years ago
|
||
Since AAStroke can't deal with non-opaque stroked path, we first generate a normal opaque, anti-aliased
stroked path with AAStroke and render it to a cache texture bound to a render target. We can then later
just use that texture with alpha to support the initial alpha stroke request.
One caveat is that trying to both render to a texture bound to a framebuffer and also upload directly to
it with texSubImage2D can expose bugs in some OpenGL drivers that have different underlying representations
for data textures and for render target textures. To avoid this problem, we segregate the texture cache
pages based on whether they are used as render targets or for direct data uploads.
This ultimately all avoids the fallback of having to draw the alpha stroke in software with Skia and
then upload it to a texture. For stroked paths with large hollow areas, uploading a Skia surface whose
bounds contain the full stroke can cause a lot of uploading of unnecessary pixel data. This allows us
to only upload the triangle mesh for AAStroke and otherwise keep generation solely on the GPU.
Comment 3•2 years ago
|
||
bugherder |
Assignee | ||
Comment 4•2 years ago
|
||
Since we use unsynchronized BufferSubData, the wrong data can be used for some draw calls.
Ensure the path vertex offset is always advanced to avoid any races.
Comment 6•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Updated•2 years ago
|
Description
•