It's wasteful to call DrawTargetWebgl::BeginFrame if we're locking in a read-only mode. It may
also mess up DrawTargetWebgl's internal profiling if we count a read-only use as an actual frame.
Differential Revision: https://phabricator.services.mozilla.com/D197483
This patch makes CanvasDrawEventRecorder track what eventCount we
recorded an external surface reference. When the reader has increment
its processedCount above that, we will release our reference as it
should have acquired a strong reference to the data. This was previously
done when we forwarded the texture, but with remote textures, we no
longer have this event. Now we check when we start a new recording, or
attempt to clear cached resources.
Differential Revision: https://phabricator.services.mozilla.com/D197216
Chartjs heavily relies on circle drawing, which dispatches to the FillCircle and
StrokeCircle hooks in DrawTarget. These need to be implemented in DrawTargetWebgl.
Differential Revision: https://phabricator.services.mozilla.com/D194353
This adds the necessary infrastructure for CanvasTranslator to allocate DrawTargetWebgl
instead of just allocating TextureData, and to use RemoteTextureMap to handle sending
the DrawTargetWebgl frames to the compositor.
This optimizes snapshot transport to use fewer copies to and from shmems when we know
the snapshot contents can be sourced from a shmem.
This adds a blocking mechanism separate from deactivation so that existing DrawTargetWebgls
can continue processing events while denying further ones from being created in the event
that allocating further DrawTargetWebgls might cause problems, but so that we don't disrupt
canvases that are already in flight.
PersistentBufferProviderAccelerated still remains the buffer provider for the new setup,
but just allocates a single RecordedTextureData internally. Since DrawTargetWebgl already
does its own swap chain management internally, we do not want to use the multiple texture
client strategy that PersistentBufferProviderShared does.
This adds a fallback mechanism such that if DrawTargetWebgl allocation fails, a TextureData
is allocated instead that still sends results to RemoteTextureMap. This has the advantage
that we don't need to synchronously block in the content process to verify if acceleration
succeeded, as the costs of such blocking are rather extreme and we must still produce the
rendered frame to ensure the user sees the correct result if the speculative acceleration
failed. It then notifies the content process asynchronously via the refresh mechanism to
try to recreate a non-accelerated buffer provider when it is ready.
There is one additional hitch in RemoteTextureMap that we need to add a mechanism to deal
with the setup of the RemoteTextureOwner. When display list building initially needs to get
the remote texture, the RemoteTextureOwner might not exist yet. In this case, we need to add
a block to ensure we wait for that to occur so that we do not render an erroneous result.
Previously, this block was handled in ClientWebGLContext. Since that is no longer used,
the block must be reinstated somewhere else until a non-blocking mechanism for display list
building to proceed with a stub texture host wrapper can be implemented.
Currently this leaves the gfx.canvas.remote and gfx.canvas.accelerated prefs as separate
toggles rather than trying to lump everything into one mechanism. While this may be desirable
in the future, currently Direct2D remote canvas is a separate acceleration mechanism that
needs to co-exist with the WebGL acceleration, and so being able to toggle both on or off
for testing is desirable.
Differential Revision: https://phabricator.services.mozilla.com/D194352
This mostly restructures DrawTargetWebgl to no longer rely upon ClientWebGLContext.
Instead, it must directly interact with WebGLContext which requires some noisy changes
of the GL rendering API used.
In addition, this restructures SharedContextWebgl so that it can be explicitly
allocated and further DrawTargetWebgls can be allocated that feed off of it.
This is all towards the ultimate goal of relying on remote canvas infrastructure for
remoting instead.
Differential Revision: https://phabricator.services.mozilla.com/D194351
Chartjs heavily relies on circle drawing, which dispatches to the FillCircle and
StrokeCircle hooks in DrawTarget. These need to be implemented in DrawTargetWebgl.
Differential Revision: https://phabricator.services.mozilla.com/D194353
This mostly restructures DrawTargetWebgl to no longer rely upon ClientWebGLContext.
Instead, it must directly interact with WebGLContext which requires some noisy changes
of the GL rendering API used.
In addition, this restructures SharedContextWebgl so that it can be explicitly
allocated and further DrawTargetWebgls can be allocated that feed off of it.
This is all towards the ultimate goal of relying on remote canvas infrastructure for
remoting instead.
Differential Revision: https://phabricator.services.mozilla.com/D194351
Chartjs heavily relies on circle drawing, which dispatches to the FillCircle and
StrokeCircle hooks in DrawTarget. These need to be implemented in DrawTargetWebgl.
Differential Revision: https://phabricator.services.mozilla.com/D194353
This mostly restructures DrawTargetWebgl to no longer rely upon ClientWebGLContext.
Instead, it must directly interact with WebGLContext which requires some noisy changes
of the GL rendering API used.
In addition, this restructures SharedContextWebgl so that it can be explicitly
allocated and further DrawTargetWebgls can be allocated that feed off of it.
This is all towards the ultimate goal of relying on remote canvas infrastructure for
remoting instead.
Differential Revision: https://phabricator.services.mozilla.com/D194351
Calling ClientWebGLContext::UniformData() many times causes the
command buffer to fill up and we spend a fair amount of time flushing
the old buffer and allocating a new one, as well as serializing the
values.
The uniforms themselves are very small but they add up over a large
number of calls. We already have some code to track whether the
uniform values are dirty to avoid some redundancy, but a) this doesn't
cover every uniform, and b) we invalidate them all when switching
program.
This patch makes us track the value of every uniform that gets set
dynamically, and tracks the values separately for each program
used. It then uses these to avoid calling UniformData redundantly.
Differential Revision: https://phabricator.services.mozilla.com/D190269
This issue was originally reported by Asahi Lina, and they also proposed the original
version of these changes. I have reworked them a bit just to clean up how clip TCs
are passed down so that distance AA does not have to be highp.
Their original comment describing the issue were, in part:
"See DrawTargetWebgl::SharedContext::CreateShaders in dom/canvas/DrawTargetWebgl.cpp. The fragment shaders specify precision mediump float; and then don't use overriding precision qualifiers anywhere. This causes the texcoords to use fp16 precision on GPUs that support it, which is not sufficient for correct rendering."
"Note that this is a common mistake and the Mesa GPU driver we've been developing actually includes a heuristic that fixes the first instance of the problem (where the varying is used as a texcoord directly), but not the second one where there is an intermediate clamp(). It is that second one that is breaking Google Sheets."
Differential Revision: https://phabricator.services.mozilla.com/D187694
The clip mask state was leaking into the drawing of the stroke mask texture.
This caused the stroke mask to be erroneously clipped out.
Differential Revision: https://phabricator.services.mozilla.com/D187254
The clip mask state was leaking into the drawing of the stroke mask texture.
This caused the stroke mask to be erroneously clipped out.
Differential Revision: https://phabricator.services.mozilla.com/D187254
The clip mask state was leaking into the drawing of the stroke mask texture.
This caused the stroke mask to be erroneously clipped out.
Differential Revision: https://phabricator.services.mozilla.com/D187254
A lot of DrawTargetWebgl allocations cause a lot of WebGL framebuffer allocations.
The allocations could cause out of resource problems.
Differential Revision: https://phabricator.services.mozilla.com/D183108
Paths with the same shape but different locations can often hash to the same bucket.
Add a couple initial points from the path to the hash to distribute them better.
This results in a substantially improved hash distribution.
Differential Revision: https://phabricator.services.mozilla.com/D180849
For lines and rects, we don't have to worry about AARect generating overlapping
triangles when alpha is used. In these cases we can avoid drawing to a mask first
and avoid a performance cliff.
Differential Revision: https://phabricator.services.mozilla.com/D180525
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.
Differential Revision: https://phabricator.services.mozilla.com/D180436
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.
Differential Revision: https://phabricator.services.mozilla.com/D180143
We have a heuristic that falls back from stroking certain paths with acceleration because
both WGR and the texture cache can have slow output as the size of the path increases in
screen area. AA-Stroke tends to have better output for these paths, or at least, this heuristic
tends to have a detrimental effect on AA-Stroke usage and performance in important tests.
Lets move the heuristic to after we use AA-Stroke for now.
Differential Revision: https://phabricator.services.mozilla.com/D178549
We have a heuristic that falls back from stroking certain paths with acceleration because
both WGR and the texture cache can have slow output as the size of the path increases in
screen area. AA-Stroke tends to have better output for these paths, or at least, this heuristic
tends to have a detrimental effect on AA-Stroke usage and performance in important tests.
Lets move the heuristic to after we use AA-Stroke for now.
Differential Revision: https://phabricator.services.mozilla.com/D178549
We have a heuristic that falls back from stroking certain paths with acceleration because
both WGR and the texture cache can have slow output as the size of the path increases in
screen area. AA-Stroke tends to have better output for these paths, or at least, this heuristic
tends to have a detrimental effect on AA-Stroke usage and performance in important tests.
Lets move the heuristic to after we use AA-Stroke for now.
Differential Revision: https://phabricator.services.mozilla.com/D178549
For cases where bitmaps are compressed down to alpha textures, the underlying
assumption is that these were supposed to be treated as luminance data as well
in the shader, or rather, the alpha represents both the opacity and intensity.
We weren't properly swizzling in the shader to accomplish this. This fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D176986
It seems that using a texture as a backing surface for a framebuffer
while simultaneously trying to use TexSubImage to upload to it aggravates
OpenGL driver bugs regarding the underlying representation of that
texture.
Given that I couldn't find an expedient way to preserve that optimized
upload path, instead we have to fallback to just uploading the sampling
rect of the surface to a transient texture that is then drawn via shader
to framebuffer.
Differential Revision: https://phabricator.services.mozilla.com/D176240
This just tries to address fairly random changes in the Skia API and correct
our usage of it in Moz2D and some other places.
Differential Revision: https://phabricator.services.mozilla.com/D173324
This just tries to address fairly random changes in the Skia API and correct
our usage of it in Moz2D and some other places.
Differential Revision: https://phabricator.services.mozilla.com/D173324
This just tries to address fairly random changes in the Skia API and correct
our usage of it in Moz2D and some other places.
Differential Revision: https://phabricator.services.mozilla.com/D173324
DrawTargetWebgl renders a path by uploading vertex data to the back of
a large VBO using glBufferSubData then issuing a draw call, orphaning
the buffer when it becomes full. This results in many glBufferSubData
calls being interleaved with draw calls. On Mali GPUs this causes
severe performance issues as the driver is unable to determine that
any pending draw calls do not reference the updated region of the
buffer, and therefore must create a copy of the buffer for each
update.
However, since *we* know that we never overwrite a region that is
referenced by a submitted draw call, we can force the driver to avoid
making these copies. We do so by adding a new function
UnsynchronizedBufferSubData(), which acts like BufferSubData so long
as this rule is followed. Internally, this uses glMapBufferRange with
GL_MAP_UNSYNCHRONIZED_BIT, allowing the driver to omit the extraneous
copies.
Differential Revision: https://phabricator.services.mozilla.com/D174685
This implements OP_CLEAR by ensuring the shader always outputs a mask value that
represents coverage. Clear color is then blended in proportion to the coverage
value.
Depends on D171025
Differential Revision: https://phabricator.services.mozilla.com/D172956
