Re:Flow browser passes the Acid tests
by freeone3000 on Saturday June 13, 2020 @10:28AM
(#23509585)
-j4 on a pi freezes the UI because you're using 100% of all cores continually for minutes - smaller chunks of work and better scheduling (or the "trick" of -j3) fixes this, and it's doubtful that a browser uses 100% of CPU for any length of time.
I know how to tackle such problems.
My comment is rather about "multi-core UI". Many UI tasks have almost real-time requirements (animations, synchronized rendering, video) so they behave as "make -j 4" meaning that the device is just busy rasterizing pixels but not doing anything meaningful.
And all that while we have dedicated powerful (YMMV) GPU that supposed to do those for us.
Re:Flow browser passes the Acid tests
by chrisseaton on Saturday June 13, 2020 @10:58AM
(#23509840)
I don't think you can run layout code on a GPU effectively. It isn't a data-parallel problem.
Obviously actual pixel rendering is is done on a GPU - why would you do it it anywhere else, but that's not what we're talking about here.
Re:Flow browser passes the Acid tests
by freeone3000 on Saturday June 13, 2020 @11:01AM
(#23509867)
It's real-time but not particularly CPU-hungry. Playback an animation and see how much CPU time it actually uses - you'll end up yielding most of the time, so other apps can use the remainder just fine.
If make -j4 makes your UI unresponsive, it is probably due to swapping. The CPU scheduler lowers the priority of CPU intensive tasks over time.
It could be that you need to “renice -5” X11 or something (I think some distributions used to tweak the UI runtime priorities. Not sure if they still do.)
The only reasonable option for UI rendering these days (high-DPI monitors) is to delegate rasterization to GPU. CPU is for running application logic. If you would do UI on CPU then this will be the only task your CPU will do. E.g. animations require stable frame rate (60 FPS or more) so UI must run on highest possible priority on your OS.