When drawing arcs or similar constructs that may have a path transform to implement
scaling, this scaling may inadvertently alter stroke options such as line width or
dashes. We need to ensure that we don't apply this scaling from the path transform
to stroke options.
Differential Revision: https://phabricator.services.mozilla.com/D232579
The Windows Intel D3D driver does not seem to be recognizing that the clip mask
texture's data has changed unless the texture binding is re-latched. This causes
clipping to seemingly use an old version of the clip mask's contents.
To work around this bug, the clip mask is instead built on texture unit 0, and
then only bound on texture unit 1 after it is modified, so that the binding is
only re-latched on texture unit 1 after modification.
Differential Revision: https://phabricator.services.mozilla.com/D232184
Currently we try to alternate between light-on-dark and dark-on-light
text rendering masks on macOS depending on text colors. Historically,
this matched earlier versions of macOS reasonably well. In successive
versions of macOS, however, this approximation appears to have broken
down and no longer gives correct results.
Given that recent macOS versions no longer promotes font-smoothing at
all, it seems more reasonable to match Skia's font smoothing handling
because it appears to better work with these more recent versions while
requiring us to have less special code to do so.
Differential Revision: https://phabricator.services.mozilla.com/D229444
Currently we try to alternate between light-on-dark and dark-on-light
text rendering masks on macOS depending on text colors. Historically,
this matched earlier versions of macOS reasonably well. In successive
versions of macOS, however, this approximation appears to have broken
down and no longer gives correct results.
Given that recent macOS versions no longer promotes font-smoothing at
all, it seems more reasonable to match Skia's font smoothing handling
because it appears to better work with these more recent versions while
requiring us to have less special code to do so.
Differential Revision: https://phabricator.services.mozilla.com/D229444
If, by default, all DrawTargetWebgl textures are created with ExtendMode::REPEAT,
then we can support a hardware-accelerated repeat mode for free with no shader
alterations.
The shader already implements clamp to edge behavior manually to support texture
atlasing, so to allow textures to repeat, we just have to force them to be a
standalone texture and set the clamping to wider bounds to not interfere with
the hardware repeat.
Differential Revision: https://phabricator.services.mozilla.com/D226703
When AC2D fails to fall back to a software canvas due to not having a cached
surface available, we need to notify the canvas with an event so that it can
respond appropriately. This uses the newly added plumbing to do route this.
Differential Revision: https://phabricator.services.mozilla.com/D225702
This attempts to allocate shared texture handles with reserved space at the end of each row in case
pixels get uploaded outside of the row length. This does not seem to affect standalone textures.
Differential Revision: https://phabricator.services.mozilla.com/D224883
Gamma-aware ClearType rendering is used on Windows even when requesting
grayscale AA, as we still sample the approximate luminance of the ClearType
result to generate the grayscale result. To compensate for this, we have to
use preblending for grayscale AA, even when no subpixel AA is requested.
Differential Revision: https://phabricator.services.mozilla.com/D222229
This attempts to map linear gradient to 1D textures of sufficient resolution
for a given rendered primitive. The 1D texture can then be rendered using
the image shader, without having to add any specialized gradient shaders.
The 1D ramp textures are much smaller than uploading a texture for an entire
fallback primitive, which becomes a significant performance benefit in the
case of primitives that take up a large area on screen.
In the future it might be possible to cache these ramp textures, but for now
they remain uncached.
Differential Revision: https://phabricator.services.mozilla.com/D221107
Even though glyph masks are stored without any baked-in color, the blending weights
they represent are preblended so as to be gamma-aware on macOS and Windows. That means
the color requested for the glyph alters the mask itself. It is not sufficient to
store a single mask that can be used for any color, rather, there must be different
masks stored for each potential preblend ramp that is generated by Skia.
Skia uses a quantization scheme where only the high bits of the color are used to
generate the preblend ramp so as to minimize the number of tables generated, so we do
our best to mimic that scheme and avoid generating an excessive number of masks. This
allows reuse of masks for some subset of colors, albeit not every color.
However, coaxing Skia into generating preblended masks without baking in the final
rasterized color requires some subversive use of SkShader to alter the queried luminance
color without changing the actual color of an SkPaint. An alternative invasive approach
would be to modify Skia to support this via a flag in SkPaint directly, but that would
require patching Skia directly, which might be necessary in the future should SkShader
become deprecated.
Differential Revision: https://phabricator.services.mozilla.com/D219242
Even though glyph masks are stored without any baked-in color, the blending weights
they represent are preblended so as to be gamma-aware on macOS and Windows. That means
the color requested for the glyph alters the mask itself. It is not sufficient to
store a single mask that can be used for any color, rather, there must be different
masks stored for each potential preblend ramp that is generated by Skia.
Skia uses a quantization scheme where only the high bits of the color are used to
generate the preblend ramp so as to minimize the number of tables generated, so we do
our best to mimic that scheme and avoid generating an excessive number of masks. This
allows reuse of masks for some subset of colors, albeit not every color.
However, coaxing Skia into generating preblended masks without baking in the final
rasterized color requires some subversive use of SkShader to alter the queried luminance
color without changing the actual color of an SkPaint. An alternative invasive approach
would be to modify Skia to support this via a flag in SkPaint directly, but that would
require patching Skia directly, which might be necessary in the future should SkShader
become deprecated.
Differential Revision: https://phabricator.services.mozilla.com/D219242
The previous attempt at refining the subpixel anti-aliasing approximation modified the
distance-to-edge tracking, which can cause the AA to approach zero too soon.
This fixes this by reverting the distance-to-edge tracking back to the way it was, but
instead limiting the alpha to the area of the subpixel rectangle if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D218493
We can avoid falling back to Skia on certain fill/clear ops so long as
the transform produces axis-aligned rectangles. In that case, we can
do a precise clip of the transformed rect to the viewport, which can
then be accelerated without any risk of fallback.
Differential Revision: https://phabricator.services.mozilla.com/D218472
The existing distance-to-edge AA scheme breaks down somewhat when rectangles
have subpixel areas. We need to bias the AA to account for this situation when
the scales get to these subpixel sizes.
Differential Revision: https://phabricator.services.mozilla.com/D215095
The existing custom TexturePacker can have some worst case behavior
when it is filled with a lot of allocated textures. Allocation
can become deeply recursive, causing allocator performance to hit
a performance cliff.
Using Etagere instead should remove this potential performance
issue while simplifying the code of DrawTargetWebgl.
Differential Revision: https://phabricator.services.mozilla.com/D213812
This shares a global SharedContextWebgl among all instances of CanvasTranslator.
The goal is that regardless of how many windows are open, we only have to pay the
startup costs and shader compilation times for SharedContextWebgl once. In the
event that all CanvasTranslators are gone, the SharedContextWebgl is kept around
while its internal caches and textures are discarded to avoid significant memory
usage when no canvases are in use, while at the same time saving on startup
costs the next time a first live CanvasTranslator is created.
Differential Revision: https://phabricator.services.mozilla.com/D205977
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
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
