I recently upgraded to a higher resolution monitor, and found that switching workspaces now takes ~1 second. While there was a barely noticable delay before, at 2048x1600 it's painful, so I investigated.
The time is taken within wWorkspaceMapUpdate, which updates the workspace's image for the workspace map.
I tend to switch workspaces frequently, but have never used the workspace map. I didn't even know it existed, and it's not bound to any key (the only way to reach it, it seems from inspecting the source) on the default configuration. I've tried binding a key to that command (on a different system, an Ubuntu x86 VM), and it doesn't actually seem to have any effect (though I haven't investigated why).
So it seems quite wrong to slow down a frequent operation for the sake of a very rare one!
Potential approaches to improve:
Don't update previews if workspace map isn't bound to any key (=> the workspace map is inaccessible)
Don't update preview until the workspace map is constructed / shown for the first time
Use a faster method of scaling down image to preview (this seems to take about half the excess time)
Defer scaling operation until after the workspace switch has completed, to minimise user-observed latency (would approximately half the response time)
Use COMPOSITE. This is probably a more radical change but would likely solve the issue entirely.
Version: 0.95.8 System: Raspbian, Raspberry Pi 4
I recently upgraded to a higher resolution monitor, and found that switching workspaces now takes ~1 second. While there was a barely noticable delay before, at 2048x1600 it's painful, so I investigated.
The time is taken within
wWorkspaceMapUpdate
, which updates the workspace's image for the workspace map.I tend to switch workspaces frequently, but have never used the workspace map. I didn't even know it existed, and it's not bound to any key (the only way to reach it, it seems from inspecting the source) on the default configuration. I've tried binding a key to that command (on a different system, an Ubuntu x86 VM), and it doesn't actually seem to have any effect (though I haven't investigated why).
So it seems quite wrong to slow down a frequent operation for the sake of a very rare one!
Potential approaches to improve: