X11-only: CPU usage does not decline if window is open but hidden behind others
Categories
(Core :: Widget: Gtk, defect, P5)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox123 | --- | fixed |
People
(Reporter: jeanluc.malet, Assigned: emilio)
References
Details
Attachments
(6 files, 1 obsolete file)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0
Steps to reproduce:
What steps will reproduce the problem?
(1) open lot of tabs in many windows (I commonly have 189tabs in 22 windows)
exemple of tabs to open that consume CPU/GPU even if not displayed :
https://www.leroymerlin.fr/produits/materiaux/bardage-et-facade/bardage-bois/?sort=price-asc&page=1
https://www.leroymerlin.fr/produits/materiaux/bois-de-charpente-bois-brut-et-dalle-de-construction/ossature-bois-et-bois-de-charpente/?filters=%7B%22type-de-produit%22%3A%22Poutre%22%7D&page=1
https://www.leroymerlin.fr/produits/materiaux/bois-de-charpente-bois-brut-et-dalle-de-construction/ossature-bois-et-bois-de-charpente/poteau-et-poutre/poutre-pin-traite-et-rabote-90x90-mm-longueur-3-m-choix-2-classe-4-70612052.html
https://www.leroymerlin.fr/produits/materiaux/bois-de-charpente-bois-brut-et-dalle-de-construction/ossature-bois-et-bois-de-charpente/poteau-et-poutre/poutre-chene-traite-150x150-mm-longueur-3-m-choix-2-67006912.html
https://www.leroymerlin.fr/v3/p/produits/lame-polyvalente-epicea-vert-isb-st-laurent-2-5-m-e53410
https://www.leroymerlin.fr/v3/p/produits/lame-pin-vert-isb-striee-2-5-m-e1500719187
(2) open system task manager and firefox task manager
(3) choose a tab that have no javascript or reduce all firefox windows
Actual results:
CPU + GPU are overconsummed... seems that even tab that have no focus or windows not focused still render frames, what the purpose of rendering frames of something not visible? this is power inefficient, create user lags, and reduce user perception of fast browser
here the output of top :
1962 XXX 20 0 8327636 3.7g 2.1g S 44.1 23.6 19:50.79 firefox-bin
4128 XXX 20 0 3337184 778912 384340 R 35.5 4.8 8:25.98 Web Content
5562 XXX 20 0 3240476 644068 422152 S 19.4 4.0 4:50.95 Web Content
4457 XXX 20 0 3456036 907308 649444 S 13.2 5.6 8:20.67 Web Content
19219 XXX 20 0 1283144 7548 5496 S 7.2 0.0 94:32.80 pulseaudio
4004 XXX 20 0 1861356 1.1g 1.1g S 6.6 7.0 121:14.17 X
26169 XXX 20 0 5686796 2.4g 51560 S 5.6 15.3 9:51.41 openshot-qt
4190 XXX 20 0 3406416 870316 712760 S 4.9 5.3 1:55.23 Web Content
4260 XXX 20 0 2822784 416288 240672 S 4.9 2.6 1:26.21 Web Content
2240 XXX 20 0 2921128 430880 287116 S 4.3 2.6 0:48.11 Web Content
24354 XXX 20 0 111052 13472 11036 S 2.0 0.1 1:31.29 gkrellm
Expected results:
=> CPU can be eated by javascript updates, so a minor CPU usage should occurs (I don't think that modifying some html content should consume more than 1% on a modern CPU, or even an older one...)
=> Web Content Proceses on task manager should be 0 (no update of current page) or near 0 (minor network usage and minor update)
|
Reporter | |
Comment 1•4 years ago
|
||
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1962 jlm 20 0 8530284 3.7g 2.1g S 46.2 23.7 23:26.08 firefox-bin
4128 jlm 20 0 3337184 775776 384340 R 35.0 4.8 10:54.82 Web Content
4457 jlm 20 0 3464224 933120 649444 R 24.8 5.7 10:43.15 Web Content
5562 jlm 20 0 3240476 642704 422152 S 17.8 3.9 6:10.34 Web Content
4004 jlm 20 0 1838936 1.1g 1.1g S 6.6 7.0 121:38.03 X
19219 jlm 20 0 1283144 7548 5496 S 6.3 0.0 95:02.19 pulseaudio
26169 jlm 20 0 5686796 2.4g 51560 S 5.3 15.3 10:15.05 openshot-qt
4260 jlm 20 0 2822784 411616 240672 S 5.0 2.5 1:47.85 Web Content
2240 jlm 20 0 2951560 471968 315016 S 4.6 2.9 1:15.99 Web Content
4190 jlm 20 0 3406416 870220 712760 S 4.3 5.3 2:15.18 Web Content
3825 root 20 0 1120392 736 0 S 2.3 0.0 45:02.69 veracrypt
24354 jlm 20 0 111052 13472 11036 S 2.0 0.1 1:39.58 gkrellm
19575 jlm 20 0 593648 22184 13184 S 1.7 0.1 52:36.23 pavucontrol
27444 jlm 20 0 9524 2748 1832 S 1.7 0.0 0:47.90 top
2784 root -51 0 0 0 0 D 1.3 0.0 50:01.75 irq/87-ITE8396:
3554 jlm 20 0 12.5g 85908 37952 S 1.3 0.5 32:42.40 chrome
|
||
Updated•4 years ago
|
|
||
Comment 2•4 years ago
|
||
Reporter, would you mind to create a gecko profile that might show us what's going on? Here some instructions in how to do that:
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem
Thanks!
|
|
Reporter | |
Comment 3•4 years ago
|
||
yes, no problem, what are the sensitive information that might be gathered by the profile? eg do I have to close sensitive (mail...) tabs?
|
|
||
Comment 4•4 years ago
|
||
When uploading the profile just untick each and every checkbox within the panel. It will obfuscate all privacy related data.
|
|
Reporter | |
Comment 5•4 years ago
|
||
|
|
||
Comment 6•4 years ago
|
||
As it looks like the LayerManagerComposite::Render method of the compositor thread uses a lot of CPU. Maybe it's related to the two content processes (32226, 32309) that also show a high GFX related activity.
Markus mind having a look at it?
|
||
Comment 7•4 years ago
|
||
We're busy painting animations in the active tab of each window. I think we treat all windows as visible on Linux. We would need to add code to detect occluded windows on Linux.
If you minimize all the windows that you don't use, I think the CPU usage will be lower.
|
|
||
Comment 8•4 years ago
|
||
Are there APIs to check whether a window is fully obscured on Linux (and be notified when this status changes)? If so, we should try using them and call mWidgetListener->OcclusionStateChanged(occluded) like we do on macOS.
|
|
||
Updated•4 years ago
|
|
||
Comment 9•4 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #8)
Are there APIs to check whether a window is fully obscured on Linux (and be notified when this status changes)? If so, we should try using them and call
mWidgetListener->OcclusionStateChanged(occluded)like we do on macOS.
- on X11: no and there's no way to fix that
- on Wayland: yes, but without notification. It's build into the base protocol: we request frame callbacks and only paint if we get them. Pretty much like
Window.requestAnimationFrame(). We enabled it in 86, see bug 1629140 and bug 1645528
|
|
||
Comment 10•4 years ago
|
||
P.S.: in the past there used to be such and API on X11 and we also used it, but it has been broken for a while: https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-visibility-notify-event (removed in bug 1654687)
|
||
Comment 11•4 years ago
|
||
On Wayland I think we may use the frame callbacks to detect active/inactive windows somehow. We already know if a window has focus, when we don't have focus and we don't get frame callback in some reasonable time frame (say half of sec) we can mark the window as inactive until we gain focus again or receive a frame callback.
|
|
Reporter | |
Comment 12•4 years ago
|
||
|
|
||
Comment 13•4 years ago
|
||
Robert, do you know if we can get frame callback info from GL backend? It may be pretty easy to get it from SW one but I'm not sure how to receive it from WebRender. May be integrated to our vsync code perhaps. OTOH we should still get ::draw Gtk signal when a part of GtkWindow needs an update, don't we? Or is that bypassed by GL backend somehow?
|
|
Reporter | |
Comment 14•4 years ago
|
||
thinks you need this => https://tronche.com/gui/x/xlib/events/window-state-change/visibility.html#XVisibilityEvent
|
|
||
Comment 15•4 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #11)
On Wayland I think we may use the frame callbacks to detect active/inactive windows somehow. We already know if a window has focus, when we don't have focus and we don't get frame callback in some reasonable time frame (say half of sec) we can mark the window as inactive until we gain focus again or receive a frame callback.
Yeah, I suppose it should be possible to get this into WaylandVsyncSource. In 86 on Wayland we already reduce the overhead quite a bit as we stop painting without frame callbacks, but it could be that we can save more cycles on the JS site by calling mWidgetListener->OcclusionStateChanged(occluded).
Robert, do you know if we can get frame callback info from GL backend? It may be pretty easy to get it from SW one but I'm not sure how to receive it from WebRender. May be integrated to our vsync code perhaps.
Our WaylandVsyncSource integrates with the general NotifyVsync() - maybe we can use that signal somehow?
OTOH we should still get ::draw Gtk signal when a part of GtkWindow needs an update, don't we? Or is that bypassed by GL backend somehow?
AFAIK we completely bypass that on the GL backend. GTK will only redraw when we actively ask it (e.g. in MozContainerWayland) or on resizes and such.
thinks you need this => https://tronche.com/gui/x/xlib/events/window-state-change/visibility.html#XVisibilityEvent
That's the one I was referring to in comment 10 - unfortunately it's not reliable on composited WMs and thus deprecated. AFAIK any occlusion detection on X11 is simply broken beyond repair, like so many other things.
|
|
Reporter | |
Comment 16•4 years ago
|
||
well... in a way, I don't use a composited WM.... so it's selfish but I don't care if broken WM eats CPU... that's the problem of the broken composite WM if they break the occlusion detection and make the user have a i7 behave as a i486....
in a way, this isn't your problem too... if a WM wants to report a window as visible to force a refresh, you have to comply to the requirement.... user have to fill bug on the WM to break complience with X11 standard....
VSync on OpenGl... I tested with glxgears, and imgui glw on opengl3.... both are consuming same CPU if displayed or not.... so you can't detect if you're displayed or not using the VSYNC, Vsync event are related to hw screen.... both app don't perform computing but just display so, they are good hints to know if obfuscating the window (eg they don't require redraw) will "block" the sync event....
one things can be also to test for _NET_CURRENT_DESKTOP => all windows that aren't on current destkop are off course obfuscated
other thing :
xwininfo
xwininfo: Please select the window about which you
would like information by clicking the
mouse in that window.
xwininfo: Window id: 0x18000a8 "Root Window Properties (and Related Messages) — Mozilla Firefox"
....
Map State: IsViewable
....
=> can the map state be used to detect visibility?
|
|
Reporter | |
Comment 17•4 years ago
|
||
I made some test with xwinfo,
- I select the firefox window that I can see on screen, Map sate is "IsViewable"
- I put the fireox window into background, so that other windows are over it, I use xwinfo -id 0xXXXXX to gather information, map sate is "IsUnMapped"
|
|
Reporter | |
Comment 18•4 years ago
|
||
|
|
Reporter | |
Comment 19•4 years ago
|
||
|
|
||
Comment 20•4 years ago
|
||
Just did a short test on Wayland (Gnome) with 10 non visible windows all running vsynctester.com (which is quite heavy) and got less than 1% average in htop. So on Wayland I'd consider this as fixed by bug 1629140.
As for uncomposited X11, it would probably enough to revert https://phabricator.services.mozilla.com/D84624. I would, however, advice against it: it complicates the GTK backend and I vaguely remember it having caused bugs elsewhere. Further more uncomposited X11 is as legacy and unsupported as it can get, see for example bug 1479135.
No offence, but given that the GTK backend is IMO already overly complex and undermaintained I'd personally vote for: wontfix, use Wayland :)
|
|
Reporter | |
Comment 21•4 years ago
|
||
for win in $(xwininfo -root -children |grep firefox |cut -d ' ' -f 6); do xwininfo -id ${win}; done
xwininfo: Window id: 0x18003f9 "Firefox"
Map State: IsViewable
xwininfo: Window id: 0x2c00001 "/opt/firefox/firefox-bin"
Map State: IsUnMapped
xwininfo: Window id: 0x2a00001 "/opt/firefox/firefox-bin"
Map State: IsUnMapped
xwininfo: Window id: 0x2800001 "/opt/firefox/firefox-bin"
Map State: IsUnMapped
xwininfo: Window id: 0x2600001 "/opt/firefox/firefox-bin"
Map State: IsUnMapped
xwininfo: Window id: 0x2400001 "/opt/firefox/firefox-bin"
Map State: IsUnMapped
xwininfo: Window id: 0x2200001 "/opt/firefox/firefox-bin"
Map State: IsUnMapped
xwininfo: Window id: 0x2000001 "/opt/firefox/firefox-bin"
Map State: IsUnMapped
xwininfo: Window id: 0x1e00001 "/opt/firefox/firefox-bin"
Map State: IsUnMapped
xwininfo: Window id: 0x1c00001 "/opt/firefox/firefox-bin"
Map State: IsUnMapped
xwininfo: Window id: 0x1a00001 "/opt/firefox/firefox-bin"
Map State: IsUnMapped
xwininfo: Window id: 0x1600001 "/opt/firefox/firefox-bin"
Map State: IsUnMapped
xwininfo: Window id: 0x1800001 "Firefox"
Map State: IsUnMapped
=>>>>> the map state could be used to know if the window is viewable....
|
|
Reporter | |
Comment 22•4 years ago
|
||
"No offence, but given that the GTK backend is IMO already overly complex and undermaintained I'd personally vote for: wontfix, use Wayland :)"
No offence, but given that wayland breaks the X11 compatibility, and that lot of "small" window manager that don't make a i7 a 486 like fluxbox don't run on wayland, I would personnally vote "find another browser that don't use 70% of ressources" really.... sorry but no... that you don't want to support broken composing managers on X11, ok, that you don't want do support a complying X11 wm.....
|
|
||
Comment 23•4 years ago
|
||
First of all I'm not an official FF dev, just a independent free time contributor, so it's not my decision anyways - this is just my opinion and an indication of what I personally would be willing to work on.
(In reply to malet jeanluc from comment #22)
a complying X11 wm.....
Just for you to understand my point: unredirected X11 is old tech and a pain to support in modern applications or toolkits. Especially as other platforms have long removed comparable legacy tech, so there's less infrastructure to share (while modern tech can in big parts be shared). So we have a way higher complexity while at the same time way less resources for that. There are reasons why Xorg devs have largely abandoned the project and moved on to Wayland. Fluxbox devs and users should IMO do the same, it would make our and other app devs jobs way easier.
|
|
Reporter | |
Comment 24•4 years ago
|
||
wellll..... "largely abandoned the project" ok.... so explain me why there is still so few wayland compositors????? that's ages that I see forcast saying wayland will be the defacto standard next year (trust me, next year....)
a short summary : X11 is the defacto standard for the *NIX galaxy..... network aware... you'll find the wm that fits you... even i3, that was created after wayland, is still X11 only... whatever wayland fan says, X11 will still be there for ages.... it's old tech, sure... but unix is old tech... and unix is surviving and killing all thoses new tech... mac is unix, smartphone is unix, even windows as now official support to unix.... old tech... but still there... anyway... firefox has to support X11 for long, because unix world isn't just linux... what the point of fluxbox dev to go to wayland? in fact nothing... X11 is far from depth, and this isn't some broken linux composing managers that no one apart eye candy bling bling fan care about (I don't use gnome or kde because it's soooooo slugish.... they are eye candy, have animations, draw stars on screen... but my i7 runs like my first i486)
have a look at https://www.slant.co/versus/8634/8635/~wayland_vs_x-org for a short summary of pro and cons.... X11 will still be here for ages... I guess I'll be dead before it...
|
|
||
Comment 25•4 years ago
|
||
(In reply to malet jeanluc from comment #24)
wellll..... "largely abandoned the project" ok.... so explain me why there is still so few wayland compositors?????
I don't understand the question. There hasn't been a Xorg release since 2018 and now we're getting standalone Xwayland releases. Because that's where the priorities of Xorg devs apparently lie.
a short summary : X11 is the defacto standard for the *NIX galaxy.....
Composited X11 maybe, uncomposited less so. And again, supporting uncomposited X11 has been a pain for Firefox for a while (Webrender, tear-free, vsync etc.). If somebody, for example you, steps up to make a proper patch - go for it. But please in a way that it at least doesn't negatively impact other backends.
(I don't use gnome or kde because it's soooooo slugish.... they are eye candy, have animations, draw stars on screen... but my i7 runs like my first i486)
This is a bug tracker so please stick to technical and precise reasoning.
|
|
Reporter | |
Comment 26•4 years ago
|
||
(In reply to Robert Mader [:rmader] from comment #25)
(In reply to malet jeanluc from comment #24)
wellll..... "largely abandoned the project" ok.... so explain me why there is still so few wayland compositors?????
I don't understand the question. There hasn't been a Xorg release since 2018 and now we're getting standalone Xwayland releases. Because that's where the priorities of Xorg devs apparently lie.
won't argue logger... but answer theses questions : do something that works with more than honorable performance require to be changed? what are the bugs in X11 that you faced since ages? Xorg is more than stable, really fast (even wayland perf improvement aren't that big)... so yep, it don't require any release.... is it bad???
a short summary : X11 is the defacto standard for the *NIX galaxy.....
Composited X11 maybe, uncomposited less so. And again, supporting uncomposited X11 has been a pain for Firefox for a while (Webrender, tear-free, vsync etc.). If somebody, for example you, steps up to make a proper patch - go for it. But please in a way that it at least doesn't negatively impact other backends.
(I don't use gnome or kde because it's soooooo slugish.... they are eye candy, have animations, draw stars on screen... but my i7 runs like my first i486)
This is a bug tracker so please stick to technical and precise reasoning.
and this is my point, saying that user should move to another window manager because you dropped a working feature because it was broken by non compliant WM... is not a technical valid answer....
-> X visibility event are reliable on X's standard compliant WM like there is thousands... if a WM isn't compliant, this is a bug to be filled on the WM's dev to fix the compliance, it's not the compliant software (eg firefox/gdk that were supporting X11's standard) to drop the compliance because of it... I think you dropped the compliance too fast making firefox unusable on thousands devices... because remember, unix is not linux, wayland won't be supported on most unix before ages, if one day it is supported widely on linux.... I still wait for those "technical improvements that will replace the old stuff" like GNU/hurd kernels....
-> proper patch ? git revert.... just bring back the gdk visibility events support you dropped.
|
|
||
Comment 27•4 years ago
|
||
This mostly reverts D84624 while leaving a runtime check for X11
in place.
Turns out that the API still works - even if only for uncomposited X11,
which is why it got deprecated by GTK. As long as we still support
uncomposited X11, lets also carry around this signal.
|
||
Updated•4 years ago
|
|
|
||
Comment 28•4 years ago
|
||
I think you dropped the compliance too fast making firefox unusable on thousands devices
This is something I can work with.
|
|
||
Comment 29•4 years ago
|
||
Robert, are you also going to implement the OcclusionStateChanged() optimization [1]?
|
|
Reporter | |
Comment 30•4 years ago
|
||
(In reply to Robert Mader [:rmader] from comment #27)
Created attachment 9204995 [details]
Bug 1693513 - Reenable visibility tracking, r=stranskyThis mostly reverts D84624 while leaving a runtime check for X11
in place.Turns out that the API still works - even if only for uncomposited X11,
which is why it got deprecated by GTK. As long as we still support
uncomposited X11, lets also carry around this signal.
thanks!!!!
|
|
||
Comment 31•4 years ago
•
|
||
(In reply to Martin Stránský [:stransky] from comment #29)
Robert, are you also going to implement the OcclusionStateChanged() optimization [1]?
Err, right, the previous optimization just worked for the basic backend I guess.
(In reply to malet jeanluc from comment #30)
thanks!!!!
You're welcome. Before we land this, could you give the following try build a go and check if it works as expected for you, especially with Webrender?
https://treeherder.mozilla.org/jobs?repo=try&revision=3241f4b34499cf6bd47f4e7aae44d4f4d813f810
You can launch it via:
mozregression --repo try --launch 3241f4b34499cf6bd47f4e7aae44d4f4d813f810 --pref gfx.webrender.all:true
|
|
||
Comment 32•4 years ago
•
|
||
To answer myself: no, at least not for the following test case: 10-15 stacked maximized windows with vsynctester.com running.
Neither with WR nor basic do I get 60 fps, neither does chromium - on fluxbox. On gnome wayland with MOZ_ENABLE_WAYLAND=1 it's no problem at all, however (with FF >= 86) :/
It could, however, be that OcclusionStateChanged() does less than we do on Wayland. E.g. requestAnimationFrame() still fires on X11 on fluxbox while it doesn't on Wayland.
Markus, does OcclusionStateChanged() stop requestAnimationFrame() when hidden on MacOS?
|
|
||
Comment 33•4 years ago
|
||
Yes, the tab switcher reacts to occlusionstatechange events by setting the tab's browser's docShellIsActive property to false, and inactive docshells don't use the vsync-driven refresh driver timer - they use the InactiveRefreshDriverTimer.
|
|
||
Comment 34•4 years ago
|
||
Inactive docshells also have other power-saving behaviors, like firing setTimeout at lower rates. It sounds like the wayland frame callback driven "deactivation" would not give you that benefit, it would only pause the refresh driver.
|
|
Reporter | |
Comment 35•4 years ago
|
||
will try it again, but first try was even worst... CPU usage jumped to 150% when all widows are maximized but covered by terminal window, and 80% cpu usage when minimized in the tray....
made some test with xev, seems that minimizing into the tray create an unmap event and no visibility event and if not minimized but just obscursed, a visibility event is created...
seems that you need also a handler for GDK_STRUCTURE_MASK for the GDK_MAP, GDK_UNMAP https://www.linuxtopia.org/online_books/gui_toolkit_guides/gtk+_gnome_application_development/sec-gdkevent_1.html
|
|
||
Comment 36•4 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #34)
Inactive docshells also have other power-saving behaviors, like firing setTimeout at lower rates. It sounds like the wayland frame callback driven "deactivation" would not give you that benefit, it would only pause the refresh driver.
Yeah, sounds like a desirable optimization. We could implement that with a timer - something like "no frame callback for more than a second -> occluded". I suppose the most tricky part would be to make sure to get this right when the vsync source is inactive.
(In reply to malet jeanluc from comment #35)
seems that you need also a handler for GDK_STRUCTURE_MASK for the GDK_MAP, GDK_UNMAP https://www.linuxtopia.org/online_books/gui_toolkit_guides/gtk+_gnome_application_development/sec-gdkevent_1.html
Right, that looks like it's missing - I wonder why this didn't exist already though, looks like it never worked as intended :(
|
|
||
Comment 37•4 years ago
|
||
Some observations:
- the visibility signal is only emitted/received when using the
basiccompositor for some reason, so that needs fixing - while on basic thing in theory work as expected, it does not reduce load much, at least not on vsynctester.com - probably not worth fixing as we want to enable Webrender everywhere
- on Wayland things work for both, basic and Webrender
|
|
Reporter | |
Comment 38•4 years ago
|
||
do anyone knows how vsynctester.com is working?
because on a "my dear Imgui" app I'm working on, fps is exactly 60.... while on vsynctester.com it's about 54 fps.... and seems that there are "back buffers" displayed while they should not.... (eg swapbuffer occurs not in sync)
|
|
||
Comment 39•4 years ago
|
||
(In reply to malet jeanluc from comment #38)
do anyone knows how vsynctester.com is working?
because on a "my dear Imgui" app I'm working on, fps is exactly 60.... while on vsynctester.com it's about 54 fps.... and seems that there are "back buffers" displayed while they should not.... (eg swapbuffer occurs not in sync)
Unfortunately don't know much about, but in general it appears to be quite heavy...one alternative - https://www.testufo.com/animation-time-graph - usually gives me much more accurate results, especially on slow devices (I recently started testing stuff on an old Thinkpad T400 more often).
|
|
||
Comment 40•4 years ago
|
||
Maybe a little bit more helpful info: vsynctester.com and similar sites work based on Window.requestAnimationFrame(). In most browsers that signal should be tied to vsync - in case of Firefox on X11 that in turn is fed by GtkVsyncSource (https://searchfox.org/mozilla-central/source/gfx/thebes/gfxPlatformGtk.cpp#514). It uses a quite legacy GLX method (glXWaitVideoSyncSGI), which may or may not work particular well. There are plans to replace it with more modern solutions on EGL (bug 1640779), but AFAIK nobody is currently working on that.
|
|
Reporter | |
Comment 41•4 years ago
|
||
is there any advance on this topic? I fixed similar issue on GLFW framework, mapping events were correctly handled, so minimizing, workspace switch etc, was correctly handled, but app was still consuming cpu when another window was on top,
see https://github.com/glfw/glfw/issues/1855
after testing behavior was correct on imgui test app....
thanks and regards
JLM
|
||
Comment 42•4 years ago
|
||
There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:rmader, could you have a look please?
For more information, please visit auto_nag documentation.
|
|
||
Updated•4 years ago
|
|
|
||
Comment 43•4 years ago
|
||
This still needs further investigation why the visibility events are not triggered when using WR. Malet, do you know about any 3d app where this works? Maybe it's a WM bug.
|
|
Reporter | |
Comment 44•4 years ago
|
||
i've made some test app using "my dear im-gui" opengl widgets and GLW low layers
-> the test app use a feature branch for "low power consumption" not yet merged into main branch : https://github.com/ocornut/imgui/pull/2749
-> GLW is also on unmerged branch : https://github.com/glfw/glfw/pull/1856
the combination of the two do the requested handling : stop update of widgets if the window is unmapped (unmapping events) or if the window is fully obfuscated (visibility event)
the GLW bug is because visibility event were not handled to compute the visibility on GLW....
when both visibility and mapping event are correctly handled, the behavior is correct :
-> fully obfuscated window don't consume any CPU
-> reduced widows (unmapped) don't consume any CPU
-> other workspace windows (unmapped) don't consume any CPU
so this isn't an issue of the window manager, the event are correctly sent.
|
|
Reporter | |
Comment 45•4 years ago
|
||
any progress? I can't try to fix it myself since it takes too long for mozilla to build...
|
|
||
Comment 46•4 years ago
|
||
(In reply to malet jeanluc from comment #45)
any progress? I can't try to fix it myself since it takes too long for mozilla to build...
Unfortunately not :(
It's good to know that the visibility event works for other GL clients - but I couldn't yet figure out why it doesn't fire for FF. It all looks right to me with the patch though. So this needs a longer debug session.
|
|
Reporter | |
Comment 47•4 years ago
|
||
maybe a way to add some debug console print? at least to know if the mapping/unmapping and focus event are reported by GDK?
by the way if FF is now GL based, why not considering a openGL aware toolkit like GLFW? even if there is a bug filled, at least the problem is identified and there is a fix....
|
|
Reporter | |
Comment 48•4 years ago
|
||
Hi, seems that the enthusiasm of first time investigation has gone....
is there anybody working on this issue?
thanks and regards
|
|
||
Comment 49•4 years ago
|
||
(In reply to malet jeanluc from comment #48)
Hi, seems that the enthusiasm of first time investigation has gone....
is there anybody working on this issue?
thanks and regards
Sorry, this is very low prio as it's such an edge case. I hope to get to it eventually. In the mean time I can only encourage to port/rewrite affected WMs for Wayland. Xorg as a display server is getting abandoned and developer focus, as much as it still exists, will only get smaller over time, on all levels of the stack. So if you are interested in preserving the the workflow of e.g. fluxbox, porting to Wayland is the way to go AFAICS.
why not considering a openGL aware toolkit like GLFW?
In short, this would be tons of work for likely no benefit.
|
|
Reporter | |
Comment 50•4 years ago
|
||
I rebuilt using gentoo script, added some std::cout information and according to what I see, seems that GDK don't report all the unmap events to the app, I see no trace of unmapping when xwininfo gives me the MAP state to not viewable, this is the root cause because the window on every workspaces think they are still mapped and not obscured (since there is no visibility event triggered if the window is unmapped...)
do you mind if I do a fix using x11's events? not sure this assigning several callbacks will works but I'm almost sure that GDK team won't fix this issue since they marqued the API as deprecated....
|
|
Reporter | |
Comment 51•4 years ago
|
||
not sure about how to use this :
gdk has visibility checking functions, maybe this can be used :
https://developer.gnome.org/gdk3/stable/gdk3-Windows.html
gdk_window_is_visible ()
gdk_window_is_viewable ()
nsWindow has virtual bool IsVisible() const override;
is it the method called by rendering to know if it should render? if yes, currently it only returns mIsShown, it should return result of one of theses functions, hopping they correctly handle x11 mapping events....
|
|
Reporter | |
Comment 52•4 years ago
|
||
when I try to build with modifications involving gdk_window_is_visible or gdk_window_is_viewable, compilation fails on link saying ld.lld: error: undefined symbol: gdk_window_is_viewable,
can you help me on this? I searched the web but nothing intersting....
|
|
||
Comment 53•4 years ago
|
||
(In reply to malet jeanluc from comment #52)
when I try to build with modifications involving gdk_window_is_visible or gdk_window_is_viewable, compilation fails on link saying ld.lld: error: undefined symbol: gdk_window_is_viewable,
can you help me on this? I searched the web but nothing intersting....
Thanks for looking into it! I just gave it a try and it worked - I'd assume you used it with an argument of the wrong type - because we're in cpp land here the compiler will complain. Casting it to GdkWindow* should do the trick.
|
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
|
Reporter | |
Comment 54•4 years ago
|
||
(In reply to Robert Mader [:rmader] from comment #53)
(In reply to malet jeanluc from comment #52)
when I try to build with modifications involving gdk_window_is_visible or gdk_window_is_viewable, compilation fails on link saying ld.lld: error: undefined symbol: gdk_window_is_viewable,
can you help me on this? I searched the web but nothing intersting....Thanks for looking into it! I just gave it a try and it worked - I'd assume you used it with an argument of the wrong type - because we're in cpp land here the compiler will complain. Casting it to
GdkWindow*should do the trick.
I just changed the following in ./widget/gtk/nsWindow.cpp:
// nsIWidget method, which means IsShown.
bool nsWindow::IsVisible() const {
bool isViewable = gdk_window_is_viewable(mGdkWindow);
std::cout << "isViewable : " << isViewable << std::endl;
return mIsShown && isViewable;
}
and according to ./widget/gtk/nsWindow.h : GdkWindow* mGdkWindow;
anyway the casting error would have occured at compile time, not at link time...
0:35.37 /usr/lib/llvm/12/bin/x86_64-pc-linux-gnu-clang++ -std=gnu++17 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fstack-clash-protection -Qunused-arguments -Qunused-arguments -Wall -Wbitfield-enum-conversion -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wshadow-field-in-constructor-modified -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wempty-init-stmt -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis -Wno-range-loop-analysis -Wc++2a-compat -Wcomma -Wimplicit-fallthrough -Wunused-function -Wunused-variable -Wstring-conversion -Wtautological-overlap-compare -Wtautological-unsigned-enum-zero-compare -Wtautological-unsigned-zero-compare -Wno-error=tautological-type-limit-compare -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=backend-plugin -Wno-error=free-nonheap-object -Wno-error=return-std-move -Wno-error=atomic-alignment -Wno-error=deprecated-copy -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-psabi -Wno-unknown-warning-option -fno-sized-deallocation -fno-aligned-new -march=native -pipe -fno-exceptions -fno-strict-aliasing -fPIC -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -O2 -fomit-frame-pointer -funwind-tables -shared -Wl,-z,defs -Wl,--gc-sections -Wl,-h,libxul.so -o libxul.so /home/portage/www-client/firefox-88.0.1/work/firefox_build/toolkit/library/build/libxul_so.list -lpthread -Wl,-O1 -Wl,--as-needed -Wl,--compress-debug-sections=zlib -Wl,-rpath=/usr/lib64/firefox,--enable-new-dtags -Wl,--compress-debug-sections=zlib -Wl,-rpath=/usr/lib64/firefox,--enable-new-dtags -fuse-ld=lld -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions -fstack-protector-strong -fstack-clash-protection -Wl,-rpath-link,/home/portage/www-client/firefox-88.0.1/work/firefox_build/dist/bin -Wl,-rpath-link,/usr/lib -fcolor-diagnostics ../../../js/src/build/libjs_static.a /home/portage/www-client/firefox-88.0.1/work/firefox_build/x86_64-unknown-linux-gnu/release/libgkrust.a ../../../security/sandbox/linux/libmozsandbox.so ../../../config/external/lgpllibs/liblgpllibs.so ../../../config/external/sqlite/libmozsqlite3.so ../../../widget/gtk/mozgtk/stub/libmozgtk_stub.so -Wl,--version-script,symverscript -ldl -licui18n -licuuc -licudata -laom -ldav1d -lrt -lm -lX11 -lX11-xcb -lxcb -lXcomposite -lXcursor -lXdamage -lXext -lXfixes -lXi -lXrender -lpthread -ldl -lc -lffi -lplds4 -lplc4 -lnspr4 -lz -lssl3 -lsmime3 -lnss3 -lnssutil3 -lfreetype -lfontconfig -L/usr/lib64 -lgraphite2 -lharfbuzz -lpng -lwebpdemux -lwebp -lvpx -lpixman-1 -ldbus-glib-1 -ldbus-1 -lgobject-2.0 -lglib-2.0 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lxcb-shm -lpangoft2-1.0 -lXt -lgthread-2.0
0:38.36 ld.lld: error: undefined symbol: gdk_window_is_viewable
what I see is that the linkage is done with -lgdk_pixbuf-2.0 but there is no reference to -lgdk where the gdk_window_is_visible symbol is defined...
and according to ldd, there is no link between gdk_pixbuf-2.0 library with gdk-x11-2.0 library (the reverse is true, if it was linked with -lgdk-x11-2.0 it would have included -lgdk_pixbuf-2.0)
# ldd /usr/lib64/libgdk_pixbuf-2.0.so
linux-vdso.so.1 (0x00007fff76cfc000)
libm.so.6 => /lib64/libm.so.6 (0x00007fa716a3a000)
libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fa716907000)
libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007fa7168ae000)
libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007fa7168a8000)
libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007fa7166d7000)
libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007fa71669d000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa71667b000)
libc.so.6 => /lib64/libc.so.6 (0x00007fa7164c0000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa716bc3000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fa716448000)
libffi.so.7 => /usr/lib64/libffi.so.7 (0x00007fa71643c000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fa716436000)
libz.so.1 => /lib64/libz.so.1 (0x00007fa71641c000)
libmount.so.1 => /lib64/libmount.so.1 (0x00007fa7163bb000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fa7163a1000)
libblkid.so.1 => /lib64/libblkid.so.1 (0x00007fa716350000)
what I don't know is where the linkage dependencies are done...
|
|
||
Comment 55•4 years ago
|
||
gdk_window_is_viewable() is not useful for you, it means the window has allocated needed background data, i.e. XID on X11 and so on. This is not what you want.
|
|
||
Comment 56•4 years ago
|
||
btw. gdk_window_is_viewable is implemented at:
libgdk-3.so:
000000000004b490 T gdk_window_is_viewable
libgdk-x11-2.0.so:
0000000000042350 T gdk_window_is_viewable
while libgdk-3.so is what you want.
|
|
||
Comment 57•4 years ago
|
||
I'm surprised to still see GTK2 symbols - we shouldn't link to it any more, no?
|
|
||
Comment 58•4 years ago
•
|
||
Ah, makes sense now. Malet: looks like you are building against an older version of FF, most importantly older than 90, which got bug 1377445. Before that we had stubs for every needed symbol in widget/gtk/mozgtk/mozgtk.c. You just need to add the function there - or update to a never FF version. I'd suggest to directly try mozilla-central / nightly, as that's where we land patches.
|
|
Reporter | |
Comment 59•4 years ago
|
||
(In reply to Robert Mader [:rmader] from comment #58)
Ah, makes sense now. Malet: looks like you are building
againstan older version of FF, most importantly older than 90, which got bug 1377445. Before that we had stubs for every needed symbol inwidget/gtk/mozgtk/mozgtk.c. You just need to add the function there - or update to a never FF version. I'd suggest to directly try mozilla-central / nightly, as that's where we land patches.
I use what is available to me from sources 89.0 build on gentoo (don't have neither time nor wish to learn the tricks to build firefox ;) ) ok I added stubs into mozgtk.c, looks like awfull, hoppefully you cleaned that on 90+ O_O
|
|
||
Comment 60•4 years ago
|
||
(In reply to malet jeanluc from comment #59)
I use what is available to me from sources 89.0 build on gentoo (don't have neither time nor wish to learn the tricks to build firefox ;) ) ok I added stubs into mozgtk.c, looks like awfull, hoppefully you cleaned that on 90+ O_O
Hehe, yes it's gone now. It was necessary as long as we had both GTK2 (for plugin support -> flash...) and GTK3.
|
|
Reporter | |
Comment 61•4 years ago
|
||
ok, gdk_window_is_viewable is no help..... in fact it reports nothing interesting....
what I found is that I can get the map/unmap event and only unmap event are required since visibility event will be triggered on map
in nsWindow::Create
g_signal_connect(widgets[i], "visibility-notify-event",
G_CALLBACK(visibility_notify_event_cb), nullptr);
g_signal_connect(widgets[i], "map_event",
G_CALLBACK(window_map_event_cb), nullptr);
g_signal_connect(widgets[i], "unmap_event",
G_CALLBACK(window_unmap_event_cb), nullptr);
then add the callbacks (visibility_notify_event_cb are already present in previous patch)
static gboolean visibility_notify_event_cb(GtkWidget* widget,
GdkEventVisibility* event) {
RefPtr<nsWindow> window = get_window_for_gdk_window(event->window);
if (!window) return FALSE;
std::cout << "visibility notify event x11 window id : " << event->window
<< " GDK_VISIBILITY_UNOBSCURED : " << std::hex << "0x" << (event->state & GDK_VISIBILITY_UNOBSCURED)
<< " GDK_VISIBILITY_PARTIAL : " << std::hex << "0x" << (event->state & GDK_VISIBILITY_PARTIAL)
<< " GDK_VISIBILITY_FULLY_OBSCURED : " << std::hex << "0x" << (event->state & GDK_VISIBILITY_FULLY_OBSCURED)
<< std::endl;
window->OnVisibilityNotifyEvent(event);
return TRUE;
}
static gboolean window_map_event_cb( GtkWidget* widget,
GdkEventAny* event) {
//RefPtr<nsWindow> window = get_window_for_gtk_widget(widget);
//if (!window) return FALSE;
std::cout << "window_map_event_cb : " <<std::endl;
if (event->type == GDK_MAP)
{
std::cout << "window mapped" <<std::endl;
}
return FALSE;
}
static gboolean window_unmap_event_cb( GtkWidget* widget,
GdkEventAny* event) {
//RefPtr<nsWindow> window = get_window_for_gtk_widget(widget);
//if (!window) return FALSE;
std::cout << "window_unmap_event_cb for window " << event->window <<std::endl;
RefPtr<nsWindow> window = get_window_for_gdk_window(event->window);
if (!window) return FALSE;
window->OnVisibilityUnmapEvent();
return FALSE;
}
void nsWindow::OnVisibilityUnmapEvent()
{
std::cout << "windows is now fully occluded" << std::endl;
mIsFullyOccluded = true;
}
on the stdout I see the right traces :
- "windows is now fully occluded" appears when the window is iconified or moved to another workspace
- "visibility notify event x11 window id : " appears when widow is restored or when I go to the workspace
BUT this don't reduce CPU usage... seems like mIsFullyOccluded is not used....
|
|
Reporter | |
Comment 62•4 years ago
|
||
this try is cleaner, and don't need to add additional method to the class :
in nsWindow::Create
g_signal_connect(widgets[i], "visibility-notify-event",
G_CALLBACK(visibility_notify_event_cb), nullptr);
g_signal_connect(widgets[i], "map_event",
G_CALLBACK(window_map_event_cb), nullptr);
g_signal_connect(widgets[i], "unmap_event",
G_CALLBACK(window_unmap_event_cb), nullptr);
then add the callbacks :
static gboolean visibility_notify_event_cb(GtkWidget* widget,
GdkEventVisibility* event) {
RefPtr<nsWindow> window = get_window_for_gdk_window(event->window);
if (!window) return FALSE;
std::cout << "visibility notify event x11 window id : " << event->window
<< " GDK_VISIBILITY_UNOBSCURED : " << std::hex << "0x" << (event->state & GDK_VISIBILITY_UNOBSCURED)
<< " GDK_VISIBILITY_PARTIAL : " << std::hex << "0x" << (event->state & GDK_VISIBILITY_PARTIAL)
<< " GDK_VISIBILITY_FULLY_OBSCURED : " << std::hex << "0x" << (event->state & GDK_VISIBILITY_FULLY_OBSCURED)
<< std::endl;
window->OnVisibilityNotifyEvent(event);
return TRUE;
}
static gboolean window_map_event_cb( GtkWidget* widget,
GdkEventAny* event) {
//RefPtr<nsWindow> window = get_window_for_gtk_widget(widget);
//if (!window) return FALSE;
std::cout << "window_map_event_cb : " <<std::endl;
return FALSE;
}
static gboolean window_unmap_event_cb( GtkWidget* widget,
GdkEventAny* event) {
//RefPtr<nsWindow> window = get_window_for_gtk_widget(widget);
//if (!window) return FALSE;
std::cout << "window_unmap_event_cb for window " << event->window <<std::endl;
GdkEventVisibility Vevent;
Vevent.window = event->window;
Vevent.state = GDK_VISIBILITY_FULLY_OBSCURED;
visibility_notify_event_cb(widget,&Vevent);
return FALSE;
}
from what I see, the CPU usage has some reduction
before it was like 80% used by firefox and 3 webrendered using between 12% to 24%
with the fix, when all the windows but one are minimized, about 33% is used by firefox and webrender finish to go to about 2% each
when moving windows to other workspace I see the moved window have a GDK_VISIBILITY_FULLY_OBSCURED, but didn't saw big CPU reduction, but I've to test because I suspect to be still in starting conditions
|
|
||
Comment 63•4 years ago
|
||
Just for the record: hiding the FF windows behind other windows does still not trigger any map/visibility events, right?
|
|
Reporter | |
Comment 64•4 years ago
|
||
I retried, cold start with retoring session, all the windows are opened on same workspace and moved to other workspace, on the console I see the fully obscured event for the moved windows
I let the process run for 10 minutes, no change on CPU usage, firefox use 66% webrenderers about 30% each
then I reduced to tray some windows, the main difference between the move to other workspace and reducing is that I see some trace that I put in other parts of the code
FULLY_OBSCURED : 0x0
OnWindowStateEvent : 82
OnWindowStateEvent : 82
window is mapped : 0
SetHasMappedToplevel : 0
so the main difference is that SetHasMappedToplevel method is called...
|
|
Reporter | |
Comment 65•4 years ago
|
||
(In reply to Robert Mader [:rmader] from comment #63)
Just for the record: hiding the FF windows behind other windows does still not trigger any map/visibility events, right?
no hidding FF windows behind another windows does trig visibility event, if it it's fully obscured, a GDK_VISIBILITY_FULLY_OBSCURED is triggered, if partial GDK_VISIBILITY_PARTIAL
map event are only triggered when moving to other workspace or reducing to tray. in case of map event, no visiblity event is produced (that's the purpose of my fix, I generate a visibility event GDK_VISIBILITY_FULLY_OBSCURED on unmap events)
|
|
Reporter | |
Comment 66•4 years ago
|
||
tried to call SetHasMappedToplevel(0) when GDK_VISIBILITY_FULLY_OBSCURED (remember that I fake this event on unmap) but this hasn't the same effect than reducing the window, consumption still remain high....
I don't understand why... unless another part of the code is triggered when reducing to tray, OnWindowStateEvent will only call SetHasMappedToplevel in this case...
really, the code is a mess... gtk code is really unreadable... not object oriented, lot of callbacks and the functions are too big to be readable...
|
|
Reporter | |
Comment 67•4 years ago
|
||
can someone explain me what is done when the window is minimized? what signals are received?
there is many duplicates variables, for example mIsShown and mIsTopLevelMapped....
|
|
Reporter | |
Comment 68•4 years ago
|
||
for the record, and if anyone is interested by solving this issue :
here are the event sent by the X11 protocol in various situations :
==== restore from tray =====
ColormapNotify event, serial 22, synthetic NO, window 0x42001fd,
colormap 0x4200002, new NO, state ColormapInstalled
PropertyNotify event, serial 22, synthetic NO, window 0x42001fd,
atom 0x24d (_NET_WM_ALLOWED_ACTIONS), time 785105408, state PropertyNewValue
PropertyNotify event, serial 22, synthetic NO, window 0x42001fd,
atom 0x1ac (_NET_WM_STATE), time 785105408, state PropertyDelete
MapNotify event, serial 22, synthetic NO, window 0x42001fd,
event 0x42001fd, window 0x42001fd, override NO
VisibilityNotify event, serial 22, synthetic NO, window 0x42001fd,
state VisibilityPartiallyObscured
Expose event, serial 22, synthetic NO, window 0x42001fd,
(0,0), width 1600, height 1734, count 2
Expose event, serial 22, synthetic NO, window 0x42001fd,
(3190,0), width 9, height 1734, count 1
Expose event, serial 22, synthetic NO, window 0x42001fd,
(0,1734), width 3199, height 16, count 0
PropertyNotify event, serial 22, synthetic NO, window 0x42001fd,
atom 0x1cf (WM_STATE), time 785105410, state PropertyNewValue
VisibilityNotify event, serial 22, synthetic NO, window 0x42001fd,
state VisibilityUnobscured
Expose event, serial 22, synthetic NO, window 0x42001fd,
(1600,0), width 1590, height 1734, count 0
FocusIn event, serial 22, synthetic NO, window 0x42001fd,
mode NotifyNormal, detail NotifyNonlinear
KeymapNotify event, serial 22, synthetic NO, window 0x0,
keys: 118 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ColormapNotify event, serial 22, synthetic NO, window 0x42001fd,
colormap 0x4200002, new NO, state ColormapUninstalled
ConfigureNotify event, serial 22, synthetic NO, window 0x42001fd,
event 0x42001fd, window 0x42001fd, (0,22), width 3199, height 1750,
border_width 0, above 0x567436, override NO
ColormapNotify event, serial 22, synthetic NO, window 0x42001fd,
colormap 0x4200002, new NO, state ColormapInstalled
PropertyNotify event, serial 22, synthetic NO, window 0x42001fd,
atom 0x23 (WM_HINTS), time 785105469, state PropertyNewValue
ConfigureNotify event, serial 22, synthetic YES, window 0x42001fd,
event 0x42001fd, window 0x42001fd, (0,23), width 3199, height 1750,
border_width 0, above 0x0, override NO
PropertyNotify event, serial 22, synthetic NO, window 0x42001fd,
atom 0x24d (_NET_WM_ALLOWED_ACTIONS), time 785105477, state PropertyNewValue
EnterNotify event, serial 22, synthetic NO, window 0x42001fd,
root 0x1a0, subw 0x0, time 785109497, (1152,1749), root:(1152,1772),
mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
focus YES, state 0
KeymapNotify event, serial 22, synthetic NO, window 0x0,
keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
LeaveNotify event, serial 22, synthetic NO, window 0x42001fd,
root 0x1a0, subw 0x0, time 785109663, (1015,1750), root:(1015,1773),
mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
focus YES, state 0
FocusOut event, serial 22, synthetic NO, window 0x42001fd,
mode NotifyNormal, detail NotifyNonlinear
VisibilityNotify event, serial 22, synthetic NO, window 0x42001fd,
state VisibilityPartiallyObscured
ColormapNotify event, serial 22, synthetic NO, window 0x42001fd,
colormap 0x4200002, new NO, state ColormapUninstalled
ConfigureNotify event, serial 22, synthetic YES, window 0x42001fd,
event 0x42001fd, window 0x42001fd, (0,23), width 3199, height 1750,
border_width 0, above 0x0, override NO
FocusIn event, serial 22, synthetic NO, window 0x42001fd,
mode NotifyNormal, detail NotifyNonlinear
KeymapNotify event, serial 22, synthetic NO, window 0x0,
keys: 4294967200 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ConfigureNotify event, serial 22, synthetic NO, window 0x42001fd,
event 0x42001fd, window 0x42001fd, (0,22), width 3199, height 1750,
border_width 0, above 0x567436, override NO
ColormapNotify event, serial 22, synthetic NO, window 0x42001fd,
colormap 0x4200002, new NO, state ColormapInstalled
PropertyNotify event, serial 22, synthetic NO, window 0x42001fd,
atom 0x23 (WM_HINTS), time 785110650, state PropertyNewValue
ConfigureNotify event, serial 22, synthetic YES, window 0x42001fd,
event 0x42001fd, window 0x42001fd, (0,23), width 3199, height 1750,
border_width 0, above 0x0, override NO
PropertyNotify event, serial 22, synthetic NO, window 0x42001fd,
atom 0x24d (_NET_WM_ALLOWED_ACTIONS), time 785110661, state PropertyNewValue
EnterNotify event, serial 22, synthetic NO, window 0x42001fd,
root 0x1a0, subw 0x0, time 785110663, (1022,1749), root:(1022,1772),
mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
focus YES, state 0
KeymapNotify event, serial 22, synthetic NO, window 0x0,
keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
LeaveNotify event, serial 22, synthetic NO, window 0x42001fd,
root 0x1a0, subw 0x0, time 785110895, (1612,1450), root:(1612,1473),
mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
focus YES, state 0
FocusOut event, serial 22, synthetic NO, window 0x42001fd,
mode NotifyNormal, detail NotifyNonlinear
ColormapNotify event, serial 22, synthetic NO, window 0x42001fd,
colormap 0x4200002, new NO, state ColormapUninstalled
ConfigureNotify event, serial 22, synthetic YES, window 0x42001fd,
event 0x42001fd, window 0x42001fd, (0,23), width 3199, height 1750,
border_width 0, above 0x0, override NO
EnterNotify event, serial 22, synthetic NO, window 0x42001fd,
root 0x1a0, subw 0x0, time 785119827, (2143,1739), root:(2143,1762),
mode NotifyUngrab, detail NotifyNonlinear, same_screen YES,
focus NO, state 0
KeymapNotify event, serial 22, synthetic NO, window 0x0,
keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
LeaveNotify event, serial 22, synthetic NO, window 0x42001fd,
root 0x1a0, subw 0x0, time 785119991, (2143,1732), root:(2143,1755),
mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
focus NO, state 0
|
|
Reporter | |
Comment 69•4 years ago
|
||
==== reduce to tray =====
FocusIn event, serial 24, synthetic NO, window 0x42001fd,
mode NotifyNormal, detail NotifyNonlinear
KeymapNotify event, serial 24, synthetic NO, window 0x0,
keys: 4294967200 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ConfigureNotify event, serial 24, synthetic NO, window 0x42001fd,
event 0x42001fd, window 0x42001fd, (0,22), width 3199, height 1750,
border_width 0, above 0x567436, override NO
ColormapNotify event, serial 24, synthetic NO, window 0x42001fd,
colormap 0x4200002, new NO, state ColormapInstalled
PropertyNotify event, serial 24, synthetic NO, window 0x42001fd,
atom 0x23 (WM_HINTS), time 785173354, state PropertyNewValue
ConfigureNotify event, serial 24, synthetic YES, window 0x42001fd,
event 0x42001fd, window 0x42001fd, (0,23), width 3199, height 1750,
border_width 0, above 0x0, override NO
PropertyNotify event, serial 24, synthetic NO, window 0x42001fd,
atom 0x24d (_NET_WM_ALLOWED_ACTIONS), time 785173361, state PropertyNewValue
VisibilityNotify event, serial 24, synthetic NO, window 0x42001fd,
state VisibilityUnobscured
Expose event, serial 24, synthetic NO, window 0x42001fd,
(1600,0), width 1590, height 32, count 2
Expose event, serial 24, synthetic NO, window 0x42001fd,
(1287,32), width 1903, height 1488, count 1
Expose event, serial 24, synthetic NO, window 0x42001fd,
(1600,1520), width 1590, height 214, count 0
PropertyNotify event, serial 24, synthetic NO, window 0x42001fd,
atom 0x24d (_NET_WM_ALLOWED_ACTIONS), time 785177108, state PropertyNewValue
PropertyNotify event, serial 24, synthetic NO, window 0x42001fd,
atom 0x1ac (_NET_WM_STATE), time 785177109, state PropertyNewValue
FocusOut event, serial 24, synthetic NO, window 0x42001fd,
mode NotifyNormal, detail NotifyNonlinear
PropertyNotify event, serial 24, synthetic NO, window 0x42001fd,
atom 0x1cf (WM_STATE), time 785177109, state PropertyNewValue
UnmapNotify event, serial 24, synthetic NO, window 0x42001fd,
event 0x42001fd, window 0x42001fd, from_configure NO
ColormapNotify event, serial 24, synthetic NO, window 0x42001fd,
colormap 0x4200002, new NO, state ColormapUninstalled
ConfigureNotify event, serial 24, synthetic YES, window 0x42001fd,
event 0x42001fd, window 0x42001fd, (0,23), width 3199, height 1750,
border_width 0, above 0x0, override NO
|
|
Reporter | |
Comment 70•4 years ago
|
||
===== sending to another workspace =====
FocusIn event, serial 24, synthetic NO, window 0x42001fd,
mode NotifyNormal, detail NotifyNonlinear
KeymapNotify event, serial 24, synthetic NO, window 0x0,
keys: 4294967200 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
PropertyNotify event, serial 24, synthetic NO, window 0x42001fd,
atom 0x23 (WM_HINTS), time 785230600, state PropertyNewValue
ConfigureNotify event, serial 24, synthetic NO, window 0x42001fd,
event 0x42001fd, window 0x42001fd, (0,22), width 3199, height 1750,
border_width 0, above 0x567436, override NO
ColormapNotify event, serial 24, synthetic NO, window 0x42001fd,
colormap 0x4200002, new NO, state ColormapInstalled
ConfigureNotify event, serial 24, synthetic YES, window 0x42001fd,
event 0x42001fd, window 0x42001fd, (0,23), width 3199, height 1750,
border_width 0, above 0x0, override NO
PropertyNotify event, serial 24, synthetic NO, window 0x42001fd,
atom 0x24d (_NET_WM_ALLOWED_ACTIONS), time 785230608, state PropertyNewValue
FocusOut event, serial 24, synthetic NO, window 0x42001fd,
mode NotifyNormal, detail NotifyNonlinear
ColormapNotify event, serial 24, synthetic NO, window 0x42001fd,
colormap 0x4200002, new NO, state ColormapUninstalled
ConfigureNotify event, serial 24, synthetic YES, window 0x42001fd,
event 0x42001fd, window 0x42001fd, (0,23), width 3199, height 1750,
border_width 0, above 0x0, override NO
Expose event, serial 24, synthetic NO, window 0x42001fd,
(1342,0), width 258, height 407, count 0
PropertyNotify event, serial 24, synthetic NO, window 0x42001fd,
atom 0x1a6 (_NET_WM_DESKTOP), time 785238258, state PropertyNewValue
PropertyNotify event, serial 25, synthetic NO, window 0x42001fd,
atom 0x1cf (WM_STATE), time 785238296, state PropertyNewValue
UnmapNotify event, serial 25, synthetic NO, window 0x42001fd,
event 0x42001fd, window 0x42001fd, from_configure NO
|
|
Reporter | |
Comment 71•4 years ago
|
||
===== entering the workspace ======
MapNotify event, serial 25, synthetic NO, window 0x42001fd,
event 0x42001fd, window 0x42001fd, override NO
VisibilityNotify event, serial 25, synthetic NO, window 0x42001fd,
state VisibilityPartiallyObscured
Expose event, serial 25, synthetic NO, window 0x42001fd,
(1600,0), width 1599, height 32, count 2
Expose event, serial 25, synthetic NO, window 0x42001fd,
(2389,32), width 810, height 1488, count 1
Expose event, serial 25, synthetic NO, window 0x42001fd,
(1600,1520), width 1599, height 230, count 0
PropertyNotify event, serial 25, synthetic NO, window 0x42001fd,
atom 0x1cf (WM_STATE), time 785353018, state PropertyNewValue
Expose event, serial 25, synthetic NO, window 0x42001fd,
(1600,32), width 789, height 1488, count 0
|
|
Reporter | |
Comment 72•4 years ago
|
||
====== leaving the workspace =======
PropertyNotify event, serial 25, synthetic NO, window 0x42001fd,
atom 0x1cf (WM_STATE), time 785392040, state PropertyNewValue
UnmapNotify event, serial 25, synthetic NO, window 0x42001fd,
event 0x42001fd, window 0x42001fd, from_configure NO
|
|
Reporter | |
Comment 73•4 years ago
|
||
according to my hacks on the code, that handle mapping/unmapping events, there is a difference between what I do on this events, and what is done when reducing to tray....
if all the windows are unmapped, the cpu usage goes about 75% and 2 webrender working at 50%
if I reduce the windows to tray, the cpu usage goes about 18% and webrender takes about 10%
|
|
Reporter | |
Comment 74•4 years ago
|
||
======= cpu usage all window minimized to tray====
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18134 XXX 20 0 3370152 906884 545620 S 5.9 5.6 0:49.43 Web Content
17040 XXX 20 0 9901500 4.8g 2.8g S 5.0 30.6 9:10.34 firefox
18148 XXX 20 0 3209304 726604 488208 S 5.0 4.5 1:28.80 Web Content
18096 XXX 20 0 3538508 873408 598032 S 4.6 5.4 1:08.76 Web Content
18042 XXX 20 0 3469164 914764 664692 S 2.0 5.6 0:35.72 Web Content
18115 XXX 20 0 3829076 1.2g 804128 S 1.3 7.5 1:45.62 Web Content
27777 XXX 20 0 388128 20880 10784 S 1.3 0.1 31:18.10 lxterminal
18186 XXX 20 0 3549208 1.0g 710036 S 1.0 6.5 1:41.32 Web Content
16832 root 20 0 9252 1384 708 R 0.7 0.0 4:29.45 top
27585 root 20 0 1054912 728 0 S 0.7 0.0 62:37.80 veracrypt
27698 XXX 20 0 2149844 1.3g 1.3g S 0.7 8.5 85:28.95 X
27717 XXX 20 0 751148 5664 3192 S 0.7 0.0 40:19.21 veracrypt
3243 root 20 0 9256 164 20 S 0.3 0.0 14:00.80 wpa_supplicant
18556 root 0 -20 0 0 0 I 0.3 0.0 0:00.07 kworker/2:1H-mmc_complete
27600 root 0 -20 0 0 0 S 0.3 0.0 1:49.71 loop0
27609 root 20 0 0 0 0 S 0.3 0.0 0:13.64 dmcrypt_write/2
27715 XXX 20 0 10580 492 244 S 0.3 0.0 0:27.05 xscreensaver
1 root 20 0 2340 24 0 S 0.0 0.0 0:12.97 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.42 kthreadd
======= cpu usage 6 windows on workspace 44 windows at total (448 tabs ;) )====
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19235 jlm 20 0 9780364 4.7g 2.8g S 31.0 30.4 2:27.21 firefox
19369 jlm 20 0 3715984 1.1g 764276 S 29.7 6.9 0:51.88 Web Content
19446 jlm 20 0 3422396 897808 601616 S 22.1 5.5 0:45.92 Web Content
19389 jlm 20 0 3319112 792304 542864 S 11.9 4.9 0:29.19 Web Content
19465 jlm 20 0 3223876 812280 603976 S 9.9 5.0 0:18.79 Web Content
19309 jlm 20 0 3196412 754280 591788 S 8.9 4.6 0:22.17 Web Content
19427 jlm 20 0 3002420 572032 366544 S 8.6 3.5 0:19.37 Web Content
27777 jlm 20 0 388488 20996 10784 R 5.3 0.1 31:22.82 lxterminal
19408 jlm 20 0 3197868 717480 455092 S 4.6 4.4 0:19.54 Web Content
27698 jlm 20 0 2270736 835592 798900 S 4.0 5.1 85:56.50 X
19355 jlm 20 0 3383816 961936 661684 S 3.0 5.9 0:17.60 Web Content
27585 root 20 0 1054912 740 0 S 1.0 0.0 62:39.56 veracrypt
16832 root 20 0 9252 1384 708 R 0.7 0.0 4:31.34 top
2567 root -51 0 0 0 0 S 0.3 0.0 10:47.99 irq/127-iwlwifi
===== cpu usage without mapp patch 6 windows on workspace 44 windows at total =====
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22543 jlm 20 0 12.8g 1.2g 260268 S 117.6 7.8 18:34.67 firefox-bin
22790 jlm 20 0 2602472 226692 68580 R 27.6 1.4 3:17.34 Web Content
22813 jlm 20 0 3152608 434476 103520 S 14.3 2.7 2:18.63 Web Content
22721 jlm 20 0 3070212 452112 120728 S 13.6 2.8 2:38.34 Web Content
45 root 20 0 0 0 0 S 11.3 0.0 9:17.77 kcompactd0
22836 jlm 20 0 2747376 254088 81264 S 8.0 1.6 1:24.53 Web Content
3301 root 20 0 82360 9076 2236 S 4.7 0.1 22:12.74 /usr/sbin/monit
22703 jlm 20 0 2630796 242088 86628 S 3.3 1.5 0:46.72 Web Content
27698 jlm 20 0 731904 116512 80552 S 2.7 0.7 86:59.56 X
22744 jlm 20 0 3168860 489320 155604 S 2.0 3.0 0:58.50 Web Content
22765 jlm 20 0 3406244 677572 177260 S 2.0 4.2 0:44.24 Web Content
22641 jlm 20 0 2781364 275008 83152 S 1.7 1.7 0:32.21 Web Content
27777 jlm 20 0 388232 15432 6032 S 1.7 0.1 31:41.73 lxterminal
23044 jlm 20 0 2441268 86496 47736 S 1.3 0.5 0:02.79 Privileged Cont
23183 jlm 20 0 2892184 105452 48584 S 1.3 0.6 2:22.17 WebExtensions
23979 root 20 0 0 0 0 I 1.0 0.0 0:02.01 kworker/0:1-events
1966 monitor+ 20 0 83160 7184 1764 S 0.3 0.0 0:06.21 monitorix-httpd
|
|
Reporter | |
Comment 75•4 years ago
|
||
|
|
Reporter | |
Comment 76•4 years ago
|
||
======= cpu usage all window minimized to tray====
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18134 XXX 20 0 3370152 906884 545620 S 5.9 5.6 0:49.43 Web Content
17040 XXX 20 0 9901500 4.8g 2.8g S 5.0 30.6 9:10.34 firefox
18148 XXX 20 0 3209304 726604 488208 S 5.0 4.5 1:28.80 Web Content
18096 XXX 20 0 3538508 873408 598032 S 4.6 5.4 1:08.76 Web Content
18042 XXX 20 0 3469164 914764 664692 S 2.0 5.6 0:35.72 Web Content
18115 XXX 20 0 3829076 1.2g 804128 S 1.3 7.5 1:45.62 Web Content
27777 XXX 20 0 388128 20880 10784 S 1.3 0.1 31:18.10 lxterminal
18186 XXX 20 0 3549208 1.0g 710036 S 1.0 6.5 1:41.32 Web Content
16832 root 20 0 9252 1384 708 R 0.7 0.0 4:29.45 top
27585 root 20 0 1054912 728 0 S 0.7 0.0 62:37.80 veracrypt
27698 XXX 20 0 2149844 1.3g 1.3g S 0.7 8.5 85:28.95 X
27717 XXX 20 0 751148 5664 3192 S 0.7 0.0 40:19.21 veracrypt
3243 root 20 0 9256 164 20 S 0.3 0.0 14:00.80 wpa_supplicant
18556 root 0 -20 0 0 0 I 0.3 0.0 0:00.07 kworker/2:1H-mmc_complete
27600 root 0 -20 0 0 0 S 0.3 0.0 1:49.71 loop0
27609 root 20 0 0 0 0 S 0.3 0.0 0:13.64 dmcrypt_write/2
27715 XXX 20 0 10580 492 244 S 0.3 0.0 0:27.05 xscreensaver
1 root 20 0 2340 24 0 S 0.0 0.0 0:12.97 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.42 kthreadd
======= cpu usage 6 windows on workspace 44 windows at total (448 tabs ;) )====
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19235 jlm 20 0 9780364 4.7g 2.8g S 31.0 30.4 2:27.21 firefox
19369 jlm 20 0 3715984 1.1g 764276 S 29.7 6.9 0:51.88 Web Content
19446 jlm 20 0 3422396 897808 601616 S 22.1 5.5 0:45.92 Web Content
19389 jlm 20 0 3319112 792304 542864 S 11.9 4.9 0:29.19 Web Content
19465 jlm 20 0 3223876 812280 603976 S 9.9 5.0 0:18.79 Web Content
19309 jlm 20 0 3196412 754280 591788 S 8.9 4.6 0:22.17 Web Content
19427 jlm 20 0 3002420 572032 366544 S 8.6 3.5 0:19.37 Web Content
27777 jlm 20 0 388488 20996 10784 R 5.3 0.1 31:22.82 lxterminal
19408 jlm 20 0 3197868 717480 455092 S 4.6 4.4 0:19.54 Web Content
27698 jlm 20 0 2270736 835592 798900 S 4.0 5.1 85:56.50 X
19355 jlm 20 0 3383816 961936 661684 S 3.0 5.9 0:17.60 Web Content
27585 root 20 0 1054912 740 0 S 1.0 0.0 62:39.56 veracrypt
16832 root 20 0 9252 1384 708 R 0.7 0.0 4:31.34 top
2567 root -51 0 0 0 0 S 0.3 0.0 10:47.99 irq/127-iwlwifi
===== cpu usage without mapp patch 6 windows on workspace 44 windows at total =====
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22543 jlm 20 0 12.8g 1.2g 260268 S 117.6 7.8 18:34.67 firefox-bin
22790 jlm 20 0 2602472 226692 68580 R 27.6 1.4 3:17.34 Web Content
22813 jlm 20 0 3152608 434476 103520 S 14.3 2.7 2:18.63 Web Content
22721 jlm 20 0 3070212 452112 120728 S 13.6 2.8 2:38.34 Web Content
45 root 20 0 0 0 0 S 11.3 0.0 9:17.77 kcompactd0
22836 jlm 20 0 2747376 254088 81264 S 8.0 1.6 1:24.53 Web Content
3301 root 20 0 82360 9076 2236 S 4.7 0.1 22:12.74 /usr/sbin/monit
22703 jlm 20 0 2630796 242088 86628 S 3.3 1.5 0:46.72 Web Content
27698 jlm 20 0 731904 116512 80552 S 2.7 0.7 86:59.56 X
22744 jlm 20 0 3168860 489320 155604 S 2.0 3.0 0:58.50 Web Content
22765 jlm 20 0 3406244 677572 177260 S 2.0 4.2 0:44.24 Web Content
22641 jlm 20 0 2781364 275008 83152 S 1.7 1.7 0:32.21 Web Content
27777 jlm 20 0 388232 15432 6032 S 1.7 0.1 31:41.73 lxterminal
23044 jlm 20 0 2441268 86496 47736 S 1.3 0.5 0:02.79 Privileged Cont
23183 jlm 20 0 2892184 105452 48584 S 1.3 0.6 2:22.17 WebExtensions
23979 root 20 0 0 0 0 I 1.0 0.0 0:02.01 kworker/0:1-events
1966 monitor+ 20 0 83160 7184 1764 S 0.3 0.0 0:06.21 monitorix-httpd
|
|
Reporter | |
Comment 77•3 years ago
|
||
|
|
Reporter | |
Comment 78•3 years ago
|
||
is there anybody working on this topic?
|
|
Reporter | |
Comment 79•3 years ago
|
||
still present on 91.0.2
top - 13:09:04 up 1 day, 58 min, 2 users, load average: 1.53, 1.43, 1.31
Tasks: 243 total, 2 running, 241 sleeping, 0 stopped, 0 zombie
%Cpu(s): 38.7 us, 7.1 sy, 0.0 ni, 52.4 id, 0.3 wa, 1.1 hi, 0.3 si, 0.0 st
MiB Mem : 15917.8 total, 472.8 free, 4386.7 used, 11058.3 buff/cache
MiB Swap: 17000.0 total, 15853.3 free, 1146.7 used. 686.1 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26778 jlm 20 0 12.9g 1.5g 324796 S 83.6 9.6 84:52.40 firefox
26958 jlm 20 0 3086148 408932 80556 R 49.0 2.5 45:33.62 Web Content
27070 jlm 20 0 2955908 340468 67592 S 18.1 2.1 77:29.74 Web Content
26978 jlm 20 0 3161668 518408 79532 S 9.9 3.2 41:12.88 Web Content
10991 jlm 20 0 474712 107368 76908 S 5.6 0.7 11:55.81 X
11062 jlm 20 0 323076 19500 11156 S 3.9 0.1 2:48.93 lxterminal
26878 jlm 20 0 3007232 378440 91392 S 3.0 2.3 8:55.92 Web Content
26935 jlm 20 0 2832256 263440 69184 S 3.0 1.6 12:18.45 Web Content
27047 jlm 20 0 3104980 439780 184664 S 3.0 2.7 3:53.99 Web Content
27024 jlm 20 0 2608296 210240 85276 S 2.3 1.3 11:39.73 Web Content
26651 jlm 20 0 9276 2824 2080 R 1.3 0.0 2:03.17 top
4535 elena 20 0 16.3g 22776 13888 S 0.7 0.1 3:15.32 chrome
4695 elena 20 0 20.4g 60960 26256 S 0.7 0.4 0:19.17 chrome
4760 elena 20 0 20.4g 156236 43204 S 0.7 1.0 28:55.46 chrome
11005 jlm 20 0 4400 2280 2100 S 0.7 0.0 0:02.27 xscreensaver
|
||
Updated•3 years ago
|
|
|
Reporter | |
Comment 80•3 years ago
|
||
with the patch provided in next comment I've a REALLY low usage on 91.0.2
there is some debug stdout print that should be changed...
jlm@jlmyoga900 ~ $ top
top - 22:49:04 up 1 day, 10:38, 2 users, load average: 2.09, 2.63, 2.89
Tasks: 262 total, 2 running, 260 sleeping, 0 stopped, 0 zombie
%Cpu(s): 10.0 us, 3.2 sy, 0.1 ni, 82.5 id, 1.8 wa, 1.9 hi, 0.4 si, 0.0 st
MiB Mem : 15917.8 total, 759.0 free, 5247.9 used, 9910.9 buff/cache
MiB Swap: 17000.0 total, 14545.8 free, 2454.2 used. 952.7 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12913 jlm 20 0 24.6g 426776 36336 S 9.3 2.6 33:06.22 chrome
18071 jlm 20 0 11.6g 1.3g 261520 R 8.3 8.1 11:42.81 firefox
18344 jlm 20 0 3033144 453144 121192 S 7.3 2.8 0:53.49 Web Content
18367 jlm 20 0 3339524 636596 119812 S 5.0 3.9 1:45.93 Web Content
10991 jlm 20 0 446628 62236 35400 S 4.6 0.4 30:20.05 X
11062 jlm 20 0 324496 18884 9476 S 2.6 0.1 5:22.98 lxterminal
12546 jlm 20 0 16.5g 35124 12992 S 2.0 0.2 2:53.39 chrome
18301 jlm 20 0 2972696 415512 102088 S 2.0 2.5 0:50.04 Web Content
11007 jlm 20 0 444312 8624 4576 S 1.7 0.1 11:58.08 veracrypt
18177 jlm 20 0 3115268 479476 116228 S 1.7 2.9 1:56.50 Web Content
18232 jlm 20 0 2785284 271352 88024 S 1.7 1.7 0:22.87 Web Content
3178 root -51 0 0 0 0 S 1.0 0.0 0:11.03 irq/142-i2c_hid
18252 jlm 20 0 2838012 285588 85952 S 1.0 1.8 0:27.37 Web Content
18321 jlm 20 0 2742756 287848 71696 S 1.0 1.8 0:26.46 Web Content
3609 root 20 0 1046904 672 0 S 0.7 0.0 6:57.40 veracrypt
18275 jlm 20 0 2728760 209640 82936 S 0.7 1.3 0:12.84 Web Content
26651 jlm 20 0 9276 1148 444 R 0.7 0.0 6:14.60 top
2704 root -51 0 0 0 0 S 0.3 0.0 2:59.28 irq/127-iwlwifi
2926 root -51 0 0 0 0 S 0.3 0.0 0:09.88 irq/51-SYNA2B29
3296 root 20 0 9172 924 412 S 0.3 0.0 3:29.70 wpa_supplicant
|
|
Reporter | |
Comment 81•3 years ago
|
||
|
Assignee | |
Comment 82•3 years ago
|
||
I'm not an X11 expert, but modulo some code style nits etc it seems reasonable? How does Wayland deal with this, just by not painting? If so your approach is superior, since it should also stop video decoding etc, I believe.
Can you submit it following the instructions here? That way it can get reviewed etc.
|
|
Reporter | |
Comment 83•3 years ago
|
||
I think this is better that a firefox dev review it and propose a patch in accordance to your dev rules, because I use gentoo build system to perform most of the task including building... and it will take me ages just to check that dependencies are installed according to your rules, and understand how to build and what files to change... so I guess it will take me more than a full week just to manage to build firefox, and after that the patch can begin to be reviewed/adapted...
I tried to find a solution even if I've no knowledge about firefox code and design, so my approach is to recreate visibility events according to X11 behavior, seems to work fine so far (I'm writing this on the patched version, and so far I don't have any issue) but I'm more used to X11 protocol than even GDK (tooks me ages to find how to receive mapping events!!! which is really annoying since mapping/unmapping is some extensively used events.... so I wonder how GDK app survived with a bug that still render the window even if the window is not visible and that don't even report the window as not visible if the window is unmapped, leaving the GDK user have to write specific code to handle the event... it's like having a framework for driving a car that don't report if the engine if off or on... 0_0)
|
|
Assignee | |
Comment 84•3 years ago
|
||
Sure, I'm happy to submit it on your behalf. I think the map_event / unmap_event bits are completely unnecessary aren't they? At least from the gtk docs it seems unmap_event at least should be unmap-event instead. And I don't see any reference to map-event (and the callback does nothing anyways right?).
|
|
Reporter | |
Comment 85•3 years ago
|
||
mapping event are not required and not used, in fact visibility/Expose event are generated after a mapping event and so re-routing mapping events to visibility is not useful.. I left the code because it could be usefull but I think it can be cleaned... (some for std::cout debugs lines)
|
|
||
Comment 86•3 years ago
|
||
Naive non-programmer question: Does this patch also work with layers.gpu-process.force-enabled=true (restart required) and maxbe fix its still (?) existing bug on non-compositing window managers? (bug 1572625 comment 10) The GPU process will be required for VAAPI hardware video decoding.
|
|
||
Comment 87•3 years ago
|
||
Hm, does that patch do anything new then compared to the one already attached above (https://phabricator.services.mozilla.com/D106217)? We could simply land that one then.
It does not, however, fix the issue described in the bug title, and it guess the new patch does not as well.
How does Wayland deal with this, just by not painting? If so your approach is superior, since it should also stop video decoding etc, I believe.
Indeed, that's tracked in bug 1695227. It should be added though that the Wayland solution does work for all obscured situations.
|
|
Assignee | |
Comment 88•3 years ago
|
||
This is basically a cleaned-up version of the patch submitted in the
comments, which the author claims to work (it's very similar to your
original patch).
I don't manage to get the fully-occluded state in either GNOME+XOrg,
XWayland, or Wayland, fwiw. Is that expected?
Do we have some sort of occlusion tracking on Wayland somewhere else?
Does it stop video decoding?
|
|
||
Updated•3 years ago
|
|
|
Assignee | |
Comment 89•3 years ago
|
||
Gah, submitted the above before reading comment 87. I don't know why the original patch would have to reintroduce the mIsFullyOccluded member btw.
|
|
||
Comment 90•3 years ago
|
||
Gah, submitted the above before reading comment 87. I don't know why the original patch would have to reintroduce the
mIsFullyOccludedmember btw.
Not exactly sure either - it looks to me like some additional optimizations. I just reintroduced them as they had been there before.
I don't manage to get the fully-occluded state in either GNOME+XOrg,
XWayland, or Wayland, fwiw. Is that expected?
Yes - this mostly/only affects non-composited window managers / legacy setups - Mutter is always composited (minus fullscreen unredirect).
For the record: such setups usually lots of tearing if the driver does not support the Xorg "TearFree" setting, which again pops up again and again as the reason for some heavy glitches with HW-WR (just today: bug 1715429 comment 12), so I'm inclined to blocklist HW-WR when paired with the classic Intel DDX driver. That again would make most of these setups return to software rendering, which again appears to make some affected WMs properly report occlusion states as described in the title.
|
|
Reporter | |
Comment 91•3 years ago
|
||
(In reply to Robert Mader [:rmader] from comment #87)
Hm, does that patch do anything new then compared to the one already attached above (https://phabricator.services.mozilla.com/D106217)? We could simply land that one then.
It does not, however, fix the issue described in the bug title, and it guess the new patch does not as well.How does Wayland deal with this, just by not painting? If so your approach is superior, since it should also stop video decoding etc, I believe.
Indeed, that's tracked in bug 1695227. It should be added though that the Wayland solution does work for all obscured situations.
it does more : the patch you quote doesn't handle in fact the mapping events of X11.... which means that when a window is sent to another workspace, it is still believed to be displayed... gdk is buggy, it generate visibility event only for X11 visibility events, X11 has 2 levels of visibility : mapped and once mapped, if it is partially displayed or not (visibility), visibility events aren't always sent, in particular if the window is unmaped
the bug was caused by window that are unmapped, but still thinks they are visible. (eg almost all window on other workspace)
|
|
||
Comment 92•3 years ago
|
||
FTR, Bug 1730533 touches a bunch of mapping related code, potentially doing a part of what's done here.
|
|
||
Comment 93•3 years ago
|
||
(In reply to Robert Mader [:rmader] from comment #92)
FTR, Bug 1730533 touches a bunch of mapping related code, potentially doing a part of what's done here.
Bug 1730533 solves situation when GdkWindow is deleted/changed and we need to restart/update compositor and GL context. It does not check actual window visibility.
|
|
||
Comment 94•3 years ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #93)
Bug 1730533 solves situation when GdkWindow is deleted/changed and we need to restart/update compositor and GL context. It does not check actual window visibility.
IIUC it is about mapping events, which appear to be important here as well. But sure, the visibility event tracking comes on top.
|
|
||
Updated•3 years ago
|
|
|
||
Comment 95•3 years ago
|
||
FYI: Bug 1737068 with map/unmap tracking has landed. It already suspends compositor when window is unmapped.
|
|
Assignee | |
Comment 97•2 years ago
|
||
Per matrix discussion the situation is:
- This works on Wayland
- There's no (reliable at least) way to do this on composited X11.
- Doing it on uncomposited X11 is doable using
nsWindow::OnMap/nsWindow::OnUnmap. Someone can send a patch if they want for that, but given we can't fix it in the most common environments it doesn't seem worth doing.
Let me know if I got that summary wrong Martin/Robert. But given that this seems wontfix.
|
|
||
Updated•2 years ago
|
|
|
||
Updated•1 year ago
|
|
|
||
Updated•1 year ago
|
|
||
Comment 98•1 year ago
|
||
|
|
||
Updated•1 year ago
|
|
||
Comment 99•1 year ago
|
||
| bugherder | ||
Description
•