Adds early exit if not originating in the parent process when recording
display HDR capability. This helps to remove more win32k usage from
content processes.
Differential Revision: https://phabricator.services.mozilla.com/D23051
--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
As a general principle, we're trying to remove most usage of the
render task data that gets stored in a texture (bind_frame_data
is slow on many platforms, and it's somewhat inflexible with the
amount of data that can be provided).
This also lays some foundations for possibly drawing clip masks
with alternative techniques on mobile / tiled GPU architectures,
where we may not need / want a render task for clip masks.
Differential Revision: https://phabricator.services.mozilla.com/D23271
--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
There's nothing to get around it unfortunately, making firefox unusable without it.
Differential Revision: https://phabricator.services.mozilla.com/D22874
--HG--
extra : moz-landing-system : lando
Should the configuration had changed at startup, a crash guard would have always been re-attempted even if a new crash occurred.
Differential Revision: https://phabricator.services.mozilla.com/D22623
--HG--
extra : moz-landing-system : lando
WebVR will not initialize correctly (VR process will not be started and the headset data is frozen) for subsequent sessions in a new tab once the VR process has been shut down due to being idle.
Differential Revision: https://phabricator.services.mozilla.com/D23027
--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
Just a refactor without any semantical changes.
Makes it for cleaner client code. Also prepares for caching of the world transforms.
Differential Revision: https://phabricator.services.mozilla.com/D23015
--HG--
extra : moz-landing-system : lando
Establishes a clear link of TransformData with the shader.
Associates a vertex data type permanently, which makes the code cleaner and allow finding the relevant bits quickly with search.
Differential Revision: https://phabricator.services.mozilla.com/D23006
--HG--
extra : moz-landing-system : lando
Env logger is useful for:
1. seeing error! generated by the code (by default). Sometimes it can give us hints on what is wrong with the capture, or a test right away.
2. seeing processed shader compile/link errors, which is very useful when changing them
Given that wrench is the main debugging tool at the moment, enabling the logging output by default should increase our productivity, at the cost of slightly longer build times.
Differential Revision: https://phabricator.services.mozilla.com/D23000
--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/D22894
--HG--
extra : moz-landing-system : lando
Recently, semantics for clips on stacking contexts were changed
such that primitives inherit the clip chain from all enclosing
stacking contexts. However, the hit testing code was not updated
to handle this change.
As each hit testing primitive is added, the current stack of
active stacking contexts is now scanned. Any valid clip chain
roots from the primitive and/or the stacking context stack are
added to the list of clip chain roots for this hit testing
primitive.
This patch also applies some optimizations and other cleanups
of the hit-testing code, specifically:
- Instead of cloning the hit testing runs Vec every time a
frame is built, store these in the new HitTestingScene. The
HitTestingScene is built once per scene, and then shared by
any hit tester instances via an Arc. This reduces a lot of
memory allocations and copying during scrolling.
- When creating a new HitTestingScene, pre-allocate the size
of the arrays, based on the size of the previous hit testing
structure. This works similarly to how arrays are sized
in the PrimitiveStore.
- Pre-calculate and cache a number of inverse transform matrices
that were previously being calculated for each hit testing run.
- Store hit testing primitives in a flat array, instead of runs,
since there is no longer a single clip chain id per primitive.
- Fix an apparent (?) bug in the existing hit testing code, where
clipping out a single hit test primitive would break out of the
loop for the current run of hit test items.
Differential Revision: https://phabricator.services.mozilla.com/D22635
--HG--
extra : moz-landing-system : lando
This is the SDK version we use to build other Android stuff in
mozilla-central. It's simpler if we build Wrench using the same
target since we can reuse the toolchains.
Depends on D22376
Differential Revision: https://phabricator.services.mozilla.com/D22377
--HG--
extra : moz-landing-system : lando
There is a bug on Adreno GPUs where glBlitFramebuffers always writes
to the 0th layer of a texture array, regardless of which layer is
actually attached to the draw framebuffer.
With picture caching enabled on webrender, the cached pictures were
all being drawn to the 0th layer of the picture cache texture array,
leaving the other layers blank. This was resulting in the wrong
content being drawn on one tile of the screen, and the rest being
black.
This works around this by blitting to an intermediate renderbuffer,
then using glCopyTexSubImage3D to copy from the renderbuffer to the
correct texture layer.
Differential Revision: https://phabricator.services.mozilla.com/D22305
--HG--
extra : moz-landing-system : lando
Same for blit_render_target_invert_y(). Make them wrappers around the
private function blit_render_target_impl(), which uses the currently
bound read and draw targets as before.
Differential Revision: https://phabricator.services.mozilla.com/D22304
--HG--
extra : moz-landing-system : lando
We always pass the same set of types so it seems simpler to just look it up
within the function itself.
Differential Revision: https://phabricator.services.mozilla.com/D22444
--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 existing linear gradient shader is quite slow, especially
on very large gradients on integrated GPUs.
The vast majority of gradients in real content are very simple
(typically < 4 stops, no angle, no repeat). For these, we can
run a fast path to persist a small gradient in the texture cache
and draw the gradient via the image shader.
This is _much_ faster than the catch-all gradient shader, and also
results in better batching while drawing the main scene.
In future, we can expand the fast path to handle more cases, such
as angled gradients. For now, it takes a conservative approach,
but still seems to hit the fast path on most real content.
Differential Revision: https://phabricator.services.mozilla.com/D22445
--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
This lets us restrict the size of the mask surface that we allocate
to the destination tile size. This gives a large performance
improvement.
It also includes some miscelanous fixes to the CreateClippedDrawTarget
code path.
Differential Revision: https://phabricator.services.mozilla.com/D21750
DTO = DrawTargetOffset = (-Origin.x, -Origin.y)
CTM = CurrentTransform
MASKT = MaskTransform = Inv(CurrentTransform)
MASKO = MaskOffset = (GetRect().x, GetRect().y)
The transform to device space is:
MASKT * CTM * DTO
Currently we do:
MASKT = MASKT * MASKO
Which gives us MASKT * MASKO * CTM * DTO. This works fine if there's no scale but
will not properly cancel out if there is.
I believe we want:
MASKO * MASKT * CTM * DTO
To get this we need to preTranslate instead of postTranslate.
Differential Revision: https://phabricator.services.mozilla.com/D21604
The way we control APZ zooming in WebRender is by inserting an animation
property placeholder on a WR stacking context, and then having APZ
update the animation transform value with the proper matrix at composite
time.
Previously, the stacking context being used was the rootmost
stacking context in the content process. However this doesn't work for
zoomable content in the UI process (e.g. about:support), and after
recent changes, also wraps display items that should not be affected by
zoom (e.g. scrollbars or the background color item).
This patch moves the animation property placeholder so that it
corresponds to the newly added nsDisplayAsyncZoom display item, which
corrects both of the above problems and is conceptually in line with the
desired behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D21795
--HG--
extra : moz-landing-system : lando
Remove the intern_types module in favor of the associated Internable types that we already have.
The only bit of magic I had to do is around serialization bounds, and it's nicely isolated.
Differential Revision: https://phabricator.services.mozilla.com/D21797
--HG--
extra : moz-landing-system : lando
A picture can have its own unique clip which was not considered by its
children when calculating their visible rects. As a result, if a picture
clips its primitive rect for snapping purposes, it may produce a
different snapping offset than expected. We should instead just snap to
the primitive rect itself for the picture, since it is the union of the
visible rects that we snapped to for the children.
Differential Revision: https://phabricator.services.mozilla.com/D21778
Remove the intern_types module in favor of the associated Internable types that we already have.
The only bit of magic I had to do is around serialization bounds, and it's nicely isolated.
Differential Revision: https://phabricator.services.mozilla.com/D21797
--HG--
extra : moz-landing-system : lando
Other mobile browsers disallow browser-based pinch zooming when the
first touchstart is preventDefaulted, even if the second one is not. We
allowed pinch zooming in that scenario. This patch makes it so that if
the first touchstart is preventDefaulted, then subsequent touchstart
events are also preventDefaulted, which brings our behaviour in line
with that of other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D21420
--HG--
extra : moz-landing-system : lando
Other mobile browsers disallow browser-based pinch zooming when the
first touchstart is preventDefaulted, even if the second one is not. We
allowed pinch zooming in that scenario. This patch makes it so that if
the first touchstart is preventDefaulted, then subsequent touchstart
events are also preventDefaulted, which brings our behaviour in line
with that of other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D21420
--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
example error
ERROR 2019-03-01T15:23:27Z: webrender::device::gl: (error) GL_INVALID_ENUM error generated. Invalid primitive mode.
thread 'main' panicked at 'Caught GL error 500 at 'draw_elements_instanced'', webrender/src/device/gl.rs:1098:17
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Differential Revision: https://phabricator.services.mozilla.com/D21701
--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
This patch fixes some wasted GPU time on mobile devices due to
redundant resolve / copy steps.
In the first case, we would previously do:
- Global clear of color / depth on main framebuffer.
- Bind and draw off-screen targets.
- Bind main framebuffer and draw scene.
Between step 1 and 2, a resolve step is triggered on tiled GPU
drivers, wasting a lot of GPU time. To fix this, the clear is
now deferred until the framebuffer of the first document is
drawn. This does slightly change the semantics of how WR does
clear operations, but I think it works fine and makes more sense.
In the second case, we would previously do:
- ...
- Draw main framebuffer
- End frame and invalidate the contents of input textures.
- Bind main framebuffer and draw debug overlay.
This also introduces an extra resolve / copy step, even if the
debug overlay is not enabled. To fix this, the invalidation step
of the input textures to the main framebuffer pass is deferred
until all drawing is complete on the main framebuffer, by doing
the invalidation in the end_frame() call of the texture resolver.
Together, these save a very significant amount of ms per frame
in GPU time on the mobile devices I tested.
Differential Revision: https://phabricator.services.mozilla.com/D21490
--HG--
extra : moz-landing-system : lando
This is a stab at what the correct approach to this should be. It
seems that we should be using the window size here and not the
screen_rect, as the screen_rect is not used to offset what we
normally draw, but instead generally for scissoring(?). The end
result is if we use an offset screen_rect, we end up applying
the offset of the chrome area twice, once because the document's
screen rect is offset, and once because of the tile.world_rect
offset.
Depends on D20696
Differential Revision: https://phabricator.services.mozilla.com/D20698
--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
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
Without this patch any enclosing scale transform between a blurred
picture and the nearest raster root was being ignored entirely for the
purposes of blur.
Also includes a couple of reftests to exercise this code.
Differential Revision: https://phabricator.services.mozilla.com/D20908
--HG--
extra : moz-landing-system : lando
Currently on Android we upload texture data to the webrender texture
cache using a PBO. On Adreno GPUs, however, this upload is still being
done synchronously, and profiles show a lot of time spent waiting in
glTexSubImage3D.
The problem is that the stride of the data in the PBO is not a
multiple of 256 bytes, so the driver is not able to DMA the upload.
This patch ensures that data is laid out optimally in the PBO, using
glMapBufferRange then copying the data line-by-line if required. This
allows the driver to perform the upload asynchronously as intended.
Differential Revision: https://phabricator.services.mozilla.com/D20492
--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
The tiling origin is computed withing image::tiles instead of being provided to the function.
In addition, the image rect in device space is exposed as function parameter.
In a followup, callers will have to determine the correct image rect using the blob image's visible area.
Differential Revision: https://phabricator.services.mozilla.com/D20175
--HG--
extra : moz-landing-system : lando
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)
Differential Revision: https://phabricator.services.mozilla.com/D21037
--HG--
extra : rebase_source : 7b9f4c5ed66d5ecaf613634c660f085de3584fd3
angle_shader_validation.rs just checks that the number of "switch" and "default:" are the same number in the source file, even if they occur in comments.
On Windows the vFuncs array is always 0 in the fragment shader. If we move the computation of the vFuncs array outside of the switch (so that it is computed for every type of shader, even when it is not needed) then it works.
For table/discrete we just create a lookup table for all 256 possible input values. We should probably switch to just computing the value in the shader, unless the list of value is really long.
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?
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/Layers.cpp:58:7 [-Wmissing-prototypes] no previous prototype for function 'FILEOrDefault'
gfx/layers/ipc/CompositorThread.cpp:26:25 [-Wmissing-prototypes] no previous prototype for function 'GetCompositorThreadHolder'
MINIMUM_TILE_COPY_AREA()
Differential Revision: https://phabricator.services.mozilla.com/D20266
--HG--
extra : rebase_source : 5c80a140cbd661644e2076a8852a0cfe58539083
extra : source : 7f44c2bcebce0b4bd549d653e4eff8b4bad71e29
And #include "BufferUnrotate.h" in BufferUnrotate.cpp for BufferUnrotate() function prototype.
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/2d/BufferUnrotate.cpp:17:6 [-Wmissing-prototypes] no previous prototype for function 'BufferUnrotate'
gfx/2d/DrawTargetCairo.cpp:195:6 [-Wmissing-prototypes] no previous prototype for function 'ReleaseData'
gfx/2d/DrawTargetCairo.cpp:201:18 [-Wmissing-prototypes] no previous prototype for function 'CopyToImageSurface'
gfx/2d/DrawTargetCairo.cpp:239:18 [-Wmissing-prototypes] no previous prototype for function 'GetAsImageSurface'
gfx/2d/DrawTargetCairo.cpp:251:18 [-Wmissing-prototypes] no previous prototype for function 'CreateSubImageForData'
gfx/2d/DrawTargetCairo.cpp:272:18 [-Wmissing-prototypes] no previous prototype for function 'ExtractSubImage'
gfx/2d/DrawTargetCairo.cpp:308:18 [-Wmissing-prototypes] no previous prototype for function 'GetCairoSurfaceForSourceSurface'
gfx/2d/DrawTargetRecording.cpp:26:6 [-Wmissing-prototypes] no previous prototype for function 'RecordingSourceSurfaceUserDataFunc'
gfx/2d/DrawTargetRecording.cpp:272:6 [-Wmissing-prototypes] no previous prototype for function 'RecordingFontUserDataDestroyFunc'
gfx/2d/DrawTargetWrapAndRecord.cpp:26:6 [-Wmissing-prototypes] no previous prototype for function 'WrapAndRecordSourceSurfaceUserDataFunc'
gfx/2d/DrawTargetWrapAndRecord.cpp:358:6 [-Wmissing-prototypes] no previous prototype for function 'WrapAndRecordFontUserDataDestroyFunc'
gfx/2d/FilterNodeSoftware.cpp:1816:6 [-Wmissing-prototypes] no previous prototype for function 'IsAllZero'
gfx/2d/FilterNodeSoftware.cpp:183:37 [-Wmissing-prototypes] no previous prototype for function 'CloneAligned'
gfx/2d/MacIOSurface.cpp:442:6 [-Wmissing-prototypes] no previous prototype for function 'MacIOSurfaceBufferDeallocator'
gfx/2d/QuartzSupport.mm:38:6 [-Wmissing-prototypes] no previous prototype for function 'cgdata_release_callback'
gfx/2d/ScaledFontMac.cpp:191:10 [-Wmissing-prototypes] no previous prototype for function 'CalcTableChecksum'
gfx/2d/ScaledFontMac.cpp:224:5 [-Wmissing-prototypes] no previous prototype for function 'maxPow2LessThan'
gfx/2d/unittest/TestCairo.cpp:12:6 [-Wmissing-prototypes] no previous prototype for function 'TryCircle'
Differential Revision: https://phabricator.services.mozilla.com/D20263
--HG--
extra : rebase_source : b42bce33ed899caeb89e462d99a5cde29a9bb559
extra : intermediate-source : 7923cc86a6394bcd2fb3b7e38f458a5180d31e11
extra : source : 02388f2454e8842d2c023bf9f9fab222d8130093
June Wilde
Sylvestre Ledru
Dzmitry Malyshau
Botond Ballo
Gurzau Raul
Brad Werth
David Major
Kartikaya Gupta
Glenn Watson
Doug Thayer
Oana Pop Rus
sotaro
Jeff Muizelaar
Narcis Beleuzu
Jean-Yves Avenard
Bas Schouten
Kearwood "Kip" Gilbert
Bogdan Tara
Timothy Nikkel
Henri Sivonen
Boris Zbarsky
Dorel Luca
Andreea Pavel
Jeff Gilbert
Bobby Holley
shindli
Nicolas Silva
arthur.iakab
Ciure Andrei
Miko Mynttinen
Lee Salzman
Jamie Nicol
Brian Birtles
Coroiu Cristina
Emilio Cobos Álvarez
Csoregi Natalia
Sebastian Hengst
Alex Gaynor
Ryan Hunt
Andrew Osmond
Ryan VanderMeulen
Razvan Maries
Cosmin Sabou
Daosheng Mu
Matt Woodrow
Jonathan Kingston
James Willcox
Daniel Varga
Chris Peterson
Barret Rennie
Byron Campen [:bwc]
Noemi Erli
Agi Sferro
Brindusan Cristian
Andrea Marchesini