Closed Bug 1565668 Opened 5 years ago Closed 5 years ago

More preparatory work for CoreAnimation

Categories

(Core :: Graphics, task)

Product:
Core
Component:
Graphics
Platform:
All
macOS
Type:
task
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla70
Tracking Flags:
Tracking Status
firefox70 --- fixed

People

(Reporter: mstange, Assigned: mstange)

References

Details

Attachments

(10 files, 1 obsolete file)

Bug 1565668 - Persist wantsTitleDrawn window property across HideWindowChrome (full screen mode). r?spohl
47 bytes, text/x-phabricator-request
Details | Review
Bug 1565668 - Add support for using an IOSurface as the default framebuffer for a GLContextCGL. r?jgilbert
47 bytes, text/x-phabricator-request
Details | Review
Bug 1565668 - Create a depth buffer for the default framebuffer of a GLContext that is used with WebRender. r?jgilbert
47 bytes, text/x-phabricator-request
Details | Review
Bug 1565668 - Make WebRender draw into the default framebuffer. r?mattwoodrow
47 bytes, text/x-phabricator-request
Details | Review
Bug 1565668 - Read screenshots from the correct framebuffer when the default framebuffer is overridden. r?mattwoodrow
47 bytes, text/x-phabricator-request
Details | Review
Bug 1565668 - Add CFTypeRefPtr which is a RefPtr-style smart pointer for CFTypeRef types. r?jrmuizel
47 bytes, text/x-phabricator-request
Details | Review
Bug 1565668 - Add an off-by-default preference called gfx.core-animation.enabled. r?jrmuizel
47 bytes, text/x-phabricator-request
Details | Review
Bug 1565668 - Add back-pressure to CompositorOGL. r?sotaro
47 bytes, text/x-phabricator-request
Details | Review
Bug 1565668 - Add back-pressure to WebRender+OGL by implementing RenderCompositorOGL::WaitForGPU(). r?sotaro
47 bytes, text/x-phabricator-request
Details | Review
Bug 1565668 - Make BasicCompositor PreRender/PostRender handling more consistent with CompositorOGL / WebRender. r?mattwoodrow
47 bytes, text/x-phabricator-request
Details | Review

Some patches which I initially attached to bug 1491442 are mostly ready to land, but others are not. I'm moving the ones which are ready (or really close to ready) over to this bug so that I can land them sooner.

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.

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

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

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.

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.

This was the order of calls for CompositorOGL+WebRender before this patch:

  • PreRender, calls [mView preRender:]
  • [compositing happens]
  • PostRender, calls [mView postRender:]

And this was the order of calls for BasicCompositor before this patch:

  • PreRender, ignored
  • StartRemoteDrawing(InRegion)
  • [software compositing happens]
  • EndRemoteDrawing, calls [mView preRender:], does a GL composition, then calls [mView postRender:]
  • PostRender, ignored

After this patch, all paths call [mView preRender:] and [mView postRender:] from
PreRender and PostRender.
This changeset also makes it so that we can't tear down the ChildView while
BasicCompositor compositing is happening.

Pushed by mstange@themasta.com:
https://hg.mozilla.org/integration/autoland/rev/0232b3377eaa
Persist wantsTitleDrawn window property across HideWindowChrome (full screen mode). r=spohl
https://hg.mozilla.org/integration/autoland/rev/4c6c75383a8b
Add support for using an IOSurface as the default framebuffer for a GLContextCGL. r=jgilbert
https://hg.mozilla.org/integration/autoland/rev/282ffbb04271
Create a depth buffer for the default framebuffer of a GLContext that is used with WebRender. r=jgilbert
https://hg.mozilla.org/integration/autoland/rev/8f7ea33e4da7
Make WebRender draw into the default framebuffer. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/3764e9dc4465
Read screenshots from the correct framebuffer when the default framebuffer is overridden. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/68b7701e3caf
Add CFTypeRefPtr which is a RefPtr-style smart pointer for CFTypeRef types. r=jrmuizel
https://hg.mozilla.org/integration/autoland/rev/a6a1f3b39709
Add an off-by-default preference called gfx.core-animation.enabled. r=jrmuizel
https://hg.mozilla.org/integration/autoland/rev/70d66bfa68c9
Add back-pressure to CompositorOGL. r=sotaro
https://hg.mozilla.org/integration/autoland/rev/6f08492418a9
Add back-pressure to WebRender+OGL by implementing RenderCompositorOGL::WaitForGPU(). r=sotaro
https://hg.mozilla.org/integration/autoland/rev/2a82b5ce10e2
Do not override _wantsFloatingTitlebar when using CoreAnimation. r=spohl
https://hg.mozilla.org/integration/autoland/rev/8ae139f71dae
Make BasicCompositor PreRender/PostRender handling more consistent with CompositorOGL / WebRender. r=mattwoodrow

Just a heads up: With these patches, there will be a preference called "gfx.core-animation.enabled" showing up on about:config but it won't do anything, other than causing titlebar glitches. No CoreAnimation will be used yet. It needs the rest of the work from bug 1491442 to do anything.

Attachment #9077795 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: