gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
--HG--
extra : moz-landing-system : lando
There are multiple SurfacePools: Main thread painting and the non-WebRender compositors create a new pool per window, and WebRender creates one shared pool across all windows. The non-WebRender users set the pool size limit to zero, i.e. no recycling across paints. This preserves the pre-existing behavior.
WebRender's pool size is configurable with the gfx.webrender.compositor.surface-pool-size pref.
Every window holds on to a SurfacePoolHandle. A SurfacePoolHandle has an owning reference to the pool, via a surface pool wrapper. Once all handles are gone, the surface pool goes away, too.
The SurfacePool holds on to IOSurfaces and MozFramebuffers. Both are created on demand, independently, but are associated with each other.
A given NativeLayer uses only one surface pool handle during its lifetime. The native layer no longer influences which GLContext its framebuffers are created for; the GL context is now managed by the surface pool handle.
As a result, a NativeLayer can no longer change which GLContext its framebuffers are created by.
So in the future, if we ever need to migrate a window frome one GLContext to another, we will need to recreate the NativeLayers inside it. I think that's ok.
Differential Revision: https://phabricator.services.mozilla.com/D54859
--HG--
extra : moz-landing-system : lando
This removes any *TargetContext methods from the Compositor interface and moves
mTarget tracking into the compositor implementations.
Differential Revision: https://phabricator.services.mozilla.com/D43872
--HG--
extra : moz-landing-system : lando
In the end we want to have BeginFrameForWindow, BeginFrameForTarget, and
BeginFrameForNativeLayers, the latter with multiple Begin/EndRenderingToNativeLayer
pairs nested inside.
This is the first step.
CompositorOGL and CompositorD3D11 keep their internal BeginFrame method but make
it private.
Differential Revision: https://phabricator.services.mozilla.com/D43871
--HG--
extra : moz-landing-system : lando
Whenever *aRenderBoundsOut was non-empty and aClipRectOut was non-null,
*aClipRectOut was set to the same value as *aRenderBoundsOut.
Depends on D43368
Differential Revision: https://phabricator.services.mozilla.com/D43369
--HG--
extra : moz-landing-system : lando
It looks like a big patch but it's mostly just moved code, with some duplication:
- Layer creation and destruction moves to LayerManagerComposite and RendererOGL.
- BasicCompositor IOSurface setup code moves to BasicCompositor.cpp.
- OpenGL IOSurface setup code moves to CompositorOGL and RenderCompositorOGL.
The duplication is a bit unfortunate but the LayerManagerComposite code will
diverge from the WebRender code soon.
BeginFrame gets a new argument aNativeLayer. This argument will go away again
over the course of this patch queue. But for now, BeginFrame is the best place
to do the layer setup because it's a very close place to PreRender which is
where that code was previously.
I wasn't able to think of a nice way to give CompositorOGL and BasicCompositor
platform-specific behavior without #ifdefs. So now LayerManagerComposite uses
the "cross-platform" NativeLayer interface, but CompositorOGL and
BasicCompositor use NativeLayerCA because they actually need the IOSurface, and
they do that in #ifdef'd code.
Luckily, NativeLayerCA.h can be included in both .cpp files and in .mm files.
Differential Revision: https://phabricator.services.mozilla.com/D42402
--HG--
extra : moz-landing-system : lando
In the past, mFullWindowRenderTarget was updated in EndFrame, so the captured
screenshots (which were captured before EndFrame) were always one frame behind.
This affected both profiler screenshots and window recording screenshots.
This also fixes a bug with the destination offset in the call to
mFullWindowRenderTarget->mDrawTarget->CopySurface(): In the case where mTarget
was non-null, those calls would use mTargetBounds.TopLeft() as the destination
offset, which is very much unrelated to anything in mFullWindowRenderTarget.
Now the destination offset for mFullWindowRenderTarget is always zero -
mFullWindowRenderTarget->mDrawTarget's device space is the same as window space.
This patch also moves the creation of mFullWindowRenderTarget down to where we
have mRenderTarget->mDrawTarget, so that we can create a DrawTarget of a type
that can efficiently copy from mRenderTarget->mDrawTarget. I think this is
important on Windows where mRenderTarget->mDrawTarget will be the Cairo/pixman
re-wrapped DrawTarget and mDrawTarget is some kind of Windows/GDI DrawTarget.
Depends on D41612
Differential Revision: https://phabricator.services.mozilla.com/D41613
--HG--
extra : moz-landing-system : lando
Without CoreAnimation, back-pressure was applied by SwapBuffers: On a
double-buffered NSOpenGLContext which is bound to an NSView, [context flushBuffer]
waits for the previous frame to be finished. With CoreAnimation, the context
is no longer bound to an NSView, and SwapBuffers acts as a regular glFlush.
glFlush on its own does not prevent overproduction.
If we submit GPU work at a faster rate than the GPU can handle, we end up
delaying the window server's GPU work. This can cause the window server to skip
frames. So even if Gecko can produce frames at 60FPS, the window server might
only present those frames at 30FPS, skipping every second frame.
Differential Revision: https://phabricator.services.mozilla.com/D26411
--HG--
extra : moz-landing-system : lando
ImageBridgeChild has only one global TextureFactoryIdentifier. When WebRender is enabled, it is used for both WebRender widget and non-WebRender(BasicCompositor) widget. WebRenderImageHost and ImageHost are incompatible and WebRenderTextureHost does not permit to be consumed on compositor thread. Then it does not work well for non-WebRender widget. To address the problem at ImageContainer, ImageContainer needs to know a connected widget type. It is not easy in some cases like WebRTC. Then host side could address the problem easier.
CompositableParentManager::FindCompositable() is changed to permit transform from WebRenderImageHost to ImageHost if it is necessary when WebRenderImageHost belongs to ImageBridge.
WebRenderTextureHost is changed to permit to consume wrapped TextureHost on compositor thread. If the wrapped TextureHost is BufferTextureHost, it is possible to comsume the TextureHost on compositor and on RenderThread, since they are memory buffer or shared memory buffer. WebRTC code always create BufferTextureHost for video frame. Then it works.
Differential Revision: https://phabricator.services.mozilla.com/D34132
--HG--
extra : moz-landing-system : lando
CompositorD3D11's implementation of `GetWindowRenderTarget` would return a
`nullptr` if we were not presently recording a profile with screenshots. Now,
CompositorD3D11 correctly will return a window render target when it has been
asked to by the `LayerManagerComposite` via `Compositor::RequestRecordFrames`.
Differential Revision: https://phabricator.services.mozilla.com/D29369
--HG--
extra : moz-landing-system : lando
The LayerManagerComposite can now request its compositor to record frames
(i.e., ensure there is a window render target). For all compositors except
BasicCompositor, this is a no-op since they already always have one.
Now the BasicCompositor keeps track of whether or not should be recording
frames based on this request from the LayerManagerComposite and information
about the profiler. This also has the benefit of cleaning up some of the code
that was conditionally compiled only on platforms that support the profiler.
Differential Revision: https://phabricator.services.mozilla.com/D27963
--HG--
extra : moz-landing-system : lando
Composition recording is now supported by the LayerManagerComposite using the
AsyncReadbackBuffer infrastructure provided by the compositor screenshots work.
This enables composition recording for LayerManagerComposite with all
compositors *except* BasicCompositor, since it does not always have a window
render target (it only keeps one around while the profiler is running and
collecting screenshots).
Differential Revision: https://phabricator.services.mozilla.com/D27820
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
The sampler thread is similar to the controller thread in that it doesn't
correspond to a particular actual thread, but instead introduces an
abstraction that allows us to reason about code flow and data ownership
that is logically grouped on a single thread. For now the sampler thread
remains mapped to the compositor thread, but eventually we will allow
it to be render backend thread when webrender is enabled.
MozReview-Commit-ID: D6i2t5lDvkv
--HG--
extra : rebase_source : 06211ad878973c76ca3fd618386bbbd0cfdd4821
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b
This patch was automatically generated. I found the files to be fixed in this
patch with the following command:
grep -r "^\* This Source Code" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
###
line1="\* This Source Code Form is subject to the terms of the Mozilla Public"
line2="\* License, v\. 2\.0\. If a copy of the MPL was not distributed with this"
line3="\* file, You can obtain one at http://mozilla\.org/MPL/2\.0/\. \*/"
# Insert 1 space at beginning:
sed -i s%"^$line1"%" $line1"% $1
sed -i s%"^$line2"%" $line2"% $1
sed -i s%"^$line3"%" $line3"% $1
###
MozReview-Commit-ID: HXBMrfnhlVr
--HG--
extra : rebase_source : de4c78563711f8366e2978c5199a5041875fbe38
This extracts a BaseMatrix template of which Matrix is now a particular
specialization. The BaseMatrix allows us to reuse the same code for
floats and doubles, much like the other "base" classes (BasePoint,
BaseRect, etc.).
MozReview-Commit-ID: HO7bA83S9E0
--HG--
extra : rebase_source : dcd84d9a978cdea00bb54eb11eefcca9c6635901
This introduces two new statistics to the overlay. The first is the ratio of
pixel shader invocations (as determined by the GPU) to the number of pixels we
determined need to be redrawn. The ideal ratio is 1.0, indicating that we
filled every pixel exactly once. Anything over 1.0 indicates overdraw.
We also add the ratio of shaded pixels to window size. This indicates how well
we computed the invalid region, and whether or not we overfilled that
region.
Note that the OpenGL and Basic compositors do not yet query the GPU for
this statistic, so they will estimate shader invocations by the area of
DrawQuad calls.
Finally, we remove the feature where layout can request the most
recent overdraw statistic. It was not implemented on all compositors, and the
only test that used it was disabled.
--HG--
extra : rebase_source : 448a162998921974575a1a988bcfde52c959d3ed
Andrew Osmond
Markus Stange
sotaro
Barret Rennie
Jean-Yves Avenard
Sylvestre Ledru
Emilio Cobos Álvarez
Kartikaya Gupta
Daniel Holbert
David Anderson
Sebastian Hengst
Miko Mynttinen
David Anderson
Kevin Chen
Morris Tseng