Someone would have to take over maintaining it then. I’m not a GTK guy.
Just to complete my experiments xterm is also slow …
So it is not what is shown in the window that slows things down.
I was thinking weather qt5 or gtk could make a difference, but I use Termite as terminal and that’s Gtk and also fast. Plus xterm in neither and still slow.
If I had a Pinebook and the skills I would be doing the maintaining of both DEs.
As I said before - as OB does not support -insert technical term for floating and redrawing windows or whatever- there still might be a slight performance gain from the similiar setting it does support - that of not resizing items in windows in real time.
I played around a bit more and here is a workaround:
If you install the compositor compton and run it from the terminal I get these error messages:
manjaro@archlinux ~> compton [ 02/15/19 13:37:04.669 vsync_opengl_swc_swap_interval ERROR ] Your driver doesn't support SGI_swap_control nor MESA_swap_control, giving up. [ 02/15/19 13:37:04.669 vsync_opengl_init ERROR ] Your driver doesn't support SGI_video_sync, giving up. [ 02/15/19 13:37:04.669 session_init FATAL ERROR ] Failed to initialize the backend
However if you start it with --vsync none
manjaro@archlinux ~> compton --vsync none [ 02/15/19 13:38:31.892 vsync_opengl_swc_swap_interval ERROR ] Your driver doesn't support SGI_swap_control nor MESA_swap_control, giving up.
You still get an error but compton seems to be willing to live with that.
From now the window movement is always relative fluent, however I feel it’s not as smooth as QTerminal without compton. This probaby can be tuned further, as I actually don’t want display effects.
It might also be interesting to investigate the error messages that comption throws. How could they be avoided.
And while I am at it. How could I use GLX instead of xrenderer ?
When I was running XFCE on an old intel I used options like these:
# GLX backend backend = "glx"; # vsync = "opengl-swc"; # sw-opti = true; paint-on-overlay = true; glx-no-stencil = true; # glx-copy-from-front = false; # glx-use-copysubbuffermesa = false; glx-no-rebind-pixmap = false; # glx-swap-method = "undefined"; # glx-use-gpushader4 = true; xrender-sync = true; xrender-sync-fence = true;
I have been looking into this a bit.
I found the proprietary mali blobs, so when installing those together with the
xf86-video-fbturbo-git driver smooths out the lagging of window dragging quite a bit.
The mali blobs package is not in the repo yet, but will be later, so you guys can install it and test.
PS: I still need to test some stuff, where I hopefully can get the mali kernel module going. But no promises though.
PPS: Written from my Pinebook.
I have installed these packages, is that correct ?
Also written on my Pinebook
That’s correct. Even though I’m not sure the
pine64-libgl-x11 actually does anything to help.
It does contain the mali blobs though, so it’s there for future use at least.
Well, there is definitely a speed boost.
Firefox and lxqt-config (strangely another very slow window) are quite smooth now. There are sometimes some jumps, however it almost feels as if that could be the mouse/trackpad and not the graphic.
Interestingly compton still complains about missing glx functionality…
vsync_opengl_swc_swap_interval ERROR ] Your driver doesn't support SGI_swap_control nor MESA_swap_control, giving up.
How does that work together with the Lima driver ?
glxgears has become if anything slower btw, from ~23fps to ~19fps in full screen. (1080)
Does anybody know a good result that the Mali400 GPU should be able to achieve with glxgears (part of the
mesa-demos package) ?
I admit I have now idea how this all plays together …
Is there some docu somewhere to see how this all adds up?
Getting better performance requires the mali driver to be functional I guess.