Delay when switching focus/selection from windows to xfdesktop

I can reproduce this without window scaling on a 2K display.

Thank you for testing @Tamaranch Good to know that I am not alone. That increases the chance that this annoying bug gets fixed dramatically.

I am not seeing this issue with git master (or maybe it is harder to spot than I think).

Please check if building xfdesktop from git master resolves the problem.

I use git master and can reproduce the problem, however on an old machine as usual.

Is my machine really that slow? It's running on an SSD drive:

And I thought I have a fast machine but you're right, the system is 13 years old now.

This issue now looks related to #284 (closed) and the discussion about there being a full redraw of the desktop on focus events.

Some performance tweaks were already implemented in !115 (merged) (WIP).

I just looked at the 4.18 code, and there should still be a full redraw on focus in/out on 4.18 as well. So something else is causing this perf regression.

I don't think this had been established before, but I've tested with xfdesktop 4.18.1 and can confirm that this is indeed a regression. Also I'm currently running !115 (merged) so it doesn't fix this problem.

Gaël, could you please kick in your profiler :D
https://www.phoronix.com/news/GNU-Profiler-gprofng

So this is strange. Running 4.18 in gdb, breaking on gtk_widget_real_focus_in_event() -- it's never called. But it's called on master and in 4.19. And I'm not sure why.

Somehow gtk_window_focus_in_event() is still called on 4.18, though, which is weird -- it returns FALSE, so the GtkWidget impl should be called, I would think.

Ok, one-liner. Not sure why I changed gtk_widget_set_accept_focus(), but that seems to be the culprit. I think it's ok for that to be FALSE because XfceDesktop still accepts focus, and XfdesktopIconView's keyboard navigation works by listening for events on its parent widget/window. Which is weird, but...

Even more embarrassingly, this is something that happened before, and was fixed already, and I broke it again.

I'll still probably merge in !115 (merged), since that will further reduce unnecessary work xfdesktop has to do, but this focus in/out issue should be no more.

Unfortunately, it doesn't fix the problem for me. Now that I'm comparing it with 4.18, it's immediately obvious, but I don't think it makes much difference anyway with or without this commit (I've only tested by eye, though, I don't do precise measurements).

Gaël, could you please kick in your profiler :D

Sorry, I didn't understand

Aw, c'mon, that's just not fair

Any change with this fix, plus !115 (merged)?

No, I also rebased !115 (merged) locally. I'll do a bisection later to try and get a better idea of the problem :)

I don't think we can identify a single guilty commit unfortunately, it's due to a series of changes that took place between 4.19.0 and 4.19.1.

The first bad commit I've identified is 4f10897c. At this stage the problem is minor though, I think if we left it at that it would be acceptable.

The second bad commit I've identified is 1f4ffd21. Here the difference is clearer.

It's not impossible that some of the commits between these two also played a small role though, but I think these are the two levels. Similarly, I sometimes think that 4.19.1 is worse than 1f4ffd21, sometimes that it's the same, so maybe there's another small level between the two.

Thank you for digging in.

So obviously given the size and scope of 4f10897c, it'll be really hard to determine exactly what part of it is slowing things down (it's why I hate large commits, but it was unavoidable this time). But I guess it's good that this commit only causes a minor slowdown. (Still, I'd like to fix it if possible.)

It's interesting that 1f4ffd21 is causing such a big difference, but I do have an idea why. Presumably it's re-rendering all the image data on focus in/out after that commit, where perhaps it wasn't doing that before. Previously the icon pixel data was being cached in the XfdesktopIcon class, but after that commit, the cache is fully inside XfdesktopIconView. And that cache does get invalidated on focus in/out. So it would make sense that this could be causing the issue.

So: do icon images actually not need to be re-rendered on focus in/out? The icon text absolutely does -- themes do change text colors and style depending on whether or not a window has focus. But do they change icon images in that way too? I would guess maybe not? And even if they do, we're of course not required to support that. So maybe the solution here is to only do partial invalidation (text only) when focus in/out occurs.

Damn, that theory is wrong. The cached pixbuf surface is only destroyed if the theme, scale factor, or icon size changes, unless I'm missing something.

Hrm or maybe not; xfdesktop_file_icon_get_gicon() is still called every time focus changes, so the cache isn't working or.... something. Will dig into that later.

Interesting; looks like GtkWidget->style_updated is called when focus changes, and I invalidate the icon pixbuf cache when that happens. Looks like that gets called when something on the GtkStyleContext is changed, which, sure, that will happen when focus in/out happens.

In 4.18 we weren't invalidating any pixbufs on style update, so... maybe that's fine to just remove.

I updated !115 (merged) with that fix; let me know if that helps. I can verify here at least that icons don't seem to get re-rendered (they do get re-drawn, though) on focus in/out.

