The signatures were updated in the previous patch to hand us the raw,
uncopied buffers. This just adjusts the callsites to match.
Differential Revision: https://phabricator.services.mozilla.com/D34653
--HG--
extra : moz-landing-system : lando
Bug 1460357 disabled AVX because gcc was generating unaligned instructions. But clang doesn't seem
to do that.
Differential Revision: https://phabricator.services.mozilla.com/D48072
--HG--
extra : moz-landing-system : lando
Promote clear primitives to be picture cache slices that can
be drawn during the composite step. Without this, the clear
primitive is not correct since it only operates on the slice
it is assigned to, not the entire background before it.
Differential Revision: https://phabricator.services.mozilla.com/D48139
--HG--
extra : moz-landing-system : lando
We need to detect this code path in renderer, and call the
legacy draw_color_target method.
Differential Revision: https://phabricator.services.mozilla.com/D48105
--HG--
extra : moz-landing-system : lando
Instead of checking whether the bounds of the clipped
image has changed just check whether our clipped bounds
have changed. This simplifies the code and avoids
a bunch of extra invalidations.
Differential Revision: https://phabricator.services.mozilla.com/D47971
--HG--
extra : moz-landing-system : lando
This can happen if we need to use gfxFontGroup::GetDefaultFont() during stylo traversal,
but we initially failed to create the required font because the font list is stale.
In this case, use a "last-resort" default font entry as a stopgap until the font list
update is completed.
Differential Revision: https://phabricator.services.mozilla.com/D47637
--HG--
extra : moz-landing-system : lando
Previously, picture cache tiles were added to normal batches, and drawn
via the brush_image shader. Since all content is now in picture cache
tiles, we can instead draw the tiles via a separate code path. The tiles
for all picture caches are collected into a single composite config, that
is stored in the Frame structure. These two changes provide a number of
advantages:
* The composite shader is very simple - it doesn't need to deal with
transforms, anti-aliasing, repetition etc.
* Since we create the tile batches in render(), rather than in the
backend, we can take advantage of information not available until
the render() call. For example, Gecko will provide information here
when the partial presentation rects need to be reset. This will be
used to enable partial presentation parameters on Windows.
* In future, we can access this list of tiles to be composited, and use
them to configure the OS compositor integration, and hand the tiles
directly to the OS compositor.
* In future, we can apply global optimizations to the set of picture
cache tiles (e.g. occlude background tiles on CPU to skip paying
the z-reject cost of drawing them).
* In future, we can take advantage of the simpler composite path
for software rasterizer implementations.
Differential Revision: https://phabricator.services.mozilla.com/D47724
--HG--
extra : moz-landing-system : lando
This was added as part of an intermediate step to blob
recoordination. It's not used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D47354
--HG--
extra : moz-landing-system : lando
Before this patch, we only considered the primary screen when deciding
whether or not WebRender should be enabled. This is problematic for
Intel users where we don't want to turn on WebRender for large screens;
several small screens are just as bad as one large screen. Now we sum
the pixel count for all the screens when making this decision.
Differential Revision: https://phabricator.services.mozilla.com/D46066
--HG--
extra : moz-landing-system : lando
This was added as part of an intermediate step to blob
recoordination. It's not used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D47354
--HG--
extra : moz-landing-system : lando
Now that we're painting based on the visible area we need to make sure that we
update the blob when ever the visible area changes. We'll do this by
unconditionally setting the visible area.
Differential Revision: https://phabricator.services.mozilla.com/D47335
--HG--
extra : moz-landing-system : lando
These variants perform significantly faster than the C implementations
according to local testing and that in treeherder. Image decoding is as
much as 40% faster in the most simple cases (solid green PNG image).
Differential Revision: https://phabricator.services.mozilla.com/D46446
--HG--
extra : moz-landing-system : lando
Some image decoders (e.g. PNG) may have a native representation of the
data as RGB, and do not have accelerated methods to transform from RGB
to RGBX/BGRX. Exposing this as part of the swizzle/premultiply methods
allows us to write accelerated versions ourselves in a later patch in
this series.
Differential Revision: https://phabricator.services.mozilla.com/D46445
--HG--
extra : moz-landing-system : lando
The image decoders produce surfaces row by row, so a variant to get a
function pointer to perform swizzle/premultiply operations makes more
ergonomic sense.
Differential Revision: https://phabricator.services.mozilla.com/D46444
--HG--
extra : moz-landing-system : lando
In addition, make sure the descriptor size stays in sync with the visible rect's size.
The descriptor's size stored in the resource cache is pretty much obsolete now, we should be able to clean it up and remove it.
Differential Revision: https://phabricator.services.mozilla.com/D46803
--HG--
extra : moz-landing-system : lando
In addition, make sure the descriptor size stays in sync with the visible rect's size.
The descriptor's size stored in the resource cache is pretty much obsolete now, we should be able to clean it up and remove it.
Differential Revision: https://phabricator.services.mozilla.com/D46803
--HG--
extra : moz-landing-system : lando
When user adjusts the video playback rate, which might cause we sending images in a speed that is faster than the speend we composite images.
In this situation, the frame dropping actually won't cause any visual defect and we also don't want to report this frame dropping to user, because it's not caused by system overloading, it's just our compositor doesn't support compositing images in such a high rate.
Therefore, we should check if the dropped images are caused by system overload or high update rate, and only report the former to user.
Differential Revision: https://phabricator.services.mozilla.com/D46236
--HG--
extra : moz-landing-system : lando
This moves the origin of fallback blobs back to the top left of their display
item bounds. This is what they were before the patches in bug 1568227 and makes
more sense because there's not necessarily a reference frame above the fallback
frame which means that the coordinates of the display item can change without
us wanting to invalidate the interior.
Differential Revision: https://phabricator.services.mozilla.com/D47275
--HG--
extra : moz-landing-system : lando
This removes a lot of old cruft in thebes to instantiate Cairo scaled fonts.
Instead, we only instantiate the Cairo scaled font inside Moz2D when we actually
need it for DrawTargetCairo. This thus gets rid of the duplicated code we had
inside both Moz2D and thebes to deal with Cairo scaled fonts.
Differential Revision: https://phabricator.services.mozilla.com/D47297
--HG--
extra : moz-landing-system : lando
Once this patch lands, all content drawn by WebRender is drawn into
a picture cache surface.
This will incur some extra GPU memory overhead since there are extra
GPU texture buffers. Much of this can be reduced by adding a couple
of simple optimizations in future to detect tiles that are solid
colors only.
With this change, we'll now be able to provide exact dirty rects for
the entire screen without any hacks, and start the work to draw into
OS compositor surfaces directly.
Differential Revision: https://phabricator.services.mozilla.com/D47395
--HG--
extra : moz-landing-system : lando
In addition, make sure the descriptor size stays in sync with the visible rect's size.
The descriptor's size stored in the resource cache is pretty much obsolete now, we should be able to clean it up and remove it.
Differential Revision: https://phabricator.services.mozilla.com/D46803
--HG--
extra : moz-landing-system : lando
This moves the origin of fallback blobs back to the top left of their display
item bounds. This is what they were before the patches in bug 1568227 and makes
more sense because there's not necessarily a reference frame above the fallback
frame which means that the coordinates of the display item can change without
us wanting to invalidate the interior.
Differential Revision: https://phabricator.services.mozilla.com/D47275
--HG--
extra : moz-landing-system : lando
Once this patch lands, all content drawn by WebRender is drawn into
a picture cache surface.
This will incur some extra GPU memory overhead since there are extra
GPU texture buffers. Much of this can be reduced by adding a couple
of simple optimizations in future to detect tiles that are solid
colors only.
With this change, we'll now be able to provide exact dirty rects for
the entire screen without any hacks, and start the work to draw into
OS compositor surfaces directly.
Differential Revision: https://phabricator.services.mozilla.com/D47395
--HG--
extra : moz-landing-system : lando
Once this patch lands, all content drawn by WebRender is drawn into
a picture cache surface.
This will incur some extra GPU memory overhead since there are extra
GPU texture buffers. Much of this can be reduced by adding a couple
of simple optimizations in future to detect tiles that are solid
colors only.
With this change, we'll now be able to provide exact dirty rects for
the entire screen without any hacks, and start the work to draw into
OS compositor surfaces directly.
Differential Revision: https://phabricator.services.mozilla.com/D47395
--HG--
extra : moz-landing-system : lando
This moves the origin of fallback blobs back to the top left of their display
item bounds. This is what they were before the patches in bug 1568227 and makes
more sense because there's not necessarily a reference frame above the fallback
frame which means that the coordinates of the display item can change without
us wanting to invalidate the interior.
Differential Revision: https://phabricator.services.mozilla.com/D47275
--HG--
extra : moz-landing-system : lando
This moves the origin of fallback blobs back to the top left of their display
item bounds. This is what they were before the patches in bug 1568227 and makes
more sense because there's not necessarily a reference frame above the fallback
frame which means that the coordinates of the display item can change without
us wanting to invalidate the interior.
Differential Revision: https://phabricator.services.mozilla.com/D47275
--HG--
extra : moz-landing-system : lando
This layer structure can still occur in cases where we place the RCD-RSF
scroll metadata on the root layer as a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D47655
--HG--
extra : moz-landing-system : lando
The signatures were updated in the previous patch to hand us the raw,
uncopied buffers. This just adjusts the callsites to match.
Differential Revision: https://phabricator.services.mozilla.com/D34653
--HG--
extra : moz-landing-system : lando
On Android, decoded buffers need to be send back to MediaCodec in order to be
rendered and/or recycled. The current mechanism introduced in bug 1299068 only
works for playback(VideoData/VideoSink) but not WebRTC(VideoFrame/VideoOutput).
Move the callback to SurfaceTextureImage because VideoData and VideoFrame both
own that when using MediaCodec, and move the notification to VideoFrameContainer
for both VideoSink and VideoOutput pass frames there for compositing.
Differential Revision: https://phabricator.services.mozilla.com/D45771
--HG--
extra : moz-landing-system : lando
To support NDK r20, wrench needs to be built with a more recent, upstream
(though still unpublished) version of cargo-apk. This has some consequences
which have been adjusted for:
* Gradle is no longer required to build wrench.
* The output apk file paths have changed.
* The apks are now signed automatically.
* The default activity name has changed.
* Android permissions must be explicitly requested.
* We must ensure winit is built with a matching version of android_glue.
Differential Revision: https://phabricator.services.mozilla.com/D47129
--HG--
extra : moz-landing-system : lando
Previously, the setup_picture_caching function was hard coded
to support only a very specific shape of display list. With this
change, flags are added to PrimitiveCluster that can specify
if a picture cache slice should be created before / after this
cluster when picture caching is set up.
The usage of these flags in this patch matches the old behaviour,
so should not have any functional effect.
However, in future we will make use of this functionality to
create picture slices for a number of different use cases, such as:
* Creating cache tiles for the UI.
* Slicing the scene where there are video elements, in order to
allow these to be composited directly by the OS. This may also
apply to WebGL and/or canvas elements.
* Slicing the scene when there is a very large fixed position
background image or other element, to avoid invalidating the
entire tile cache each frame.
Differential Revision: https://phabricator.services.mozilla.com/D46125
--HG--
extra : moz-landing-system : lando
To avoid duplicating information, the comment about lock ordering in
APZCTreeManager.h is also updated to point to the documentation.
Differential Revision: https://phabricator.services.mozilla.com/D47146
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
Before Bug 1570869, new frame was generated if WR does not have a pending frame build task. But since Bug 1570869 fix, there is a case that new frame generation does not happen even when WR does not have a frame build task.
Differential Revision: https://phabricator.services.mozilla.com/D47045
--HG--
extra : moz-landing-system : lando
Move DeviceReset handling before the assert. It is OK, since RendererOGL instance is not re-used after the DeviceReset. It is replaced by a new RendererOGL.
Differential Revision: https://phabricator.services.mozilla.com/D47036
--HG--
extra : moz-landing-system : lando
Previously, the setup_picture_caching function was hard coded
to support only a very specific shape of display list. With this
change, flags are added to PrimitiveCluster that can specify
if a picture cache slice should be created before / after this
cluster when picture caching is set up.
The usage of these flags in this patch matches the old behaviour,
so should not have any functional effect.
However, in future we will make use of this functionality to
create picture slices for a number of different use cases, such as:
* Creating cache tiles for the UI.
* Slicing the scene where there are video elements, in order to
allow these to be composited directly by the OS. This may also
apply to WebGL and/or canvas elements.
* Slicing the scene when there is a very large fixed position
background image or other element, to avoid invalidating the
entire tile cache each frame.
Differential Revision: https://phabricator.services.mozilla.com/D46125
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
Still getting some crash reports on nightly with a 1MB stack. Let's try one more time
with 2MB just to see if we can eliminate those. If this fails, then we may need to consider
more drastic approaches like disabling OMTP in this case.
Differential Revision: https://phabricator.services.mozilla.com/D47080
--HG--
extra : moz-landing-system : lando
This approach does have some stacking issues. The way to fix this would
be to instrument the brush_image shader rather than adding debug rects.
Something like: #ifdef WR_FEATURE_SFW frag.color = vec4(0,1,1,1); #endif
That's slightly more involved though, so I'm going to leave it for now.
Differential Revision: https://phabricator.services.mozilla.com/D47155
--HG--
extra : moz-landing-system : lando
D46944 / bug 1583534 is what fixes the root cause of bug 1528052 by not
having the first call to ResizeReflow have a wrong old size of 0x0.
This removes the code that bug introduces to suppress resize events, which
fixes this bug. I think our behavior now is pretty sane.
In particular, consider the test-case:
<!doctype html>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<a href="" target="_blank">Open me in a separate tab</a>
<pre id="log"></pre>
<script>
// This shouldn't be needed, but otherwise Fenix doesn't show the tooltip on
// longpress...
document.querySelector("a").href = location.href;
function logSize() {
log.innerText += window.innerWidth + "x" + window.innerHeight + "\n";
}
logSize();
onresize = logSize;
</script>
(Hosted at https://crisal.io/tmp/gecko-mobile-resize.html for convenience)
Right now on trunk, when you click the link from GVE or Fenix, we're only
getting an initial size of 0x0 (which is not great, btw), and only after first
paint we get the real device size, but content doesn't get a resize event.
This is obviously wrong, every time the layout viewport changes we should fire
resize events.
Pages that get opened in new tabs and get refreshed when resized may get an
extra reload with this approach, but this seems not avoidable unless widget sets
the viewport size right in advance (which from discussion with snorp and agi
doesn't seem possible in the general case).
What used to happen is that we were triggering a redundant resize reflow from
the initial paint which didn't update the layout viewport (because the content
viewer and co had the right viewport from the previous navigation).
Now that we optimize those away, I think our behavior should be correct.
Differential Revision: https://phabricator.services.mozilla.com/D46956
--HG--
extra : moz-landing-system : lando
In particular, not let ResizeReflow take the old and new size. Most of the
callers pass dummy values anyway.
Instead, use the old size of the layout viewport. This ensures we fire resize
events only if the layout viewport actually changes.
This is important because the first resize of the mobile viewport manager
after a navigation has an "old size" of 0x0, even though the layout viewport
is initialized on presshell initialization to the right size.
Thus, we fire resize events unnecessarily in that case, which is the root cause
for bug 1528052.
To do this, we need to shuffle a bit of code in nsDocumentViewer that deals with
delayed resizes, to set the visible area _and_ invalidate layout, rather than
setting the visible area and _then_ relying on doing a resize reflow.
Further cleanup is possible, though not required for my android resizing fix, so
will do separately.
Differential Revision: https://phabricator.services.mozilla.com/D46944
--HG--
extra : moz-landing-system : lando
It is a preparation of Bug 1460499. It adds RenderDXGITextureHostOGL::GetD3D11Texture2D() for use by dc layer.
Differential Revision: https://phabricator.services.mozilla.com/D46928
--HG--
extra : moz-landing-system : lando
Ricky Stewart
Glenn Watson
Emilio Cobos Álvarez
Sylvestre Ledru
Doug Thayer
Lee Salzman
Tom Ritter
Kris Taeleman
Jeff Muizelaar
Jonathan Kew
Daosheng Mu
Andrew Osmond
thomasmo
Daniel Varga
Jeff Muizelaar
Nicolas Silva
Gurzau Raul
Bogdan Tara
alwu
Oana Pop Rus
Brindusan Cristian
Ryan VanderMeulen
Gabriele Svelto
arthur.iakab
Ciure Andrei
Botond Ballo
Jamie Nicol
Hiroyuki Ikezoe
Dorel Luca
Coroiu Cristina
sotaro
Cosmin Sabou
John Lin
Bobby Holley
Andreea Pavel
Josh Aas