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
