To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. Do that by transimitting the vsync rate `SendNotify()`.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Depends on D98254
Differential Revision: https://phabricator.services.mozilla.com/D93173
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. Do that by transimitting the vsync rate `SendNotify()`.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. Do that by transimitting the vsync rate `SendNotify()`.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. When using PVsync, limit updates to once in every
250ms in order to minimize overhead while still updating fast.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. When using PVsync, limit updates to once in every
250ms in order to minimize overhead while still updating fast.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. When using PVsync, limit updates to once in every
250ms in order to minimize overhead while still updating fast.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
RenderFrame is a very poor name for what this class does. RemoteLayerTreeOwner
isn't perfect (it's not the only thing that owns layer trees), but it's
hopefully clearer.
Differential Revision: https://phabricator.services.mozilla.com/D33564
--HG--
rename : layout/ipc/RenderFrame.cpp => layout/ipc/RemoteLayerTreeOwner.cpp
rename : layout/ipc/RenderFrame.h => layout/ipc/RemoteLayerTreeOwner.h
extra : rebase_source : 890e54b93f5979a2430c35028110aa7f2091c550
extra : source : f50dd4cde03beb99ed27397e06f81748ae87b727
extra : histedit_source : 2d7eed25156829b2502f1712880df962a781adcf
nsDisplayRemote no longer has any direct ties to RenderFrame and should
be moved to nsSubDocumentFrame.cpp where it's actually used/created.
Differential Revision: https://phabricator.services.mozilla.com/D33563
--HG--
extra : rebase_source : ae2e03108820bd14b5f2771da17cabfd95706f94
extra : source : b301161ab461cd46cea3f91749896686c50e9b9f
extra : histedit_source : 1c80f83d26734e56bd6353f0a50dcbc4bf894b4b
The nsDisplayListBuilder bits were added in the previous commit.
Differential Revision: https://phabricator.services.mozilla.com/D32477
--HG--
extra : rebase_source : aec41ccaaab4c99b11ed94baf908d1ec61eaee31
extra : intermediate-source : bbcfdcc12774c1b8d78c6420614141382fed3d40
extra : source : 489c8d663f7f63ea32d3eb2226d45a84e51aabe8
WebRender support will be finished in the following commit.
Differential Revision: https://phabricator.services.mozilla.com/D32476
--HG--
extra : rebase_source : f40ab9946e946d137aa2522f9fce0aa268e22937
extra : intermediate-source : ea63d3d6b85fd3c4456275638e968e0eed045b37
extra : source : 79be6c27e0f9e262b75723c120786e2256ee4700
Move ApplyOpacity(), CanApplyOpacity(), Paint() and PaintWithClip() methods to nsPaintedDisplayItem
Differential Revision: https://phabricator.services.mozilla.com/D30225
--HG--
extra : moz-landing-system : lando
To avoid expensive virtual dispatch in PreProcessDisplayList().
Depends on D24460
Differential Revision: https://phabricator.services.mozilla.com/D26136
--HG--
extra : moz-landing-system : lando
To avoid expensive virtual dispatch in PreProcessDisplayList().
Depends on D24460
Differential Revision: https://phabricator.services.mozilla.com/D26136
--HG--
extra : moz-landing-system : lando
Except retrieving from weak reference, `nsIFrame` should treat
`mozilla::PresShell` directly rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D26388
--HG--
extra : moz-landing-system : lando
These casts are now unnecessary after Part 2, due to all consumers directly
using `ContentParent`.
Depends on D20551
Differential Revision: https://phabricator.services.mozilla.com/D20552
--HG--
extra : moz-landing-system : lando
These casts are now unnecessary after Part 2, due to all consumers directly
using `ContentParent`.
Depends on D20551
Differential Revision: https://phabricator.services.mozilla.com/D20552
--HG--
extra : moz-landing-system : lando
This commit removes the dependency on RenderFrame from nsDisplayRemote so that
it can work in child processes with remote subframes. Instead nsDisplayRemote
now works with an nsFrameLoader, which will return the LayerId from either
the RenderFrame (for top-level remote browsers), or from RemoteFrameChild
(for remote subframes).
Differential Revision: https://phabricator.services.mozilla.com/D17448
--HG--
extra : source : 1e1b5cd23412a85fad19ab8ec5aacf31b3a9c9b6
extra : intermediate-source : a62c029510315d109faa9edb31216014e7c70367
extra : histedit_source : 3df246e632fbb71f731c856779e0d2201b3673a3
A TabParent for a remote subframe will have the same owner content as the top-level
remote browser. This means that 'TabParent::GetFrameLoader()' will return the
frame loader of the top-level remote browser.
This is fine for getting the layer manager and compositor for connecting layer trees,
but the frame loader is also used to acquire a TabParent for its process ID. This
is incorrect in the remote subframe case, and will lead to the compositor rejecting
layer transactions for the remote subframe because it will only accept them from
the top-level remote browser's process.
This commit switches RenderFrame to just hold on to TabParent, and acquire the
nsFrameLoader as necessary.
Another change is to RenderFrame::SetOwnerContent. Previously this method would
take the new owner content and check an assertion. I don't see much value in the
assertion, so I've removed it. Additionally, now that we acquire the owner content,
and therefore the layer manager, from TabParent, we need to ensure that
RenderFrame::SetOwnerContent is ran after the TabParent has had it's owner content
updated. So the callsite has been moved into TabParent. This resolved a test failure
with frame loader swapping.
Differential Revision: https://phabricator.services.mozilla.com/D17447
--HG--
extra : source : 4c85fb68f2ed297828bf4646301c2d80d1c8e0a1
extra : intermediate-source : 62ad54fb95eb76f88865f43da1a5d556421e7884
extra : histedit_source : 6b7085118bca83433b26fcec3983a385bd536672
The documentation for these pieces are a bit out of date.
Differential Revision: https://phabricator.services.mozilla.com/D17446
--HG--
extra : source : ba62cc27c32f4d8a3fefff8eee5bf47d270130bc
extra : intermediate-source : caafb04b7dd44d607adfa1f5f5cabcd42e367cf4
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
