The gfxPlatform::GetScreen* methods have always been redundant. Removing
them in favor of ScreenManager or nsDeviceContext methods will
discourage future code authors from adding more redundancy in
gfxPlatform.
Differential Revision: https://phabricator.services.mozilla.com/D203672
ImageBridgeChild::GetSingleton returns null in the GPU process. This causes
DrawTargetWebgl::CopyToSwapChain to use an incorrect texture type for WebGL
canvases when in the GPU process. To work around this, determine the texture
type for WebGL in the content process and send it to CanvasTranslator for
later usage.
Differential Revision: https://phabricator.services.mozilla.com/D202292
WGR is fairly slow at generating specialized circle geometry, whereas we can
generate similar geometry much faster using the AAStroke filled circle
implementation now.
Differential Revision: https://phabricator.services.mozilla.com/D201939
Currently BufferData when supplied null data, a pattern explicitly recommended in OpenGL for orphaning
buffer before they are subsequently filled with BufferSubData, currently causes zero data to be calloc'd
and uploaded to the buffer, which can be expensive.
In trusted code that only directly accesses WebGLContext, we can add an UninitializedBufferData_SizeOnly
call that can be used for this initialization, with the understanding that subsequent BufferSubData calls
will fill in relevant sections of the buffer before they are ever used.
Differential Revision: https://phabricator.services.mozilla.com/D201176
CopyToSwapChain was silently failing, causing no texture to get pushed
to RemoteTextureMap, so that when a wait on it was occurring, it would
timeout.
The failure occurred in DrawTargetWebgl::FlushFromSkia, because the
DT's size actually exceeded the value of the texture limit pref when
it was attempting to allocate a temporary texture to blend back a
Skia layer to the WebGL framebuffer. This is fixed by allowing layering
to bypass this limit, as it is always expected that layer blending
succeed.
To guard against future instances of this bug, CopyToSwapChain now returns
a boolean result so that it is fallible and can signal to CanvasTranslator
that it needs to take appropriate fallback measures on failure.
Differential Revision: https://phabricator.services.mozilla.com/D199794
Certain users of DrawTargetRecording need accurate tracking of SetPermitSubpixelAA.
This ensures the values are properly tracked locally in DrawTargetRecording as well
as forwards any necessary changes to the remote end.
Differential Revision: https://phabricator.services.mozilla.com/D198919
When a context loss occurs on DrawTargetWebgl, this may result in a fallback TextureData
being created. Each of these are currently managed by two different RemoteTextureOwnerClients.
This is not really safe at all.
To fix this, CopyToSwapChain is modified so that it can be supplied a RemoteTextureOwnerClient.
Then CanvasTranslator can inject its own RemoteTextureOwnerClient into CopyToSwapChain, rather
than letting CopyToSwapChain use its own separate internal RemoteTextureOwnerClient.
This also tries to address a few other data consistency bugs with the fallback TextureData.
Differential Revision: https://phabricator.services.mozilla.com/D198487
After a minimize, an unknown amount of time or circumstances may be involved that ultimately lead to
a GL context loss. To try to mitigate this, cache software snapshots of DrawTargetWebgls when we are
about to minimize so that these can hopefully be copied into fallback TextureDatas later if the context
is actually lost.
Differential Revision: https://phabricator.services.mozilla.com/D198129
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
