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
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
This also replaces 'isFennec' with the more correct 'is_fennec'.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--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
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
In this case, moving these functions' declarations to header files means the same declaration will be seen by the .cpp files defining each function and TextureHost.cpp calling the functions.
Differential Revision: https://phabricator.services.mozilla.com/D20268
--HG--
extra : source : ffeda0b30541127073de4892ba3e1a6e8bd0f15f
extra : intermediate-source : 22238a64f3da13ed0f8de826092def10a427a55a
extra : histedit_source : b6f1c1e39ddf16f7e5716eb07915114b94204174
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
In this case, moving ShutdownTileCache()'s function declaration to the header file TiledContentClient.h means the same declaration will be seen by the TiledContentClient.cpp file defining the function and the gfxPlatform.cpp calling the function.
gfx/layers/client/TiledContentClient.cpp:337:6 [-Wmissing-prototypes] no previous prototype for function 'ShutdownTileCache'
Differential Revision: https://phabricator.services.mozilla.com/D20267
--HG--
extra : source : 495273cd3fdc65f353d5562573503fc897760603
extra : histedit_source : fab19badff1cadd66212cf182978217b398c0fe6
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
gfx/layers/composite/ContainerLayerComposite.cpp:132:6 [-Wmissing-prototypes] no previous prototype for function 'TransformLayerGeometry'
gfx/layers/composite/LayerManagerComposite.cpp:1409:6 [-Wmissing-prototypes] no previous prototype for function 'ComputeVisibleRegionForChildren'
gfx/layers/composite/LayerManagerComposite.cpp:234:6 [-Wmissing-prototypes] no previous prototype for function 'ShouldProcessLayer'
gfx/layers/composite/TiledContentHost.cpp:156:6 [-Wmissing-prototypes] no previous prototype for function 'UseTileTexture'
gfx/layers/ipc/CompositorBridgeParent.cpp:1827:6 [-Wmissing-prototypes] no previous prototype for function 'EraseLayerState'
gfx/layers/ipc/CompositorBridgeParent.cpp:2140:6 [-Wmissing-prototypes] no previous prototype for function 'UpdateIndirectTree'
gfx/layers/opengl/OGLShaderProgram.cpp:28:6 [-Wmissing-prototypes] no previous prototype for function 'AddUniforms'
Differential Revision: https://phabricator.services.mozilla.com/D20265
--HG--
extra : source : f5653a8b1bc5a02cf899fe87cb3ebc9796b0b0b1
extra : histedit_source : 4f44f15098c42b4b1fa141de7b8593c128b58596
Preferrably CreateOffscreenContentDrawTarget would create Capture DrawTargets when we intend to use OMTP. This is not the case at the moment though and changing this would likely introduce more unforseen issues. For now all of these calls basically mean a DrawTarget will be used on the main thread and we should use a no-op ClearRect to ensure that the DrawTarget is actually initialized. Since IsValid for the moment won't do this for DrawTargetD2D. (See bug 1521368)
--HG--
extra : rebase_source : 6a5c1732d3908be748ea4d05668f4a7562828f6a
This doesn't introduce any functional changes. However, it refactors
the way that stacking context coords are converted into reference
frame relative coordinates.
Having a single method to retrieve the current offset will make it
easier to take advantage of the newly added API that allows Gecko
to supply initial scroll offsets for scroll nodes. In turn, this
will allow WR to normalize the local coordinates of primitives, which
will allow future improvements and simplifications to the picture
caching implementation.
Differential Revision: https://phabricator.services.mozilla.com/D21090
--HG--
extra : moz-landing-system : lando
A number of small tweaks to enable the picture caching invalidation
tests. With this in place, we can start adding more test coverage
for various invalidation scenarios.
- Make the reference image render after the test images, so that dirty
region tracking is more intuitive.
- Instead of replaying the same frame in wrench to ensure frames are
caching, try to cache tiles every frame when testing mode is enabled.
- Add a basic invalidation test for a rectangle with color that changes
each frame.
- Make the dirty region index implicit and rename dirty_region to dirty
in reftest format.
- Fix an underflow error when moving to next frame in wrench.
Differential Revision: https://phabricator.services.mozilla.com/D20963
--HG--
extra : moz-landing-system : lando
This is a new implementation of mix-blend compositing that is meant to be more idiomatic to WR and efficient.
Previously, mix-blend mode was composed in the following way:
1. parent stacking context was forced to isolate
2. source picture is also isolated
3. when rendering the isolated context, the framebuffer is read upon reaching the source. Both the readback and the source are placed in the RT cache.
4. a mix-blend draw call is issued to read from those cache segments and blend on top of the backdrop
The new implementation works by using the picture cutting (intruduced for preserve-3D contexts earlier) and some bits of magic:
1. backdrop stacking context is isolated with a special composition mode that prevents it from actually rendeing unless the suorce stacking context is invisible.
2. source stacking context is isolated with mix-blend composition mode that has a pointer to the backdrop picture
3. the instance of the backdrop picture is placed as a peer of the source picture (not a child)
4. if the backdrop is invisible, the source is drawn as a simple blit
5. otherwise, it's a draw call that reads from the isolated backdrop and source textures
Note the differences:
- parent stacking context is not isolated, but backdrop is
- no framebuffer readback is involved
- the source and backdrop pictures are rendered in parallel in a pass, improving the batching
- we don't blend onto the backdrop while reading from the backdrop copy at the same time
- the depth of the render pass tree is reduced: previously the parent and the source were isolated, now the source and the backdrop, which are siblings
Differential Revision: https://phabricator.services.mozilla.com/D20608
--HG--
rename : gfx/wr/wrench/reftests/blend/multiply-2-ref.yaml => gfx/wr/wrench/reftests/blend/multiply-3-ref.yaml
rename : gfx/wr/wrench/reftests/blend/multiply-3.yaml => gfx/wr/wrench/reftests/blend/multiply-4.yaml
extra : moz-landing-system : lando
Document splitting is crashing with early initialization of the debug
renderer. Not sure why, and this is just a temporary workaround, but
one that I think we want anyway, as we don't want to be unnecessarily
lazy-initting the debug renderer.
Depends on D20698
Differential Revision: https://phabricator.services.mozilla.com/D20700
--HG--
extra : moz-landing-system : lando
This is a new implementation of mix-blend compositing that is meant to be more idiomatic to WR and efficient.
Previously, mix-blend mode was composed in the following way:
1. parent stacking context was forced to isolate
2. source picture is also isolated
3. when rendering the isolated context, the framebuffer is read upon reaching the source. Both the readback and the source are placed in the RT cache.
4. a mix-blend draw call is issued to read from those cache segments and blend on top of the backdrop
The new implementation works by using the picture cutting (intruduced for preserve-3D contexts earlier) and some bits of magic:
1. backdrop stacking context is isolated with a special composition mode that prevents it from actually rendeing unless the suorce stacking context is invisible.
2. source stacking context is isolated with mix-blend composition mode that has a pointer to the backdrop picture
3. the instance of the backdrop picture is placed as a peer of the source picture (not a child)
4. if the backdrop is invisible, the source is drawn as a simple blit
5. otherwise, it's a draw call that reads from the isolated backdrop and source textures
Note the differences:
- parent stacking context is not isolated, but backdrop is
- no framebuffer readback is involved
- the source and backdrop pictures are rendered in parallel in a pass, improving the batching
- we don't blend onto the backdrop while reading from the backdrop copy at the same time
- the depth of the render pass tree is reduced: previously the parent and the source were isolated, now the source and the backdrop, which are siblings
Differential Revision: https://phabricator.services.mozilla.com/D20608
--HG--
rename : gfx/wr/wrench/reftests/blend/multiply-2-ref.yaml => gfx/wr/wrench/reftests/blend/multiply-3-ref.yaml
rename : gfx/wr/wrench/reftests/blend/multiply-3.yaml => gfx/wr/wrench/reftests/blend/multiply-4.yaml
extra : moz-landing-system : lando