We need to track window compositor state in various cases, when compositor is paused after window creation,
when compositor is paused for hidden window (EGLSurface is missing) and paused compositor when layout is not updated yet
and drawing will lead to incorrect / obsoleted window content.
In this patch we track compositor state by WindowCompositorState atomic enum (because it can be accessed from Compositor thread)
and two private methods (PauseCompositorHiddenWindow and ResumeCompositorHiddenWindow) and two public ones (PauseCompositor() and ResumeCompositor).
Private interface is used by nsWindow when EGLSurface is missing so we can't render to window - it's initial compositor pause and
pause when window is hidden.
Public interface is used by nsWindow and WebRender compositor to disable/enable rendering when window content is updated.
When compositor is disabled by public interface it will be enabled automatically after a timeout (1s) or when content layout is updated.
Changes in the patch:
- Implement GtkCompositorWidget::RemoteLayoutSizeUpdated() to notify GtkCompositorWidget widget about layout size update in content process.
- Track nsWindow compositor state by WindowCompositorState
- Implement nsWindow::PauseCompositorHiddenWindow() and ResumeCompositorHiddenWindow() to handle internal nsWindow states.
- Implement nsWindow::PauseCompositor() and nsWindow::ResumeCompositor() to allow compositor pause/resume during content layout updates.
- Use timeout to resume compositor paused by public interface as a fallback when content is not updated or it takes too long.
Differential Revision: https://phabricator.services.mozilla.com/D121650
- Set mozcontainer scale only when we're going to paint into it.
- Set scale to EGL window with window size update at nsWindow::SetEGLNativeWindowSize().
- Don't fire configure events for scale changes as we handle scale change by OnScaleChanged().
- Remove redundant layout updates from nsWindow::OnScaleChanged().
- Dont pass allocation size to OnScaleChanged() as it's not provided by the Gtk signal.
- Log updates
Differential Revision: https://phabricator.services.mozilla.com/D121649
We're currently using -isysroot as a preprocessor flag and
-Wl,--syslibroot/-Wl,--sysroot as a linker flag, but --sysroot is
generalization of both, so we can use that instead.
Differential Revision: https://phabricator.services.mozilla.com/D121943
They are equivalent, except for the fact that MACOSX_DEPLOYMENT_TARGET
may apply to more processes in a normal build. In practice, all the
processes that matter are covered through compiler flags.
On the opposite end, MACOSX_DEPLOYMENT_TARGET isn't necessary passed in
all cases (like clangd, mach static-analysis, etc.), while compiler
flags are.
Differential Revision: https://phabricator.services.mozilla.com/D122145
This hides the scProfilerMainThreadId detail, and makes for a safer API.
Also, ::profiler_init_main_thread_id() calls ::mozilla::baseprofiler::profiler_init_main_thread_id().
And in non-MOZ_GECKO_PROFILER builds, AUTO_PROFILER_INIT calls profiler_init_main_thread_id(), which makes other main-thread functions usable there (assuming profiler_current_thread_id works).
Differential Revision: https://phabricator.services.mozilla.com/D121695
This patch only shuffles source code around, so that all declarations in {,Base}ProfilerUtils.h are now implemented only in ProfilerUtils.cpp (instead of the different platform-*.cpp), the final generated code should be the same in MOZ_GECKO_PROFILER builds (the default on all our supported platforms).
This simplifies the headers and makes further changes easier.
In non-MOZ_GECKO_PROFILER builds: On supported platforms these functions are now fully defined; Unsupported platforms should all had `getpid()`, but thread ids are null.
So now `profiler_current_process_id()` is available on all platforms, at all tier levels.
Differential Revision: https://phabricator.services.mozilla.com/D121051
An upcoming patch will change the size of ProfilerThreadId, which causes troubles with TracePayload.
Trying to move members around didn't help, I'm guessing some padding remains, which cannot be accounted for by just enumerating member sizes.
The proposed solution is to wrap all members in a macro (so they don't need to be repeated), and create a private struct with these members and a character, in order to find the exact offset at which the name will actually start.
This is uglier, but more flexible, and allows future changes (internal or external) more easily, without having to modify the name-size formula.
Differential Revision: https://phabricator.services.mozilla.com/D121050
Since ProfilerProcessId and ProfilerThreadId (and their NumberTypes) will potentially grow to 64 bits on some platforms (in a later patch), all code that uses them must be able to handle bigger types.
Differential Revision: https://phabricator.services.mozilla.com/D121049
It tries to replace a following NBSP with an ASCII white-space if there is.
However, it calls the scan method with start of the replacing range. Therefore,
the assertion in `GetInclusiveNextNBSPPointIfNeedToReplaceWithASCIIWhiteSpace()`
detects this bug.
Note that this occurs only when updating composition string because it's
called with non-collapsed range only for doing it. Otherwise, selected range
has already been deleted by `HTMLEditor::DeleteSelectionAsSubAction()`.
Unfortunately, I don't have how to make this bug appear. It seems that the
path does nothing in the wild because it tries to replace a first character
of composition string from an NBSP to a normal white-space, but it'll be
replaced with new composition string anyway. Therefore, this patch does not
have new tests.
Differential Revision: https://phabricator.services.mozilla.com/D122182
In an incremental reflow, if a flex item has a valid bsize cache , we
skip its measuring reflow. However, we may still need to set relevant
bsize flags if the flex container is changing its definiteness in the
block-axis. See bug 1611303 comment 2 for an analysis.
This patch is playing safe by always calling SetHasBSizeChange() if we
override bsize for the item. Of course this can be solved in a more
sophisticated way by checking whether the item really has a block-axis
resize, but that means we'll need to duplicate a lot of logic in
FlexItem::NeedsFinalReflow().
Differential Revision: https://phabricator.services.mozilla.com/D122041
As this means stdc++compat also would need to be built when
cross-building for Windows on Linux, we also recurse in the stdc++compat
directory in that case. It was already possible to use
--enable-stdcxx-compat in that configuration, and that wasn't working
(there are other problems that prevent it from working, but we're going
to fix them shortly).
Differential Revision: https://phabricator.services.mozilla.com/D122195
Since the minimum required version of gcc and libstdc++ is 7.1 as of bug
1536848, the _GLIBCXX_RELEASE macro is available on all supported
versions. Which means instead of grabbing the largest version of the
libstdc++ symbols and tweaking for that, we can just tweak for
_GLIBCXX_RELEASE. We also remove the conditions that are always true due
to the versions involved.
Differential Revision: https://phabricator.services.mozilla.com/D122194
This patch implements device-pixel-content-box for ResizeObserver.
GetTargetSize() returns CSS pixels for {border|content}-box, or device
pixels for device-pixel-content-box. We round the device pixel to
integral based on the spec,
https://drafts.csswg.org/resize-observer/#calculate-box-size.
And then we compare the current calculated box sizes and the last updated one
in IsActive().
Besides, the current wpts only use zoom property to verify this, but zoom
property is non-standard and we doesn't supports it, so now we only test the
getter functions for device-pixel-content-box and the subpixel snapping
algorithm (e.g. devicepixel.html) for Gecko in wpts.
Differential Revision: https://phabricator.services.mozilla.com/D120776
LogicalPixelSize is a variant of LogicalSize but it stores pixel values
in floating-point. Now we store LogicalPixelSize in ResizeObservation and
ResizeObserverSize. This makes us easier to introduce device-pixel-content-box.
Differential Revision: https://phabricator.services.mozilla.com/D121155
We will introduce device-pixel-content-box, which is in device-pixel
domain. Therefore, we convert the app units into CSS/device pixel when creating
ResizeObserverSize.
Differential Revision: https://phabricator.services.mozilla.com/D121016
Font inflation isn't required for pages whose viewport is narrow enough that we
don't have to zoom *out* when doing zoom-to-fit.
As the viewport scale is given as a CSSToScreenScale, this means that what we're
actually doing at the moment, though, is comparing the width of the viewport in
CSS pixels to the width of the screen in physical pixels, *without* taking the
default scale on a high-DPI device into account.
This issue affects neither pages using a "width=device-width" viewport (the
IsAutoSizeEnabled() check handles those), nor pages without an explicitly
specified viewport at all (the viewport info returns the minimum zoom level in
that case, i.e. 25 %, which would therefore require a device scale of > 4 in
order for us to erroneously turn off font inflation - even modern phones don't
seem to quite reach *that* sort of pixel density, e.g. a Pixel 5 only reports a
default scale of ~2.73.
For pages with an explicitly sized viewport this can however mean that we turn
off font inflation too early: Slashdot e.g. uses "width=1000", which means that
on a phone with a 720 px screen font inflation is correctly enabled, but on a
different phone squeezing 1080 px into the same physical screen width (i.e.
higher DPI, but *not* a physically larger screen), font inflation is suddenly
and incorrectly turned off.
Differential Revision: https://phabricator.services.mozilla.com/D122059