Closed aomader closed 7 years ago
DaveDavenport
commented
7 years ago Can you explain what is exactly horrible slow? from the timing log it looks like rofi is visible in 40ms
0.039558 (0.007370): source/view.c:rofi_view_update:728 Backgroundand a refilter (on typing) is also very fast.
aomader
commented
7 years ago I was simply moving the selected item and than quickly typing a few characters. The update after each interaction, e.g., entering a character and waiting for the screen to respond, took more than a second. If enter a few characters in quick succession, it needs a bunch of seconds to show the end result.
DaveDavenport
commented
7 years ago odd, the trace doesn't show that. I wonder if something is going wrong with repainting (so it updates, but you don't see it).
What setup do you have (Window manager, graphic card, composite manager)
DaveDavenport
commented
7 years ago You entered text and the filtering needs to be updated, so it starts filtering.
4.345048 (0.000082): source/view.c:rofi_view_refilter:835 Filter startThen very quickly it is done
4.345061 (0.000013): source/view.c:rofi_view_refilter:924 Filter doneIt then triggers a redraw of the screen
4.345064 (0.000003): source/view.c:rofi_view_update:703
4.365240 (0.020176): source/view.c:rofi_view_update:728 BackgroundAfter 20 ms, it redrawn the background.
4.411802 (0.046562): source/view.c:rofi_view_update:761 And 46 ms later it repainted all the widget.
so the repaint is around 66ms. While this is not incredibly fast (seems cairo on 4k is not the fastest), it does not suggest 'seconds'.
I don't have a 4k screen to test, but on 3k I haven't noticed extreme slowdowns. Ill see if I can do some testing.. is it non-fullscreen (rofi -show run -no-config ) better?
DaveDavenport
commented
7 years ago done some test with scaling the screen (xrandr -scale).. at 8k fullscreen I do notice a slight lag. Running compton (composite manager) makes it worse.
(there seems to be tripping point, where things suddenly starts lagging behind and key presses arrive late @ rofi.. wonder why).
DaveDavenport
commented
7 years ago More looking, there seems to be a tipping point at 37ms for the draw function.. at that point it starts lagging behind and then suddenly it takes a second for a new event to come in (into rofi from X). On large resolution (4800x2700) it takes 40ms to flush the internal surface to the xcb surface. (if I draw in xcb directly you get artifacts..) will continue to investigate.
DaveDavenport
commented
7 years ago Found one issues (and fixed) that caused extra rewrites. Working on another solution that hopefully improves the situation.
Still on 4800x2700 with composite manager, just painting to the xcb_window_t takes ages. (up to 120ms on my pc) this causes (why I don't know yet) some expose events to get lost.
Not yet sure what is the best to fix it, I could do partial redrawing (this is not trivial to implement and still a lot of actions will change most of the screen at once). Another, but no idea if it helps, is to give each widget it own X window. (very old (pre-cairo) rofi used to do this), not sure if this will be a speedup (but code will be less clean).
DaveDavenport
commented
7 years ago A patch to try, to see if it improves things: https://filebin.pw/Qn3n/
aomader
commented
7 years ago My setup is as follows:
Here a few remarks to your latest points:
rofi -show run -no-config is instant, yet not really a surprise, given that the windows is much smaller--backend glx --vsync opengl-mswc --xrender-sync --unredir-if-possible --paint-on-overlay --glx-no-stencil)Using your proposed patch makes the situation a bit better. The response is faster, but still far from instant. This however only applies to running rofi with compton.
DaveDavenport
commented
7 years ago Good to hear patch helps. Problem is the painting of the window with compton enabled just takes to long. I don't see a quick short-term solution to this.
I find it a bit weird that 1.2.0 did not have this problem as very little changed in the way of painting. There is some extra clipping set, I could remove that but this is only a small difference. (did some bench-marking on this before) (I did notice however that the point between smooth/non smooth is a hair trigger. I need to check if X has some kind of timeout for expose events.)
Ill keep playing with it.
DaveDavenport
commented
7 years ago While thinking I don't see a quick solution, I actually realized one, can you test the following patch:
https://filebin.pw/nEuA7/ https://filebin.pw/hRul0h/
(Thanks for testing the patches, this really helps).
It is not perfect yet, but solves the problem for me at > 4k screens.
(Instead of trying to send a expose event via X. (not the best solution) I now ask the GMainloop to repaint the window the moment it becomes idle. This way I won't miss redraws.. downside might be that under heavy load redraws are done less frequent.....)
aomader
commented
7 years ago Tried it. When doing things faster you kinda feel that frames are lost, but overall it feels "better", especially when compton is not running. However, the problem still exists with compton running. It's actually quite easy to trigger the "event lost" behaviour by typing something really fast. At some point it stops updating and then nothing happens anymore, until you hit any key.
However, I still thing this patch is a worthy addition. At least in my opinion, it makes rofi behave more 'instant' when compton is not running. 👍
DaveDavenport
commented
7 years ago hmm curious weird.. with the patch it should update when it is idle, so when idle you should see the last update. The redraw should always happen when rofi is idle. Only if the cpu is fully overloaded that blinking takes all cpu (and it doesn't, and the blink should redraw the screen anyway)
I tested it here with up to 5760x3240 and it skipped a bit, but always showed the final result..
Well back to the drawing table :sweat_smile:
Edit: frustrating, I cannot reproduce this.... at 4x4 scaling 7680x4320 this pc completely gives up :smile:
DaveDavenport
commented
7 years ago Tried your exact compton flags, it is completely unusable for me.. Xorg just eats 100% cpu and halts to a grind. removing the GLX backend makes everything speedy again.
What I am experiencing with glx backend kinda feels like this: https://github.com/chjj/compton/issues/152 It just stops updating for seconds, Xorg pulls 100% cpu.
Adding --xrender-sync-fence to compton improved things for me significant, remove --paint-on-overlay even more so. Can you try this? (and non glx backend).
aomader
commented
7 years ago Thanks for the hint with compton, that actually solved the problem! It's much faster now. I also ditched (as recommended here) the xf86-video-intel driver, which also made everything a bit more snappy.
How should we proceed with this issue?
DaveDavenport
commented
7 years ago I am happy that the huge delays in redraw where not directly a rofi issue, because I was running out of ideas why final redraw did not happen. I guess the original bug is solved by this.
Still think patches are useful, they solve some clumsiness I never had reason to fix before that improves responsiveness. Also there is one more fix I want to try to see if I can make the flipping to new output faster.
DaveDavenport
commented
7 years ago The last thing seems to have been the golden solution, this is instance even with your settings on 6.5k screen. https://filebin.pw/rh5qZc/
There is slightly more glitch when resizing, will look at that.
DaveDavenport
commented
7 years ago This is now instant with the above compton: https://filebin.pw/3ciO/
aomader
commented
7 years ago The patch works and I also feel an improvement. Seems like a worthy addition.
DaveDavenport
commented
7 years ago Yeah going to merge it.. the 'flipping' (copying buffered rofi view on window) went back from > 10-20 ms for full hd to 15 us. brilliant. Need to do something similar for the fake background, but need to see how I can convert from different visuals/depths with xcb, I used a 2 x copy with cairo to do this now...
github-actions[bot]
commented
3 years ago This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Version
Configuration
Launch Command
I compiled
rofiwith--enable-timingsand simple usedrofi -show run.Steps to reproduce
DP1 connected primary 5376x3024+0+0 (normal left inverted right x axis y axis) 600mm x 340mm panning 5376x3024+0+0What behaviour you see
rofiis horribly slow using the latest git version, I can't recall the previous version I exactly used, but it didn't have that problemrofi1.2.0 the behaviour is much better, still not instant but much fasterWhat behaviour you expect to see
Other resources
Here is the output of the timing log: