See https://github.com/mathml-refresh/mathml/issues/22
* mathml/relations/css-styling/attribute-mapping-001.html (length, dir)
* mathml/relations/html5-tree/display-1.html (display)
* mathml/relations/css-styling/displaystyle-1.html (displaystyle)
* mathml/relations/css-styling/displaystyle-2.html (displaystyle)
* mathml/relations/css-styling/mathvariant-case-sensitivity.html (mathvariant)
layout/reftests/bugs/355548-3.xml has been updated now that units are case
insensitive.
Note:
* mathml/relations/css-styling/attribute-mapping-002.html also checks
case insensitiveness of mathvariant and displaystyle but for now we map
these attributes to internal -moz-* CSS properties.
* mathcolor and mathbackground values are already case insensitive, this
is verified by mathml/relations/css-styling/attribute-mapping-001.html
Differential Revision: https://phabricator.services.mozilla.com/D42081
--HG--
extra : moz-landing-system : lando
In practice the Reader doesn't need to be copied/moved/reassign.
BlocksRingBuffer::Read() can just instantiate one on the stack, and pass it by
reference to callbacks.
Differential Revision: https://phabricator.services.mozilla.com/D42118
--HG--
extra : moz-landing-system : lando
The point of the EntryReserver was mainly to have an object that represented a
writing lock on BlocksRingBuffer, so potentially perform multiple consecutive
writes.
After some experience implementing bug 1562604, there's actually no need for it.
So instead of having `Put()` create an `EntryReserver`, we now have
`ReserveAndPut()` that does the whole work in one function.
Differential Revision: https://phabricator.services.mozilla.com/D42116
--HG--
extra : moz-landing-system : lando
EntryWriter doesn't even need to be moveable, as BlocksRingBuffer can just
create one on the stack, and pass it by reference to callbacks.
This removes risks, and potential data copies.
Differential Revision: https://phabricator.services.mozilla.com/D42115
--HG--
extra : moz-landing-system : lando
This seems to make a big difference when running tests with WARP.
e.g. Assertion failure: frameInfo.mDocFramesSeen == frameInfo.mDocFramesTotal,
at z:/build/build/src/gfx/webrender_bindings/RenderThread.cpp:303
and various other browser chrome test failures.
The original problem that added this flag only impacted AMD hardware as I
recall and we are unlikely to ever be running on WARP in production anyways.
When WARP is forced we also don't disable INTERNAL_THREADING_OPTIMIZATIONS.
Differential Revision: https://phabricator.services.mozilla.com/D42214
--HG--
extra : moz-landing-system : lando
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
