To import cubeb-coreaudio-rs crate later, creating a dummy folder in
advance in libcubeb. It should be the mirrow of cubeb-coreaudio-rs crate
on github. The information of cubeb-coreaudio-rs is in README_MOZILLA.
Differential Revision: https://phabricator.services.mozilla.com/D23429
--HG--
extra : moz-landing-system : lando
Since Bug 1531898 fix, fix of Bug 1552734 is not necessary anymore. The backout reduces memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D38257
--HG--
extra : moz-landing-system : lando
CompositorInitiallyPaused() uses mNeedsUpdatingEGLSurface. But it is not good. mNeedsUpdatingEGLSurface is set to true in moz_container_set_initial_draw_callback(). If compositor is created before moz_container_set_initial_draw_callback(), compositor is not initially paused. It happens sometimes with popup window.
Differential Revision: https://phabricator.services.mozilla.com/D38200
--HG--
extra : moz-landing-system : lando
We've been lucky that non-sanitizer cross-builds for macosx have not
required the clang runtime so far, but they soon will. And it's only
available in the mac-cross clang toolchain, so we need to use that on
all macosx builds.
Differential Revision: https://phabricator.services.mozilla.com/D38260
--HG--
extra : moz-landing-system : lando
This patch reverts the previous attempted fix for snapping issues
with picture caching, and implements a better solution.
This fixes the main visual issue by ensuring that any fractional
offset in the root transform is accounted for by:
* Offsetting the tile rects by this amount, so that the content
origin is a whole device pixel.
* Invalidating all tiles if the fractional part of the root
transform changes. This is required since it can affect the
snapping logic that WR applies. Fortunately, this occurs
very rarely - Gecko typically has a constant fractional part
for each page.
Differential Revision: https://phabricator.services.mozilla.com/D38267
--HG--
extra : moz-landing-system : lando
We don't need to run binary checks on the instrumentation builds, only the final optimized build.
Differential Revision: https://phabricator.services.mozilla.com/D38382
--HG--
extra : moz-landing-system : lando
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.
Differential Revision: https://phabricator.services.mozilla.com/D37915
--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/D26412
--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
This preference doesn't do anything yet but having it at this point in the
patch stack lets me untangle things a bit.
Differential Revision: https://phabricator.services.mozilla.com/D37914
--HG--
extra : moz-landing-system : lando
RenderTargetOGL::Bind on mWindowRenderTarget needs to bind the default framebuffer, not framebuffer 0.
Differential Revision: https://phabricator.services.mozilla.com/D26405
--HG--
extra : moz-landing-system : lando
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.
Differential Revision: https://phabricator.services.mozilla.com/D26403
--HG--
extra : moz-landing-system : lando
These configurations are already taken care of in js/src/build/moz.build
and do not need to duplicated.
Depends on D37567
Differential Revision: https://phabricator.services.mozilla.com/D37568
--HG--
extra : moz-landing-system : lando
Consolidate build settings required by standalone builds into a single
mozbuild script. A full Gecko build does not use these settings and thus
we cannot simply put them in js/src/build/moz.build
Differential Revision: https://phabricator.services.mozilla.com/D37567
--HG--
extra : moz-landing-system : lando
Direct use of aInput buffers for ArrayBuffer elements is not possible in
general. aInput buffers are const because they may be used elsewhere but
ArrayBuffer elements may be modified by script. If necessary, it would be
possible to later add a mechanism to mix inputs directly into the ArrayBuffer,
but often no mixing is required.
Direct use of output ArrayBuffer elements would require DetachArrayBuffer to
ensure the elements are not modified by script, but that would require
creation of a new ArrayBuffer JS object on each call.
https://github.com/WebAudio/web-audio-api/issues/1932 tracks specification of
making output data available for reading (for downstream node input).
Differential Revision: https://phabricator.services.mozilla.com/D34837
--HG--
extra : moz-landing-system : lando
We can speed up the getType function by changing the dataType into an object from an array.
That way we avoid looping looking for the matching tagName and namespaceURI and access the typeData directly by their tagName.
Differential Revision: https://phabricator.services.mozilla.com/D38196
The changes made in bug changeset 03e0de747d02 assume that drop() is only called on handlers that have been succesfully set on a DebuggerFrame object, and attempt to remove the memory associated with that object. That logic fails if these are called due to an error during initialisation as is happening here. The patch changes a call to drop() to js_delete() and adds assertions that drop() is only called on handlers that are currently associated.
Differential Revision: https://phabricator.services.mozilla.com/D37874
Chun-Min Chang
Benjamin
sotaro
Shane Caraveo
Emilio Cobos Álvarez
Jan-Ivar Bruaroey
Mike Hommey
Ciure Andrei
Xidorn Quan
Glenn Watson
Eric Rahm
Markus Stange
Tom Ritter
Nicholas Nethercote
Luke Crouch
Geoff Brown
Matt Woodrow
Razvan Maries
Erica Wright
Ted Campbell
sagudev
Karl Tomlinson
Gabriel Luong
Jon Coppeard
Sebastian Hengst
Daniel Varga
Christoph Kerschbaumer
Mirko Brodesser