I suspect we may change things more in the future as we blob's size
just be the visible rect but this is an incremental step in the right
direction.
It also includes some changes to make sure that we always update our
tiles appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D37079
--HG--
extra : moz-landing-system : lando
This will let us do the subtraction of the recording origin during
playback instead of during recording.
It will also let us merge recordings that have different origins.
Differential Revision: https://phabricator.services.mozilla.com/D37561
--HG--
extra : moz-landing-system : lando
I suspect we may change things more in the future as we blob's size
just be the visible rect but this is an incremental step in the right
direction.
It also includes some changes to make sure that we always update our
tiles appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D37079
--HG--
extra : moz-landing-system : lando
On startup some program binaries are loaded from disk into an
in-memory cache. When we call create_program() we check if the
required program is present in this cache, and if so we call
glProgramBinary(). This is done early on so that the driver can
perform any necessary work in the background.
There may however be binaries in the disk cache that have not yet been
loaded in to memory, in order not to slow down startup. This change
makes it so that we attempt to load missing binaries from disk during
link_program(). The reason we do not do this in create_program() is
because that would result in loading all shaders from disk during
startup, which we want to avoid. Loading these shaders may therefore
take slightly longer than if they'd been loaded at startup, but will
still be much faster than recompiling them from scratch, and startup
will remain quick.
If loading the shaders on startup had previously timed out, then we do
not attempt to load shaders on demand as the disk is probably too slow
for that to be useful.
Depends on D33954
Differential Revision: https://phabricator.services.mozilla.com/D33955
--HG--
extra : moz-landing-system : lando
Webrender caches the program binaries of shaders used within the first
ten frames, so that on next startup it can load them from disk rather
than having to recompile them.
Previously it would load all binaries found in the disk cache on
startup, and when saving to the cache it would delete any existing
binaries that weren't used.
This changes it so that unused binaries are not deleted. The disk
space this requires is insignificant, but as the cache grows loading
all the shaders on startup can get expensive. To solve that we write a
whitelist of the shaders used during startup, and only load those
during the next startup.
Differential Revision: https://phabricator.services.mozilla.com/D33954
--HG--
extra : moz-landing-system : lando
Before this patch, we would use fallback for all border images. Now for
all but vector images we will use the WebRender border images
primitives. Vector images are an exception because the fallback is
clever in that it upscales the vector image and clips to only draw the
region it requires. This avoids artifacting but to do something similar
for WebRender as it is currently defined, we would increase our CPU and
memory footprint as we would need to produce the entire vector image
upscaled, not just the parts we need. In the future we should change
WebRender to accept different image resources for each of the segments.
Differential Revision: https://phabricator.services.mozilla.com/D37093
Before this patch, we would use fallback for all border images. Now for
all but vector images we will use the WebRender border images
primitives. Vector images are an exception because the fallback is
clever in that it upscales the vector image and clips to only draw the
region it requires. This avoids artifacting but to do something similar
for WebRender as it is currently defined, we would increase our CPU and
memory footprint as we would need to produce the entire vector image
upscaled, not just the parts we need. In the future we should change
WebRender to accept different image resources for each of the segments.
Differential Revision: https://phabricator.services.mozilla.com/D37093
Seems like GeckoSurfaceTexture::DestroyUnused can change the current
context.
Differential Revision: https://phabricator.services.mozilla.com/D36685
--HG--
extra : moz-landing-system : lando
This is the first piece of the blob-recoord series. Adding
some checks to ensure things stay sane.
Differential Revision: https://phabricator.services.mozilla.com/D35806
--HG--
extra : moz-landing-system : lando
If we decide to just go with an overlay that sits fully over the
window (which I don't personally see a perf problem with right now,
but correct me if you can think of one), then this should be all
we need.
Differential Revision: https://phabricator.services.mozilla.com//D33819
--HG--
extra : rebase_source : 44a5af47f9c10071b0933931fbf3708978f549e4
On android, android's nsWindow creates LayerManaer only in nsWindow::Create(). When WebRender error happened, gecko just stopped rendering by disabling Webrender.
The nsWindow needs to re-create LayerManager during disabling Webrender. Further, during disabling WebRender, All GeckoSurfaceTextures should not be attached to GLContext. It is for preventing a conflict with AttachToGLContext() call in SurfaceTextureHost::EnsureAttached().
Differential Revision: https://phabricator.services.mozilla.com/D26687
--HG--
extra : moz-landing-system : lando
Now that we have a suitable composition recorder infrastructure, it is just a
matter of plumbing the `WebRenderCompositionRecorder` from the
`CompositorBridgeParent` to the `RenderThread` to start recording frames.
Differential Revision: https://phabricator.services.mozilla.com/D32234
--HG--
extra : moz-landing-system : lando
Since WebRender does its rendering on a separate thread from the compositor
thread, we need a composition recorder that can be shared between threads.
Differential Revision: https://phabricator.services.mozilla.com/D32231
--HG--
extra : moz-landing-system : lando
Now that we have a suitable composition recorder infrastructure, it is just a
matter of plumbing the `WebRenderCompositionRecorder` from the
`CompositorBridgeParent` to the `RenderThread` to start recording frames.
Differential Revision: https://phabricator.services.mozilla.com/D32234
--HG--
extra : moz-landing-system : lando
Since WebRender does its rendering on a separate thread from the compositor
thread, we need a composition recorder that can be shared between threads.
Differential Revision: https://phabricator.services.mozilla.com/D32231
--HG--
extra : moz-landing-system : lando
Now that we have a suitable composition recorder infrastructure, it is just a
matter of plumbing the `WebRenderCompositionRecorder` from the
`CompositorBridgeParent` to the `RenderThread` to start recording frames.
Differential Revision: https://phabricator.services.mozilla.com/D32234
--HG--
extra : moz-landing-system : lando
Since WebRender does its rendering on a separate thread from the compositor
thread, we need a composition recorder that can be shared between threads.
Differential Revision: https://phabricator.services.mozilla.com/D32231
--HG--
extra : moz-landing-system : lando
If ExternalImageType is just passed from C to rust, it caused crash on non-Windows platform. It was caused by stack corruption. Then &ExternalImageType is used instead of ExternalImageType to bypass the problem.
Differential Revision: https://phabricator.services.mozilla.com/D32436
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
It is theorically possible that the WinCompositorWindowThread failed to start. Should this happen, attempting to shut it down will cause shutdown to hang forever.
Differential Revision: https://phabricator.services.mozilla.com/D32602
--HG--
extra : moz-landing-system : lando
The EGL context must be set before the call to eglSwapInterval to ensure that it will operate on the correct context.
Differential Revision: https://phabricator.services.mozilla.com/D30282
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
When pinch zooming webrender would re-rasterize glyphs for each tiny
difference in zoom level. This takes time in itself, but also causes
the texture cache to grow incredibly large, to the point where
resizing it to make room for more glyphs takes far too much time.
This patch avoids this by rounding the size at which glyphs are
rasterized whilst pinch zooming. To do this we add a FrameMsg which
APZ uses to tell webrender whether a spatial node is being pinch
zoomed. Then during frame building if a spatial node is being pinch
zoomed we override the raster space of its corresponding picture.
The chosen raster space is the current zoom level rounded up to the
nearest power of two, but not exceeding 8x. This seems to be a good
balance between quality and performance, though at high zoom levels
the cache still does grow very large due to the size of the glyphs.
Differential Revision: https://phabricator.services.mozilla.com/D30213
--HG--
extra : moz-landing-system : lando
BGRA may not be supported on GLES implementations, such as on the
Pixel 2 device. Since WR on Android uses GLES, we should use RGBA
when getting snapshots so that it actually works instead of failing
silently.
Differential Revision: https://phabricator.services.mozilla.com/D29060
--HG--
extra : moz-landing-system : lando
The Rgba8 enum value is redundant with the Standard(ImageFormat::RGBA8) value,
this patch collapses the former into the latter. Which then makes the entire
ReadPixelsFormat redundant, so we can get rid of it completely.
Differential Revision: https://phabricator.services.mozilla.com/D29059
--HG--
extra : moz-landing-system : lando
GeckoSurfaceTexture could bind to only one GL context at once. With WebRender, GeckoSurfaceTexture is soon bounded to sharedGL on render thread. It caused the problem if GeckoSurfaceTexture is rendered to WebGL. It could happen only for video's GeckoSurfaceTexture. To avoid the problem, the GeckoSurfaceTexture is bound to gl context when it is actually rendered on WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D27873
--HG--
extra : moz-landing-system : lando
We can't yet enable the build by default since it pulls in networking functions
into libgkrust which runs afoul of the checks added in bug 1376621.
Differential Revision: https://phabricator.services.mozilla.com/D28353
--HG--
extra : moz-landing-system : lando
The gist of the problem I introduced with the framebuffer coordinate system is that we provided the window rect (effectively) twice:
1. when computing the document rectangle (and Y-inverting it)
2. when rendering
If between these points the window got resized (during scene building), we end up with our document aligned to bottom left corner.
The user expects content to still be aligned to the top left, so that's what is visible as a bug.
The change here switched scene building to only care about device coordinate space, restraining the framebuffer coordinates to be mostly
an implementation detail of the renderer/device (the way it was originally meant to be, when introduced). This way the current window size
is only considered once during rendering.
Differential Revision: https://phabricator.services.mozilla.com/D28731
--HG--
extra : moz-landing-system : lando
disclaimer: this isn't an *amazing* cleanup, but more of a major step that
unlocks the ability to do more minor cleanups and refinements. There's some
messy things and inconsistencies here and there, but we can hopefully iron
them out over time.
1. The primary change here is to move from
struct { common_fields, enum(specific_fields) }
to
enum (maybe_common_fields, specific_fields)
most notably this drops the common fields from a ton of things
that don't need them PopXXX, SetXXX, ClipChain, etc.
2. Additionally some types have had some redundant states shaved off,
for instance, rect no longer has *both* bounds and a clip_rect, as
the intersection of the two can be used. This was done a bit conservatively
as some adjustments will need to be done to the backend to fully eliminate
some states, and this can be done more incrementally.
2.5. As a minor side-effect of 2, we now early-reject some primitives whose
bounds and clip_rect are disjoint.
3. A HitTest display item has been added, which is just a Rect without
color. In addition to the minor space wins from this, this makes it much
easier to debug display lists
4. Adds a bunch of comments to the display list, making it easier to understand
things.
The end result of all these changes is a significantly smaller and easier to
understand display list. Especially on pages like gmail which have so many
clip chains. However this ultimately just makes text an even greater percentage
of pages (often 70-80%).
Differential Revision: https://phabricator.services.mozilla.com/D27439
--HG--
extra : moz-landing-system : lando
disclaimer: this isn't an *amazing* cleanup, but more of a major step that
unlocks the ability to do more minor cleanups and refinements. There's some
messy things and inconsistencies here and there, but we can hopefully iron
them out over time.
1. The primary change here is to move from
struct { common_fields, enum(specific_fields) }
to
enum (maybe_common_fields, specific_fields)
most notably this drops the common fields from a ton of things
that don't need them PopXXX, SetXXX, ClipChain, etc.
2. Additionally some types have had some redundant states shaved off,
for instance, rect no longer has *both* bounds and a clip_rect, as
the intersection of the two can be used. This was done a bit conservatively
as some adjustments will need to be done to the backend to fully eliminate
some states, and this can be done more incrementally.
2.5. As a minor side-effect of 2, we now early-reject some primitives whose
bounds and clip_rect are disjoint.
3. A HitTest display item has been added, which is just a Rect without
color. In addition to the minor space wins from this, this makes it much
easier to debug display lists
4. Adds a bunch of comments to the display list, making it easier to understand
things.
The end result of all these changes is a significantly smaller and easier to
understand display list. Especially on pages like gmail which have so many
clip chains. However this ultimately just makes text an even greater percentage
of pages (often 70-80%).
Differential Revision: https://phabricator.services.mozilla.com/D27439
--HG--
extra : moz-landing-system : lando
The array takes up more space than a bitset, and we don't need to keep
duplicates anyway, so the set doesn't lose us anything.
Differential Revision: https://phabricator.services.mozilla.com/D27900
--HG--
extra : moz-landing-system : lando
NotifyWebRenderError is sent via CompositorBridgeParent/CompositorBridgeChild. It is not good, since they are re-created for each nsBaseWidget::CreateCompositorSession() call. Then there could be a case that the NotifyWebRenderError is not notified to GPUProcessManager and a crash was caused by NotifyWebRenderError message during ipc close. CompositorManagerParent/CompositorManagerChild are stable for sending NotifyWebRenderError.
Differential Revision: https://phabricator.services.mozilla.com/D27030
--HG--
extra : moz-landing-system : lando
We discussed this a bit in Orlando. Essentially, we want to run cleanup
operations in texture_cache before all documents' frames, and then be
able to ensure that every document generates a frame, because otherwise
we will run into problems with evicted cache items used by non-updating-
but-still-rendering documents. Accordingly, we need an endpoint to
lump all of the transactions that generate frames together. This adds
that and builds out all of the plumbing necessary.
Differential Revision: https://phabricator.services.mozilla.com/D25132
--HG--
extra : moz-landing-system : lando
We discussed this a bit in Orlando. Essentially, we want to run cleanup
operations in texture_cache before all documents' frames, and then be
able to ensure that every document generates a frame, because otherwise
we will run into problems with evicted cache items used by non-updating-
but-still-rendering documents. Accordingly, we need an endpoint to
lump all of the transactions that generate frames together. This adds
that and builds out all of the plumbing necessary.
Differential Revision: https://phabricator.services.mozilla.com/D25132
--HG--
extra : moz-landing-system : lando
During playing a video, one GeckoSurfaceTexture is used for all RenderAndroidSurfaceTextureHostOGLs of the video. GeckoSurfaceTexture owns multiple buffers. UpdateTexImage() needs to be called at the correct timing for adjusting SurfaceTexture's buffer status.
Differential Revision: https://phabricator.services.mozilla.com/D27467
--HG--
extra : moz-landing-system : lando
When mContinuousUpdate is true, UpdateTexImage() needs to be called for each rendering.
Differential Revision: https://phabricator.services.mozilla.com/D27232
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
YUVColorSpace is inseparable from the bit depth as the matrix coefficients to be calculated need the bit depth information.
So let's put the two types together. gfx namespace also makes more sense as that's where we find IntRect, IntSize and other.
The extent of the changes highlight how much similar data structures are duplicated across the code, to the point it's scary.
Differential Revision: https://phabricator.services.mozilla.com/D25347
--HG--
extra : moz-landing-system : lando
We discussed this a bit in Orlando. Essentially, we want to run cleanup
operations in texture_cache before all documents' frames, and then be
able to ensure that every document generates a frame, because otherwise
we will run into problems with evicted cache items used by non-updating-
but-still-rendering documents. Accordingly, we need an endpoint to
lump all of the transactions that generate frames together. This adds
that and builds out all of the plumbing necessary.
Differential Revision: https://phabricator.services.mozilla.com/D25132
--HG--
extra : moz-landing-system : lando
When SurfaceTexture is single buffer mode, UpdateTexImage() should be called only once for each publish. If UpdateTexImage() is called more than once, it causes hand on puglish side.
Differential Revision: https://phabricator.services.mozilla.com/D24483
--HG--
extra : moz-landing-system : lando
wr_window_new() uses (0.0, 0.0, 0.0, 1.0) and (0.0, 0.0, 0.0, 0.0) as clear color. Then it makes rendering black until a content of webrender comes. By changing clear color to (1.0, 1.0, 1.0, 1.0), we could suppress black flashing.
Differential Revision: https://phabricator.services.mozilla.com/D25832
--HG--
extra : moz-landing-system : lando
On android, we want to use only RenderCompositorEGL for using sharedGL. Further RenderCompositorOGL does not work well with android SurfaceTexture.
Differential Revision: https://phabricator.services.mozilla.com/D25201
--HG--
extra : moz-landing-system : lando
Bug 1416015 and Bug 1470348 added function calls for CompositorOGL. Similar things needs to be done for RenderCompositorEGL.
Differential Revision: https://phabricator.services.mozilla.com/D25199
--HG--
extra : moz-landing-system : lando
The receiver of this parameter treats it as a layout size, so it doesn't
make sense for the argument to be a LayerSize partway through the call
chain. Also the callers originally get this from a LayoutDevice rect;
so there's even less reason for this to be turned into a LayerSize. The
next patch will propagate this cleanup more.
Differential Revision: https://phabricator.services.mozilla.com/D25238
--HG--
extra : moz-landing-system : lando
The change contains a number of incremental improvements with the main goal of:
- allocating exactly as many tile as required by the app
- respecting the picture caching option
Differential Revision: https://phabricator.services.mozilla.com/D24740
--HG--
extra : moz-landing-system : lando
The change contains a number of incremental improvements with the main goal of:
- allocating exactly as many tile as required by the app
- respecting the picture caching option
Differential Revision: https://phabricator.services.mozilla.com/D24740
--HG--
extra : moz-landing-system : lando
If we try to send them separately as we were before, we can run into
cases where we try to destroy the actors and then send the OpRemoveTexture,
which crashes.
Differential Revision: https://phabricator.services.mozilla.com/D23987
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
If we try to send them separately as we were before, we can run into
cases where we try to destroy the actors and then send the OpRemoveTexture,
which crashes.
Differential Revision: https://phabricator.services.mozilla.com/D23987
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
Add an experimental code path that makes use of the pixel local
storage extension available on many mobile GPUs.
This code path is currently disabled by default, as the support
is not complete for all primitives and blend modes. The initial
aim is to get feature parity with the existing renderer.
Once that's complete, we can take advantage of the (minimum)
12 bytes per pixel of high speed on-tile memory to store custom
data.
Clip masks are a good use case for this, since they map 1:1 with
the position of the fragment they are clipping. Using this for
clip masks allows us to handle clipping on mobile GPUs in a much
more efficient way - we can skip (a) separate render targets,
(b) target resolve (c) sample the mask texture during rendering.
Depends on D24123
Differential Revision: https://phabricator.services.mozilla.com/D24124
--HG--
extra : moz-landing-system : lando
RenderCompositorEGL is also used on wayland, but SharedGL is not enabled on wayalnd. Since SharedGL caused flickering, when multiple windows were opened on wayland.
Differential Revision: https://phabricator.services.mozilla.com/D23786
--HG--
extra : moz-landing-system : lando
The cleans up our WR use statements further, easying the merge conflicts.
Note: this PR is subject to instant rot, it is preferred to land quickly.
Differential Revision: https://phabricator.services.mozilla.com/D23373
--HG--
extra : moz-landing-system : lando
The cleans up our WR use statements further, easying the merge conflicts.
Note: this PR is subject to instant rot, it is preferred to land quickly.
Differential Revision: https://phabricator.services.mozilla.com/D23373
--HG--
extra : moz-landing-system : lando
On Wayland with WebRender, RenderCompositorEGL creates headless context by using GLContextProviderEGL::CreateForCompositorWidget(), since GetNativeData(NS_NATIVE_EGL_WINDOW) returns nullptr. But we want to make hadless explicitly. But GLContextProviderEGL::CreateHeadless() and GLContextEGL::CreateEGLPBufferOffscreenContext() could not be used for it. They creates incompatible EGLConfig to egl window. Then we extends GLContextProviderEAGL::CreateForCompositorWidget() to handle this case. When CreateForCompositorWidget() receives null widget, it creates GLContext without surface of egl window.
Differential Revision: https://phabricator.services.mozilla.com/D22454
--HG--
extra : moz-landing-system : lando
By Bug 1526213, WebRenderBridgeParent::RecvEmptyTransaction() does not handle a case that resource update is handled by WebRenderTextureHostWrapper. In this case, txn.IsResourceUpdatesEmpty() became true and the function thought there was no resource update and the function returned DidComposite soon to client side. Then it caused a heavy over production of SharedSurface_ANGLEShareHandle if GPU is not powerful.
Differential Revision: https://phabricator.services.mozilla.com/D22454
By Bug 1526213, WebRenderBridgeParent::RecvEmptyTransaction() does not handle a case that resource update is handled by WebRenderTextureHostWrapper. In this case, txn.IsResourceUpdatesEmpty() became true and the function thought there was no resource update and the function returned DidComposite soon to client side. Then it caused a heavy over production of SharedSurface_ANGLEShareHandle if GPU is not powerful.
Differential Revision: https://phabricator.services.mozilla.com/D22894
--HG--
extra : moz-landing-system : lando
We can get back the fancy flag syntax as soon as we get C++17 inline variables,
which I sent an email to dev-platform@ about, with no reply.
Differential Revision: https://phabricator.services.mozilla.com/D22382
--HG--
extra : moz-landing-system : lando
EGLConfig could be get from GLContextEGL. It is better to use it than re-creating EGLConfig.
Differential Revision: https://phabricator.services.mozilla.com/D22274
--HG--
extra : moz-landing-system : lando
The goal of this change was to simplify the semantics of our document placement and split the logical elements inside (display list) from the actual screen rectangle occupied by a document.
To achieve that, we introduce the framebuffer space for things Y-flipped on screen.
We fix the frame outputs, so that they get produced on the first frame without loopback from the frame building to scene building.
Differential Revision: https://phabricator.services.mozilla.com/D21641
--HG--
extra : moz-landing-system : lando
The goal of this change was to simplify the semantics of our document placement and split the logical elements inside (display list) from the actual screen rectangle occupied by a document.
To achieve that, we introduce the framebuffer space for things Y-flipped on screen.
We fix the frame outputs, so that they get produced on the first frame without loopback from the frame building to scene building.
Differential Revision: https://phabricator.services.mozilla.com/D21641
--HG--
extra : moz-landing-system : lando
Bug 1527804 did not expect multiple moz_container_unmap_wayland()/moz_container_map_wayland() calls. inital_draw_cb should not be cleared in multiple moz_container_unmap_wayland().
Differential Revision: https://phabricator.services.mozilla.com/D21522
--HG--
extra : moz-landing-system : lando
Change the external scroll offset to be a vector, rather than a
point. This can also be updated gecko-side in future, but for
now is converted to a vector at the API boundary.
Also plumb through the external scroll offset so that it is stored
inside the ScrollFrameInfo in a spatial node. This will allow
modifying the transforms that the clip-scroll tree creates to
take into account the external scroll offset in future.
Differential Revision: https://phabricator.services.mozilla.com/D21319
--HG--
extra : moz-landing-system : lando
The format for stacking contexts in the built display list goes from
PushStackingContext item
push_iter of Vec<FilterOp>
to
SetFilterOps item
push_iter of Vec<FilterOp>
1st SetFilterData item
push_iter of array of func types
push_iter funcR values
push_iter funcG values
push_iter funcB values
push_iter funcA values
.
.
.
nth SetFilterData item
push_iter of array of func types
push_iter funcR values
push_iter funcG values
push_iter funcB values
push_iter funcA values
PushStackingContext item
We need separate a SetFilterData item for each filter because we can't push_iter a variable sized thing.
When we iterate over the built display list to flatten it we work similarly to how gradients work with a SetGradientStops item before the actual gradient item. So when we see SetFilterOps or SetFilterData we use them to fill out values on the built display list iterator but don't those items return them to the iterator user and instead continue iterating until we hit the PushStackingContext item, at which point to the iterator consumer it appears as those the FilterOps and FilterDatas were on the PushStackingContext item. (This part is trickier too since we need a TempFilterData type that just holds ItemRange's until we get the actual bytes later.)
Do we need to clear cur_filters and cur_filter_data at some point to prevent them from getting ready by items for which they do not apply?
The format for stacking contexts in the built display list goes from
PushStackingContext item
push_iter of Vec<FilterOp>
to
SetFilterOps item
push_iter of Vec<FilterOp>
1st SetFilterData item
push_iter of array of func types
push_iter funcR values
push_iter funcG values
push_iter funcB values
push_iter funcA values
.
.
.
nth SetFilterData item
push_iter of array of func types
push_iter funcR values
push_iter funcG values
push_iter funcB values
push_iter funcA values
PushStackingContext item
We need separate a SetFilterData item for each filter because we can't push_iter a variable sized thing.
When we iterate over the built display list to flatten it we work similarly to how gradients work with a SetGradientStops item before the actual gradient item. So when we see SetFilterOps or SetFilterData we use them to fill out values on the built display list iterator but don't those items return them to the iterator user and instead continue iterating until we hit the PushStackingContext item, at which point to the iterator consumer it appears as those the FilterOps and FilterDatas were on the PushStackingContext item. (This part is trickier too since we need a TempFilterData type that just holds ItemRange's until we get the actual bytes later.)
Do we need to clear cur_filters and cur_filter_data at some point to prevent them from getting ready by items for which they do not apply?
Splitting part of OGLShaderProgram.h out into OGLShaderConfig.h makes it
easier to keep GLContext.h included in OGLShaderProgram.h for inlining
purposes.
Differential Revision: https://phabricator.services.mozilla.com/D20017
--HG--
extra : moz-landing-system : lando
Splitting part of OGLShaderProgram.h out into OGLShaderConfig.h makes it
easier to keep GLContext.h included in OGLShaderProgram.h for inlining
purposes.
Differential Revision: https://phabricator.services.mozilla.com/D20017
--HG--
extra : moz-landing-system : lando
By using WebRenderTextureHostWrapper for canvas, we could avoid triggering frame build on WebRender backend if WebRenderTextureHostWrapper is only change.
Differential Revision: https://phabricator.services.mozilla.com/D19896
--HG--
extra : moz-landing-system : lando
Jeff Muizelaar
Connor Brewster
Csoregi Natalia
Jeff Gilbert
Noemi Erli
Barret Rennie
Andreea Pavel
sotaro
Jamie Nicol
Dorel Luca
Oana Pop Rus
Nicolas Silva
Narcis Beleuzu
Andrew Osmond
Robert Mader
Sylvestre Ledru
Gurzau Raul
Kartikaya Gupta
Coroiu Cristina
Doug Thayer
Nicholas Nethercote
Bob Owen
Neil Deakin
Jean-Yves Avenard
Bastien Orivel
Kenny Levinsen
arthur.iakab
Alexis Beingessner
Razvan Maries
Dzmitry Malyshau
Daniel Varga
Martin Stransky
Alex Gaynor
Cosmin Sabou
Ciure Andrei
Glenn Watson
Bobby Holley
shindli
Emilio Cobos Álvarez
Timothy Nikkel
Masatoshi Kimura
Bogdan Tara