1491442 - Stand up a present path, preffed-off by default, that uses IOSurface + CoreAnimation

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, enhancement, P2)

Description

[Markus Stange [:mstange]]

This is the first step towards bug 1429522. After this bug, we should have an implementation that:
 - is preffed-off by default
 - uses a single, non-opaque, CoreAnimation layer to cover the entire window
 - is used by CompositorOGL
 - may have glitches during certain window interactions
 - doesn't necessarily use less power than the current implementation.

Comment 1

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch, version 2.

Here's a patch implementing the functionality behind a pref as requested. An opaque layer is used if `gfx.compositor.glcontext.opaque` is set to true.

Comment 2

[Patrick Walton (:pcwalton)]

By the way, I've tested this patch and it seems to solve the window resizing problems, by compositing synchronously in `displayLayer:` just like we do today in `drawRect:`.

Comment 3

[Mark]

Could you push a Try so I can have a play? Thanks

Comment 4

[Markus Stange [:mstange]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=57236ab86ffe8cb226b29178e1538eaeeb799cd8

Comment 5

[Markus Stange [:mstange]]

The pref in this patch is called gfx.core-animation.enabled.

Comment 6

[Mark]

Try build failed I think?

Comment 7

[Markus Stange [:mstange]]

Tried a hacky workaround for the warning that made it fail: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b46d5f626ff6159e09403d2c86bb1a9e47905b5c

Comment 8

[Mark]

Do I have to set 
gfx.core-animation.enabled TRUE
AND 
gfx.compositor.glcontext.opaque TRUE

or just the former?

Comment 9

[Patrick Walton (:pcwalton)]

If you enable `gfx.core-animation.enabled` without `gfx.compositor.glcontext.opaque`, you get a transparent Core Animation layer. If you enable both preferences, you get an opaque Core Animation layer. I would expect enabling both to yield better performance, but you will presently lose vibrancy if you do.

Comment 10

[Mark]

Hmmmm, I only see a smallish reduction in power unlike what you say in bug 1429522 comment 14. When CA is enabled, opaque vs transparent seems to make only a couple of watts difference to GPU power consumption for me. Unlike CA disabled where opaque vs transparent makes a huge difference. For me CA + opaque is still much higher power than !CA + opaque.

I don't know how important this is that this stage because comment 0 says the fix "doesn't necessarily use less power than the current implementation" but as I said in bug 1429522 comment 11 I'd like to understand where all the watts are going at all stages in the process.

So, if what I say is true, why doesn't the opaque CA window match the opaque !CA window for GPU power consumption?



gfx.core-animation.enabled              TRUE      TRUE     FALSE    FALSE     

gfx.compositor.glcontext.opaque         TRUE      FALSE    TRUE     FALSE      

GPU power consumption, watts             12        14       4         15     


MacBookPro11,1 @1440x900, Firefox window covers whole screen, speed scrolling mozilla.org up & down.

Comment 11

[Patrick Walton (:pcwalton)]

I don't know off the top of my head what's going on, but any solution needs this patch as a prerequisite, so I'm not concerned.

Comment 12

[Mark]

Fair enough.

Comment 13

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Persist wantsTitleDrawn window property across HideWindowChrome (full screen mode). r?spohl

This is an existing problem: Whenever you enter DOM fullscreen mode on a
window that has drawsContentsIntoWindowFrame == YES, we drop the information
about whether the title should be shown in the titlebar on top of Gecko's
drawing. Then, when you leave DOM fullscreen again, the freshly-created
ToolbarWindow will have mDrawTitle and titleVisibility set to their default
values: mDrawTitle defaults to NO and titleVisibility defaults to
NSWindowTitleVisible.
The title can be drawn in two different modes:

• If the ChildView is covering the titlebar and drawing it in its OpenGL
  context, the ChildView handles the drawing of the title text. That drawing
  code respects the window's mDrawTitle field, and ignores titleVisibility.
• If Cocoa is drawing the titlebar, it respects the titleVisibility property.
  At the moment, Cocoa's drawing is never visible, because it is covered up by
  the ChildView's OpenGL context. As a consequence, the extraneous title is never
  actually visible on the screen and the bug doesn't actually cause a visible
  glitch.
  Once we use CoreAnimation, Cocoa's drawing will become visible, and the wrong
  value of the titleVisibility property would become apparent.

Comment 14

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Add support for using an IOSurface as the default framebuffer for a GLContextCGL. r?jgilbert

TODO:

• Add docs for why registering / unregistering
• Remove handling of non-registered IOSurfaces, rename to UseRegisteredIOSurfaceForDefaultFramebuffer.
• Move depth buffer part into a separate patch, and also fix the ", true" in the second usage.

Depends on D26403

Comment 15

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Read screenshots from the correct framebuffer when the default framebuffer is overridden. r?mattwoodrow

RenderTargetOGL::Bind on mWindowRenderTarget needs to bind the default framebuffer, not framebuffer 0.

Depends on D26404

Comment 16

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Make WebRender draw into the default framebuffer. r?mattwoodrow

Depends on D26405

Comment 17

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Add interfaces mozilla::layers::NativeLayerRoot and NativeLayer, and add CoreAnimation implementations NativeLayerRootCA and NativeLayerCA. r=jrmuizel

TODO:

• fix typos in comments
• remove commented out debug logging
• compress swap chain when it exceeds 3 and surfaces in the middle become unused

Depends on D26406

Comment 18

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - [WIP] Use MOZIOSurfaceCALayer to render the contents of ChildView, in all compositing modes, behind the gfx.core-animation.enabled pref.

TODO:

• separate out documentation for old stuff
• fix window resizing properly
• invalidateContents -> invalidateForResize

Depends on D26407

Comment 19

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Use NSFullSizeContentViewWindowMask for ToolbarWindows. r?spohl

This gives us two behaviors for free which we were achieving through manual
overrides:

• The content view is sized to cover the entire window frame.
• The window controls are placed on top of the content view (instead of
  underneath it in z-order).

It also forces CoreAnimation layers for the window's entire NSView hierarchy.

NSFullSizeContentViewWindowMask is only available on 10.10 and up, but we still
support 10.9, so we cannot remove the code with the manual overrides just yet.

Depends on D26408

Comment 20

[Markus Stange [:mstange]]

Attachment: Bug 1565668 - Do not override _wantsFloatingTitlebar when using CoreAnimation. r?spohl

Depends on D26409

Comment 21

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Add back-pressure to CompositorOGL. r?sotaro

TODO: Only when UseCoreAnimation().

Depends on D26410

Comment 22

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Add back-pressure to WebRender+OGL by implementing RenderCompositorOGL::WaitForGPU(). r?sotaro

TODO: only when gfxPrefs::UseCoreAnimation().

Depends on D26411

Comment 23

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Create a depth buffer for the default framebuffer of a GLContext that is used with WebRender. r?jgilbert

Depends on D26404

Comment 24

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Make WebRender draw into the default framebuffer. r?mattwoodrow

Depends on D26623

Comment 25

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Add CFTypeRefPtr which is a RefPtr-style smart pointer for CFTypeRef types. r?jrmuizel

Depends on D26405

Comment 26

[Markus Stange [:mstange]]

The patches mostly work but I'm seeing some glitches during window resizes, because OMTC triggers CATransactions on the compositor thread which sometimes race with the window server's knowledge of our window shape. I have a plan to fix them but it'll take me a bit longer to implement it. The two patches in the patch stack which interact with window resizing may require some changes, so I've marked them as WIP and unset the review requests on them.

Comment 27

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Add an off-by-default preference called gfx.core-animation.enabled. r?jrmuizel

This preference doesn't do anything yet but having it at this point in the
patch stack lets me untangle things a bit.

Depends on D30402

Comment 28

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Make BasicCompositor PreRender/PostRender handling more consistent with CompositorOGL / WebRender. r?mattwoodrow

This also makes it so that we can't tear down the ChildView while BasicCompositor compositing is happening.

Depends on D26410

Comment 29

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - [WIP] Let PreRender/PostRender know whether a composite is caused by a sync FlushRendering call.

TODO: This information still needs to be forwarded to WebRender.

Depends on D37915

Comment 30

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - [WIP] Do not clear the invalid region if compositing was canceled because PreRender returned false.

Depends on D37916

Comment 31

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - [WIP] Always composite during flush rendering, even if nothing requested a composite.

If a composite was aborted because PreRender returned false, the composite
scheduler still resets its sense of "composite is needed". If it now receives
a flush rendering call, before this patch it would not trigger a composite.

This patch changes it so that flush rendering always triggers a composite.

I'm planning to use this as follows: During window resizing, while the main
thread is in a "being resizing" state, I want to cancel all "async" composites
and only allow "sync" / "flush rendering" composites, by returning false or
true from PreRender. This avoids overcompositing and makes resizing smoother.

Depends on D37917

Comment 32

[Phabricator Automation]

Comment on attachment 9056299 [details]
Bug 1491442 - Persist wantsTitleDrawn window property across HideWindowChrome (full screen mode). r?spohl

Revision D26403 was moved to bug 1565668. Setting attachment 9056299 [details] to obsolete.

Comment 33

[Phabricator Automation]

Comment on attachment 9056300 [details]
Bug 1491442 - Add support for using an IOSurface as the default framebuffer for a GLContextCGL. r?jgilbert

Revision D26404 was moved to bug 1565668. Setting attachment 9056300 [details] to obsolete.

Comment 34

[Phabricator Automation]

Comment on attachment 9056737 [details]
Bug 1491442 - Create a depth buffer for the default framebuffer of a GLContext that is used with WebRender. r?jgilbert

Revision D26623 was moved to bug 1565668. Setting attachment 9056737 [details] to obsolete.

Comment 35

[Phabricator Automation]

Comment on attachment 9056738 [details]
Bug 1491442 - Make WebRender draw into the default framebuffer. r?mattwoodrow

Revision D26624 was moved to bug 1565668. Setting attachment 9056738 [details] to obsolete.

Comment 36

[Phabricator Automation]

Comment on attachment 9056301 [details]
Bug 1491442 - Read screenshots from the correct framebuffer when the default framebuffer is overridden. r?mattwoodrow

Revision D26405 was moved to bug 1565668. Setting attachment 9056301 [details] to obsolete.

Comment 37

[Phabricator Automation]

Comment on attachment 9063608 [details]
Bug 1491442 - Add CFTypeRefPtr which is a RefPtr-style smart pointer for CFTypeRef types. r?jrmuizel

Revision D30402 was moved to bug 1565668. Setting attachment 9063608 [details] to obsolete.

Comment 38

[Phabricator Automation]

Comment on attachment 9077764 [details]
Bug 1491442 - Add an off-by-default preference called gfx.core-animation.enabled. r?jrmuizel

Revision D37914 was moved to bug 1565668. Setting attachment 9077764 [details] to obsolete.

Comment 39

[Phabricator Automation]

Comment on attachment 9056307 [details]
Bug 1491442 - Add back-pressure to CompositorOGL. r?sotaro

Revision D26411 was moved to bug 1565668. Setting attachment 9056307 [details] to obsolete.

Comment 40

[Phabricator Automation]

Comment on attachment 9056308 [details]
Bug 1491442 - Add back-pressure to WebRender+OGL by implementing RenderCompositorOGL::WaitForGPU(). r?sotaro

Revision D26412 was moved to bug 1565668. Setting attachment 9056308 [details] to obsolete.

Comment 41

[Phabricator Automation]

Comment on attachment 9056306 [details]
Bug 1565668 - Do not override _wantsFloatingTitlebar when using CoreAnimation. r?spohl

Revision D26410 was moved to bug 1565668. Setting attachment 9056306 [details] to obsolete.

Comment 42

[Phabricator Automation]

Comment on attachment 9077765 [details]
Bug 1491442 - Make BasicCompositor PreRender/PostRender handling more consistent with CompositorOGL / WebRender. r?mattwoodrow

Revision D37915 was moved to bug 1565668. Setting attachment 9077765 [details] to obsolete.

Comment 43

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - [WIP] Make sure that window resizing and async compositing never overlap.

Depends on D37920

Comment 44

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Fix up and document mNeedsGLUpdate locking semantics, and remove a stray semicolon. r=mattwoodrow

Depends on D38747

Comment 45

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Fix comments that talk about BasicLayers but intend to say BasicCompositor. r=mattwoodrow

BasicLayers is main thread drawing. BasicCompositor is compositor-thread drawing.

Depends on D38748

Comment 46

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Add some documentation to mPixelHostingView. r=mattwoodrow

Depends on D38749

Comment 47

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Rename preRender/postRender to preRenderGL/postRenderGL.

Depends on D38750

Comment 48

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Remove -[ChildView isUsingOpenGL] and use mUsingOMTCompositor instead. r=mattwoodrow

We always use OMTC when using OpenGL. We also currently always use OpenGL when using OMTC, but that's about to change.

Depends on D38751

Comment 49

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - If CoreAnimation is enabled, don't clip the TitlebarGradientView to rounded corners, and don't draw the title string on top of it. r=mattwoodrow

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.

Depends on D38752

Comment 50

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Disable all non-CoreAnimation rendering paths when gfx.core-animation.enabled is set. r=mattwoodrow

This patch leaves you with empty windows everywhere. We will build the new
rendering paths from the ground up in the upcoming patches.

Depends on D38753

Comment 51

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - When gfx.core-animation.enabled is true, use CoreAnimation for all windows and create an empty layer. r=mattwoodrow

This makes us host an empty layer on mPixelHostingView. It 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.

Depends on D38754

Comment 52

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Create a MOZIOSurfaceCALayer and fill it with content when painting using BasicLayers (which used to go through drawRect).

This makes context menus work. Regular windows are still blank at this point.

Depends on D26407

Comment 53

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Render accelerated windows into mContentLayer, using OMTC.

This makes windows that render using CompositorOGL or WebRender show content.

Depends on D38756

Comment 54

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Support BasicCompositor OMTC rendering in the CoreAnimation path. r=mattwoodrow

Now CoreAnimation supports all rendering paths.

Depends on D38757

Comment 55

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Call SuspendAsyncCATransactions on window focus changes. r=mattwoodrow

There are three cases here: Window opening, window resizing, and window
activeness state change.
Each one of these triggers a CoreAnimation transaction on the main thread. By
default, those transactions do not call our layer's display method because the
layer is not marked 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. This can look glitchy: For window
activeness changes in windows with titlebars, the titlebar would change color
at a different time than the content. And for window resizing it would look
even worse.
Calling markLayerForDisplay will result in a call to displayLayer in the
upcoming CoreAnimation transaction and lets us update the entire window in one
atomic paint.

Depends on D38758

Comment 56

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Disable window overlay drawing in the CoreAnimation path. r=mattwoodrow

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.

Depends on D38759

Comment 57

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - If gfx.compositor.glcontext.opaque is set to true, make the CoreAnimation layer opaque.

This is only a temporary solution. In the near future, we want to split up this
layer into opaque and non-opaque sublayers so that we can have both: vibrancy
in the places that should be vibrant, and efficient compositing in the places
that are actually opaque.

Depends on D38760

Comment 58

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Make reftest readback read from the current render target. r=mattwoodrow

Comment 59

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Add CompositorWidget::DoCompositorCleanup() to give the widget a chance to clean up any state from PreRender/PostRender on the correct thread. r=mattwoodrow

Depends on D40513

Comment 60

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Make nsChildView create a NativeLayerRootCA and fill it with content when painting using BasicLayers (which used to go through drawRect). r=mattwoodrow

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.

Depends on D26407

Comment 61

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Render accelerated windows into mContentLayer, using OMTC. r=mattwoodrow

This makes windows that render using CompositorOGL or WebRender show content.

Depends on D40516

Comment 62

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Make sure to never trigger async CA transactions when the main thread might be resizing a window. r=mattwoodrow

This avoids most window resizing glitches.

Depends on D38758

Comment 63

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Don't handle null render targets in this method. r=mattwoodrow

Comment 64

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Remove call to ReadBuffer. r=jgilbert

Doing so causes GL_INVALID_OPERATION errors:
[gl:0x121a59000] void mozilla::gl::GLContext::fReadBuffer(GLenum): Generated unexpected GL_INVALID_OPERATION error.

Depends on D40550

Comment 65

[Markus Stange [:mstange]]

The patches are fully ready for review now. Unfortunately Bugzilla doesn't display them in the right order, so I recommend looking at the "Stack" view on phabricator to see the correct order.

Try pushes:
CoreAnimation off: https://treeherder.mozilla.org/#/jobs?repo=try&revision=18bc2fd6a4700040643ec22a0661ca2fc593cbe4
CoreAnimation on: https://treeherder.mozilla.org/#/jobs?repo=try&revision=269fd0f81f44a6a97980cb89947c3d2edf116b9e

Both are green except for some intermittents.

Comment 66

[Mark]

The CoreAnimation ON build seems to have WebRender disabled???

ie gfx.webrender.enabled is FALSE when I first launch the try out of the unpacked dmg on my desktop.

Is this intentional? It confused me for a bit.

Comment 67

[Mark]

Maybe ignore previous comment, I'm confused, sorry

Comment 68

[Mark]

As with comment 10, I don't see any GPU power saving with the Core Animation enabled Try build compared with Nightly using the default vibrant window.

1280x800, WebRender OFF, MacBookPro11,1, speed scroll mozilla.org up & down
Nightly, opaque GL context ~4 W GPU
Nightly, transparent GL context ~12 W GPU
CA enabled Try build, sidebar collapsed ~12 W GPU

Chrome --disable-mac-overlays ~4 W GPU

The Core Animation enabled Try build seems to show all the correct behaviors in Quartz Debug eg opaque (green) main content window, vibrant (red) sidebar & tab bar.

Comment 69

[Markus Stange [:mstange]]

Thanks for testing; this is expected. The work in this bug gives us an equivalent implementation to what we had before, but using CoreAnimation. There are no power savings yet. The power savings will come from the work in the follow-up bugs; see the "Depends on" list in bug 1429522 for the full list. (If only it was as simple as flipping a switch... Saving power with CoreAnimation is all about how you use CoreAnimation: How many CoreAnimation layers do you create, how do you distribute your window's contents into these layers, how many of the layers are opaque, how large are the layers that you touch when anything changes, how many changes can you handle by simply moving layers and not repainting their contents, etc. Chrome has done a lot of work to create layers in smart ways, whereas the work in this bug is just the simplest thing that works, because it's only the first step: One transparent layer that covers the entire window.)

A quick note on Quartz Debug, though: Unfortunately, for windows that use CoreAnimation, Quartz Debug's opaque color tinting only works on the window as a whole, and doesn't tint individual layers within the window. So it tints the window green even if the window contains transparent layers in front, on top of the window's opaque background layer. For a more accurate idea of opaque and transparent layers, you can start the Firefox process with the environment variables CA_LAYER_SURFACE=0 CA_COLOR_OPAQUE=1: This will tint the layers within the window. But be aware that doing so will change power consumption characteristics because CA_LAYER_SURFACE=0 causes in-process layer compositing as opposed to the usual out-of-process, within-WindowServer CoreAnimation layer compositing.

Let's keep this bug focused on landing the patches. Once the work to actually save power is further along, I will let you know.

Comment 70

[Mark]

Great. Thanks for the detailed explanation. I'll shut up now :)

Comment 71

[Markus Stange [:mstange]]

Attachment: Bug 1491442 - Fold DoWidgetCleanup and DetachWidget into Compositor::Destroy. r=mattwoodrow

Comment 73

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fb949ba38402
Make reftest readback read from the current render target. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/38705780d7f8
Add CompositorWidget::DoCompositorCleanup() to give the widget a chance to clean up any state from PreRender/PostRender on the correct thread. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/9dcce9060dac
Fold DoWidgetCleanup and DetachWidget into Compositor::Destroy. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/82b63cd1a2d3
Fix up and document mNeedsGLUpdate locking semantics, and remove a stray semicolon. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/9216803cdf01
Fix comments that talk about BasicLayers but intend to say BasicCompositor. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/d66f54731eeb
Add some documentation to mPixelHostingView. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/8e82722106c0
Remove -[ChildView isUsingOpenGL] and use mUsingOMTCompositor instead. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/9ffcdc648de5
If CoreAnimation is enabled, don't clip the TitlebarGradientView to rounded corners, and don't draw the title string on top of it. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/e89c3a6b2cd8
Disable all non-CoreAnimation rendering paths when gfx.core-animation.enabled is set. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/372c720b6ce8
When gfx.core-animation.enabled is true, use CoreAnimation for all windows and create an empty layer. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/cf2547ffbfd4
Add interfaces mozilla::layers::NativeLayerRoot and NativeLayer, and add CoreAnimation implementations NativeLayerRootCA and NativeLayerCA. r=jrmuizel
https://hg.mozilla.org/integration/autoland/rev/7711755e979e
Make nsChildView create a NativeLayerRootCA and fill it with content when painting using BasicLayers (which used to go through drawRect). r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/5aa5080461f8
Render accelerated windows into mContentLayer, using OMTC. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/24dbae685801
Support BasicCompositor OMTC rendering in the CoreAnimation path. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/a5ba77776417
Make sure to never trigger async CA transactions when the main thread might be resizing a window. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/e6e88a4fc6b9
Disable window overlay drawing in the CoreAnimation path. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/706ff8a1badc
Call SuspendAsyncCATransactions on window focus changes. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/ae86a277bd72
Don't handle null render targets in this method. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/0822612163d6
Remove call to ReadBuffer. r=jgilbert

Comment 74

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/03a1e5d857b5
Fix field order. r=fix CLOSED TREE

Comment 75

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/fb949ba38402
https://hg.mozilla.org/mozilla-central/rev/38705780d7f8
https://hg.mozilla.org/mozilla-central/rev/9dcce9060dac
https://hg.mozilla.org/mozilla-central/rev/82b63cd1a2d3
https://hg.mozilla.org/mozilla-central/rev/9216803cdf01
https://hg.mozilla.org/mozilla-central/rev/d66f54731eeb
https://hg.mozilla.org/mozilla-central/rev/8e82722106c0
https://hg.mozilla.org/mozilla-central/rev/9ffcdc648de5
https://hg.mozilla.org/mozilla-central/rev/e89c3a6b2cd8
https://hg.mozilla.org/mozilla-central/rev/372c720b6ce8
https://hg.mozilla.org/mozilla-central/rev/cf2547ffbfd4
https://hg.mozilla.org/mozilla-central/rev/7711755e979e
https://hg.mozilla.org/mozilla-central/rev/5aa5080461f8
https://hg.mozilla.org/mozilla-central/rev/24dbae685801
https://hg.mozilla.org/mozilla-central/rev/a5ba77776417
https://hg.mozilla.org/mozilla-central/rev/e6e88a4fc6b9
https://hg.mozilla.org/mozilla-central/rev/706ff8a1badc
https://hg.mozilla.org/mozilla-central/rev/ae86a277bd72
https://hg.mozilla.org/mozilla-central/rev/0822612163d6
https://hg.mozilla.org/mozilla-central/rev/03a1e5d857b5