Godot: Xlib clipboard/selection requests do not play well with the powersave FPS-cap

[Meriipu]

Godot version:
Godot Engine v3.2..2.beta.custom_build.aa57bb047
aa57bb0473cb3930670bcfa3159f96262dfaa1dd

Edit: kind of a regression (see https://github.com/godotengine/godot/issues/39422#issuecomment-645950551 ). Introduced in ac14efcdfb22575fc49a75201492955e723d04c3.

Or instead of decoupling, make the part that deals with selections and clipboards more efficient somehow? Xlib is not very enjoyable to deal with.

OS/device including version:
Linux

Issue description:

• Firefox with autoscroll enabled (pressing and holding middle click and dragging the mouse up causes page to scroll)
• press ctrl+c in the editor in the client. Does not need to have text selected
• Try to hold+drag middle in firefox, then after a few seconds release it
  For me, the page in firefox keeps scrolling for around a second before stopping scrolling.
  This issue persists until I select some text in firefox. After that, scrolling stops immediately upon release again.

Steps to reproduce:
1) Have the editor in a project and Firefox (my version is 76) open
2) Press ctrl+c in the editor
3) Press and hold middleclick in firefox, move the mouse a bit, release middleclick
The reticle lags behind for a second or so, long after the middleclick was released
In order to "fix it", select some text in Firefox. This fixes it until the above steps are repeated again.

[Meriipu]

I tried commenting out this line and it makes the sluggishness moderately less sluggish, but only moderately.
https://github.com/godotengine/godot/blob/master/editor/editor_node.cpp#L442

[Calinou]

This may be unrelated, but I noticed that pasting the clipboard can take a very long time in other applications, if the current clipboard data comes from Godot. (Tested on Godot 3.2.1 running KDE on Fedora 31.)

[Meriipu]

It very likely is related. I called this in a terminal

sleep 10; echo 'abc'|xclip

then caused the issue. It fixes itself when xclip is done.

It is kind of a regression, it was introduced apparently in ac14efcdfb22575fc49a75201492955e723d04c3

I say kind of and apparently because this commit just reduces the framerate when inactive from what I can tell, so the issue was likely always there, it is just that with a reduced framerate it becomes more apparent due to how the xclipboard works [in conjunction with?] the engine?

[Calinou]

It is kind of a regression, it was introduced apparently in ac14efc

I would really prefer keeping the FPS cap when the window is unfocused (think of the laptops). We should try to find another fix for this, such as running a loop dedicated to the clipboard that's not affected by any FPS limit.

[Meriipu]

This section of code gets executed multiple times (around 8) each time a paste is attempted, either via ctrl+v or via middle-click (even autoscrolling middleclick).
https://github.com/godotengine/godot/blob/d3c10e8dd60b8e771f9e3d1e1df6780491d8effe/platform/linuxbsd/display_server_x11.cpp#L2858-L2918

[Meriipu]

but yes I think it takes some guru to fix this one