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
When GDK_BACKEND is wayland, widget is not fully mapped during creating CompositorSession. Needs to create valid EGLSurface after widget is fully mapped.
Differential Revision: https://phabricator.services.mozilla.com/D18940
It turns out that setting the parent link on a clip chain is no longer
needed (and probably hasn't been since WR started applying a stacking
context's clip to the SC's contents). In fact it can produce incorrect
behaviour in some cases, because it doesn't match the semantics of
Gecko's clip chains. This removes the parent link on the Gecko side and
adds a test for this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D18101
--HG--
extra : moz-landing-system : lando
We lose some sugar but gain some safety. This seems like the right
trade. If people want sugar they should use Rust.
Differential Revision: https://phabricator.services.mozilla.com/D16918
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
The only thing using both was perspective, but that's not really needed with the current setup.
This more closely matches Gecko, too.
Differential Revision: https://phabricator.services.mozilla.com/D16764
The only thing using both was perspective, but that's not really needed with the current setup.
This more closely matches Gecko, too.
Differential Revision: https://phabricator.services.mozilla.com/D16764
--HG--
extra : moz-landing-system : lando
When scroll frames are created, and no explicit parent is provided,
the old code used to take the ClipID from the c/s stack. The stack
has been removed on WR side, and this parent assignment got lost.
This change takes the SpatialID from the top of the stack on Gecko
side to replicate the old behavior.
Differential Revision: https://phabricator.services.mozilla.com/D16732
--HG--
extra : moz-landing-system : lando
When scroll frames are created, and no explicit parent is provided,
the old code used to take the ClipID from the c/s stack. The stack
has been removed on WR side, and this parent assignment got lost.
This change takes the SpatialID from the top of the stack on Gecko
side to replicate the old behavior.
Differential Revision: https://phabricator.services.mozilla.com/D16732
--HG--
extra : moz-landing-system : lando
Barret Rennie
Doug Thayer
Ciure Andrei
Glenn Watson
sotaro
Bobby Holley
Sylvestre Ledru
Dzmitry Malyshau
Gurzau Raul
Jeff Muizelaar
Narcis Beleuzu
Dorel Luca
shindli
Emilio Cobos Álvarez
Csoregi Natalia
Kartikaya Gupta
Timothy Nikkel
Jamie Nicol
Coroiu Cristina
Nicolas Silva
Jeff Gilbert
Masatoshi Kimura
Bogdan Tara
Cosmin Sabou
Ryan Hunt
Oana Pop Rus
Daniel Varga
Lee Salzman
Razvan Maries
WR Updater Bot
Greg Tatum
Brindusan Cristian
Margareta Eliza Balazs
Ehsan Akhgari