There's no other caller that sets ReadBuffer to anything else, and GL_BACK is
the default for default framebuffers. Furthermore, this call triggers
GL_INVALID_OPERATION errors when called on a non-default framebuffer.
Differential Revision: https://phabricator.services.mozilla.com/D40551
--HG--
extra : moz-landing-system : lando
Without this, in windows with title bars, such as the bookmark library window,
the title bar and the content would update at different times.
The title bar paint is done as part of a main thread CoreAnimation transaction.
However, by default, we don't get notified of all main thread CA transactions;
our only notification mechanism is the updateLayer handler on the PixelHostingView,
and that handler is only invoked (the layer is only displayed) if the layer has
been marked as needing display. And by default, window focus changes do not mark
random views' backing layers as needing display. Usually, what this means is that
the window will be painted twice: Once in the main thread transaction, and then
another time on the compositor thread once Gecko has noticed a state change and
triggered its own composite in response. (Often, Gecko's compositor-side paint
will actually happen *before* the main thread paint, because the main thread is
often busy with repainting the system menu bar during window focus changes.)
Such non-atomic window repaints look glitchy.
Calling SuspendAsyncCATransactions will result in a call to updateLayer in the
upcoming CoreAnimation transaction and lets us update the entire window in one
atomic paint, and it will avoid updating the window early if the compositor
thread gets ahead of the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D38759
--HG--
extra : moz-landing-system : lando
Window overlay drawing was added as a workaround for the following:
When our NSOpenGLContext covered the entire window, it would cover the titlebar
contents and hide the window buttons and the title string. It would also not
get anti-aliased rounded corner clipping.
In windows that use CoreAnimation layers for the window frame, this is no longer
a problem, because the CoreAnimation layer tree takes care of these effects:
It applies rounded corner clipping to the window content layers, it puts the
window buttons on top, and it also puts the title string on top if it is shown.
So when we're using CoreAnimation, the existing code needs to be deactivated,
otherwise we'd draw those things twice.
Differential Revision: https://phabricator.services.mozilla.com/D38760
--HG--
extra : moz-landing-system : lando
Now CoreAnimation supports all rendering paths.
The BasicCompositor OMTC path is used when hardware acceleration is disabled,
for example in safe mode or when the user manually disabled it.
Differential Revision: https://phabricator.services.mozilla.com/D38758
--HG--
extra : moz-landing-system : lando
This makes windows that render using CompositorOGL or WebRender show content.
Differential Revision: https://phabricator.services.mozilla.com/D40517
--HG--
extra : moz-landing-system : lando
This makes context menus work. Regular windows are still blank at this point.
This introduces a visual regression on 10.9: context menus and panels now no
longer have a shadow. Only 10.10 and above support shadows on transparent windows
that use CoreAnimation; 10.9 is not able to obtain the shadow shape on those
types of windows.
I think this is an acceptable regression to take. We want to use CoreAnimation
for all window types because it simplifies the code (no need to handle two
paths) and because it avoids expensive mode switches if we realize too late
that a window we just opened is supposed to use CoreAnimation.
Differential Revision: https://phabricator.services.mozilla.com/D40516
--HG--
extra : moz-landing-system : lando
NativeLayerRoot and NativeLayer allow building up a flat layer "tree" of sibling
layers. They're created and manipulated with a synchronous-looking API, but any
changes will only be applied to the underlying native layers when ApplyChanges()
is called. This ensures that the modifications can be limited to run within a
CoreAnimation transaction, and on a thread of the caller's choosing.
In the near future I'm planning to have LayerManagerComposite create these
layers. That's the reason for the pseudo-abstracted cross-platform C++ API:
LayerManagerComposite can create and place the layers, and any painting into the
layer surfaces will happen in the compositor implementations with platform-specific
code.
For now, the CoreAnimation implementation is the only implementation. I think
the current API will let us use the same infrastructure for DirectComposite
layers on Windows, but we'll likely need to make some API modifications once we
attempt that.
The classes are threadsafe; their methods can be called on any thread and the
caller is responsible for sufficient synchronization. In reality, there are only
two threads that would have a reason to use these layers: The compositor thread
and the main thread. The main thread creates and destroys the NativeLayerRootCA,
and sometimes it calls ApplyChanges, e.g. during window resizes. It also calls
SetBackingScale. All other methods are usually only called on the compositor
thread.
Differential Revision: https://phabricator.services.mozilla.com/D26407
--HG--
extra : moz-landing-system : lando
This makes mPixelHostingView layer-backed, and that layer will be empty.
This patch also causes all windows (including context menus, tooltips, arrow
panels etc.) to use CoreAnimation layers for the window frame. This is achieved
by calling setWantsLayer:YES on every window's content view.
After this changeset, all windows will still be empty.
Differential Revision: https://phabricator.services.mozilla.com/D38755
--HG--
extra : moz-landing-system : lando
This patch leaves you with empty windows everywhere. We will build the new
rendering paths from the ground up in the upcoming patches.
Differential Revision: https://phabricator.services.mozilla.com/D38754
--HG--
extra : moz-landing-system : lando
Unlike what the old comment in its drawRect method says, this isn't actually
dependent on the NSFullSizeContentViewWindowMask. Any window that uses
CoreAnimation layers for its window frame will apply these effects automatically.
Differential Revision: https://phabricator.services.mozilla.com/D38753
--HG--
extra : moz-landing-system : lando
We always use OMTC when using OpenGL. We also currently always use OpenGL when using OMTC, but that's about to change.
Differential Revision: https://phabricator.services.mozilla.com/D38752
--HG--
extra : moz-landing-system : lando
BasicLayers is main thread drawing. BasicCompositor is compositor-thread drawing.
Differential Revision: https://phabricator.services.mozilla.com/D38749
--HG--
extra : moz-landing-system : lando
This removes the assumption that there is a default framebuffer to read from,
in order to prepare for a world in which all rendering goes into non-default
framebuffers.
The current render target's framebuffer is already bound when this function is
called.
Differential Revision: https://phabricator.services.mozilla.com/D40513
--HG--
extra : moz-landing-system : lando
Bug 1498518 adds credui.dll to use OS's authenticate dialog for WebAuth support, but this isn't required at start up etc. So we should move this to delay load DLL list.
Differential Revision: https://phabricator.services.mozilla.com/D42079
--HG--
extra : moz-landing-system : lando
This one was VarCached to two different variables in two different modules.
Differential Revision: https://phabricator.services.mozilla.com/D41920
--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
These areas only need to be cleared in rt->mDrawTarget. Once the invalid area gets
copied over to mFullWindowRenderTarget, any cleared pixels will be copied over and
clear those pixels in mFullWindowRenderTarget.
This clear wasn't only necessary, it also sometimes cleared to much, because the
clip to the invalid region that the caller sets does not apply to this DrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D41612
--HG--
extra : moz-landing-system : lando