The re-draw on style update is new in 4.19, though, so it still may be a little slower than 4.18. It is required in some instances to redraw there, though the code should really be doing a better job of checking what's actually changed (if anything) and only queuing icon redraws if actually necessary.

Well yes, I'd say the problem is solved with latest !115 (merged). It's hard to say whether we're at the level of 4f10897c or 4.19.0, but it's a matter of detail. We'd need an objective measurement to decide, and it's probably not worth the trouble. @dc_coder_84 can you confirm?

PS: not the first time this style-updated signal has caused performance problems, by the way.

@Tamaranch When I try to compile libxfce4windowing 4.19.3 I get this error when running ./autogen.sh:

libxfce4windowing/Makefile.am:18: error: ENABLE_X11 does not appear in AM_CONDITIONAL
libxfce4windowing/Makefile.am:84: error: ENABLE_X11 does not appear in AM_CONDITIONAL
libxfce4windowing/Makefile.am:89: error: ENABLE_WAYLAND does not appear in AM_CONDITIONAL
libxfce4windowing/Makefile.am:123: error: ENABLE_WAYLAND does not appear in AM_CONDITIONAL
libxfce4windowing/Makefile.am:130: error: ENABLE_X11 does not appear in AM_CONDITIONAL
libxfce4windowing/Makefile.am: installing './depcomp'
protocols/Makefile.am:1: error: ENABLE_WAYLAND does not appear in AM_CONDITIONAL
autoreconf: error: automake failed with exit status: 1

How can I fix this? I need libxfce4windowing to compile xfdesktop.

You have to install xfce4-dev-tools 4.19.0 in /usr or set some env vars, see xfce4-dev-tools#62 (comment 70812).

The environment vars did not work but installing under /usr worked.

Regarding MR !115 (merged) well maybe it got a bit better but there is still some delay.

At this point I'm having trouble seeing what else to improve; very little gets done on focus in/out now. Possibly the last thing to do would be to differentiate between invalidating the whole icon, or just the text. Could you give a little more information about your setup?

Number of monitors and their resolutions
Full 'screen' geometry (xrandr | grep -Eo 'current [0-9]+ x [0-9]+')
Number of icons on the desktop
Icon size
Font size

@dc_coder_84 also can you confirm that xfdesktop 4.19.0 works fine for you (you'll need libxfce4windowing 4.19.1 if you build it by hand).

I now captured some videos and counted the frames. This may not be super accurate but I hope it gives us some insight. Reference point to begin the counting was when a title from a window like xfce4-terminal turned from active to inactive which is visible in a change of the color of the title in the titlebar. Since the recorded videos have 60 fps one frame is 16 ms. Here are my test results for different versions of xfdesktop:

4.16.0 -> 9 frames  = 150 ms
4.17.0 -> 8 frames  = 133 ms
4.17.1 -> 19 frames = 316 ms
4.18.0 -> 18 frames = 300 ms
4.18.1 -> 17 frames = 283 ms
4.19.0 -> 19 frames = 316 ms
4.19.2git-ce2c5f6e -> 20 frames = 333 ms -> MR !115

Number of monitors and their resolutions
One monitor with 4K resolution. Gui scaling is set to 2x. Here you can see my hardware setup.
Full 'screen' geometry (xrandr | grep -Eo 'current [0-9]+ x [0-9]+')
Command line output is: current 3840 x 2160
Number of icons on the desktop
172
Icon size
48
Font size
Default which is 12

If I should do some more frame counting, just let me know

Could you also do a measurement with 4.19.1?

Number of icons on the desktop 172

Maybe that's part of the explanation, I have far fewer (12 at the moment).

4.17.1 -> 19 frames = 316 ms

So that would be the first jump for you, in fact.

Ah, good idea to take videos and count frames. Right, it seems like this started happening a lot earlier than we'd assumed.

Assuming that 4.19.1 is significantly worse than both 4.19.0 and 4.19.2git-ce2c5f6e, that would make sense given the fixes on !115 (merged).

The jump between 4.17.0 and 4.17.1 is concerning all by itself (though I am selfishly pleased it wasn't my fault :-P); figuring out what caused that and finding a better way to do things might solve our problem. 18-20 frames to redraw seems excessive, even for the larger number of icons. (I also have much fewer, about 20.)

It looks like the main change around drawing between 4.17.0 and 4.17.1 was supporting UI scale factors. To do that, drawing is done a little bit differently, so it's hard to compare directly. But one thing that definitely changed with that is if you had a 2x scale factor, 4.17.1 would load, render, and draw the icons at twice the size, or 4x the number of pixels. That certainly will slow things down a little, though I wouldn't expect quite so much!

The thing that is weird, though, is that on focus in/out, the icons aren't loaded or rendered (they're cached); the only thing that's done is that they're redrawn to the window. Cairo isn't the fastest thing in the world, but it's still a surprise to me that drawing 4x the pixels for each icon would slow things down that much.

At any rate, the icon images shouldn't need to be redrawn on focus change at all; just the text does, as I mentioned somewhere above.

I just pushed a change to !115 (merged) to redraw only the text on focus change. Maybe that improves things.

4.17.1 -> 19 frames = 316 ms

All along, I've been wondering whether we're talking about the same problem, i.e. maybe the same effect, but maybe not the same cause. Personally, I don't see any noticeable difference between 4.16 and 4.18. I've also tried a 2x scaling factor a few times in my various tests without seeing any noticeable difference. I have the impression that there's something else going on for you...

More test results:

4.19.2git-1ab3601b -> 9 frames = 150 ms -> MR 115 including commit "Only redraw icon text when focus changes"
4.19.2git-1ab3601b test with only 2 icons available instead of 172 -> 1 frame = 16 ms

Well done Brian!

I'll be back with more test results when I find time. Please be a bit patient.

Great! I think I'm going to merge !115 (merged), and maybe do another dev release soon. I expect there might be some new issues with not enough redraws, and it would be good to get some wider testing.

Okay ladies and gentlemen, I've done some more frame counting but unfortunately without any new insights. When you look at this comment you can see a jump in lag between the versions 4.17.0 and 4.17.1. I tried to find if there is a certain commit which causes this. But as I said I couldn't find a problematic commit. Maybe this is due to the frame counting varying between multiple tests with the same xfdesktop version.

Here is the data if you guys are interested. The data is sorted by commit date, the last/bottom lines are the oldest commits.

xfdesktop-xfdesktop-4.19.1 -> 35 frames, as requested by Gaël, 172 icons visible/available

xfdesktop-0cbe2819be20f650ea57fdd4af592cb4e805ff21 "Updates for release 4.17.1" -> 18 frames, 162 icons visible, 172 icons in total

xfdesktop-e9319d00b4fe87d859d310cba8cca8f5c7f01c74 "doc: README.xfconf: fix missing type for 'primary' attribute" -> 13 frames, 162 icons visible, 172 icons in total
xfdesktop-f082dfde0a0d6dd55e2e1710fa7e4bd52fb66069 "xfce-desktop: give the 'primary' property a more clear description" -> 13 frames, 162 icons visible, 172 icons in total
xfdesktop-2ae9496c3e05abe5649bb183ea67108a5eff0a87 "harmonize build-time option USE_DESKTOP_MENU to ENABLE_DESKTOP_MENU" -> 16 frames, 162 icons visible, 172 icons in total
xfdesktop-1d6fa261fa902c9dbfb09aeaf232bb586f161bb8 "Fix windowlist icon blurriness when UI scale factor != 1" -> 12 frames, 162 icons visible, 172 icons in total

xfdesktop-5119588aa6e4b86b979c8b35e0b96c98cce2d794 "Fix blurry drag icon when UI scale != 1" -> 12 frames, 162 icons visible, 172 icons in total

xfdesktop-3e3a7f625d0ea44e2e83f77d9ecc2d02f10da3ed "Fix blurry desktop icons when UI scaling != 1" -> 10 frames, 162 icons visible, 172 icons in total
xfdesktop-86ba7d14a60486a02daeea86aafcc0d4a751ca14 "Fix blurry background when UI scaling != 1"-> 11 frames, 162 icons visible, 172 icons in total
xfdesktop-f8c239495925d8c42677b83ade7969a2b8e3bef0 "Fix incorrect args to gtk_widget_queue_draw_area()" -> 12 frames, 162 icons visible, 172 icons in total
xfdesktop-374f4a4db27ea047b5db3343a2bd38a33ffe6f27 "Properly handle UI scale factor" -> 10 frames, 162 icons visible, 172 icons in total
xfdesktop-b91f69f0155a8bb2012715f69867f492df7c006c "Allow ejecting unmounted volumes" -> 5 frames, 90 icons visible, 172 icons in total

There is one jump in lag between the last two commits in the data and I think that's probably not due to a regression but the fact that roughly only half of the icons are visible on screen. A bug which has been fixed in xfdesktop-374f4a4d "Properly handle UI scale factor".

So let's keep this bug closed and many thanks for your work Gaël and Brian. And Brian, happy marriage for you and your wife

Thanks for the tests :) (as for me, I didn't do much work on this one :D)

So basically, we can conclude that we're back to 4.16 performance and that the peak was indeed in 4.19.1, where you didn't even need to have a lot of icons to see the problem (provided you had a slightly older machine, probably).

Cairo isn't the fastest thing in the world

Maybe things will get faster in the future:
GTK 4.15 Released With Vulkan Renderer By Default

closed with commit 958a6455

reopened

mentioned in commit 1ab3601b

closed with commit 094884be

added 1. Performance 1. Regression labels

Delay when switching focus/selection from windows to xfdesktop

Designs

Child items 0

Activity