Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Xlib clipboard/selection requests do not play well with the powersave FPS-cap #39422

Closed
Meriipu opened this issue Jun 9, 2020 · 6 comments · Fixed by #41910
Closed

Xlib clipboard/selection requests do not play well with the powersave FPS-cap #39422

Meriipu opened this issue Jun 9, 2020 · 6 comments · Fixed by #41910

Comments

@Meriipu
Copy link
Contributor

Meriipu commented Jun 9, 2020

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

Edit: kind of a regression (see #39422 (comment) ). Introduced in ac14efc.

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
Copy link
Contributor Author

Meriipu commented Jun 9, 2020

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 Calinou changed the title [Linux] Certain editor-actions [e.g. ctrl+c] causes sluggish other applications [Firefox] Certain editor-actions [e.g. ctrl+c] causes sluggish other applications [Firefox] Jun 10, 2020
@Calinou
Copy link
Member

Calinou commented Jun 10, 2020

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
Copy link
Contributor Author

Meriipu commented Jun 18, 2020

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 ac14efc

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
Copy link
Member

Calinou commented Jun 18, 2020

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 Meriipu changed the title Certain editor-actions [e.g. ctrl+c] causes sluggish other applications [Firefox] Decouple processing of xevents from powersave FPS-cap Jun 19, 2020
@Meriipu
Copy link
Contributor Author

Meriipu commented Jun 19, 2020

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).

case SelectionRequest: {
XSelectionRequestEvent *req;
XEvent e, respond;
e = event;
req = &(e.xselectionrequest);
if (req->target == XInternAtom(x11_display, "UTF8_STRING", 0) ||
req->target == XInternAtom(x11_display, "COMPOUND_TEXT", 0) ||
req->target == XInternAtom(x11_display, "TEXT", 0) ||
req->target == XA_STRING ||
req->target == XInternAtom(x11_display, "text/plain;charset=utf-8", 0) ||
req->target == XInternAtom(x11_display, "text/plain", 0)) {
CharString clip = clipboard_get().utf8();
XChangeProperty(x11_display,
req->requestor,
req->property,
req->target,
8,
PropModeReplace,
(unsigned char *)clip.get_data(),
clip.length());
respond.xselection.property = req->property;
} else if (req->target == XInternAtom(x11_display, "TARGETS", 0)) {
Atom data[7];
data[0] = XInternAtom(x11_display, "TARGETS", 0);
data[1] = XInternAtom(x11_display, "UTF8_STRING", 0);
data[2] = XInternAtom(x11_display, "COMPOUND_TEXT", 0);
data[3] = XInternAtom(x11_display, "TEXT", 0);
data[4] = XA_STRING;
data[5] = XInternAtom(x11_display, "text/plain;charset=utf-8", 0);
data[6] = XInternAtom(x11_display, "text/plain", 0);
XChangeProperty(x11_display,
req->requestor,
req->property,
XA_ATOM,
32,
PropModeReplace,
(unsigned char *)&data,
sizeof(data) / sizeof(data[0]));
respond.xselection.property = req->property;
} else {
char *targetname = XGetAtomName(x11_display, req->target);
printf("No Target '%s'\n", targetname);
if (targetname) {
XFree(targetname);
}
respond.xselection.property = None;
}
respond.xselection.type = SelectionNotify;
respond.xselection.display = req->display;
respond.xselection.requestor = req->requestor;
respond.xselection.selection = req->selection;
respond.xselection.target = req->target;
respond.xselection.time = req->time;
XSendEvent(x11_display, req->requestor, True, NoEventMask, &respond);
XFlush(x11_display);
} break;

@Meriipu Meriipu changed the title Decouple processing of xevents from powersave FPS-cap X11 clipboard/selection requests do not play well with the powersave FPS-cap Jun 19, 2020
@Meriipu Meriipu changed the title X11 clipboard/selection requests do not play well with the powersave FPS-cap Xlib clipboard/selection requests do not play well with the powersave FPS-cap Jun 20, 2020
@Meriipu
Copy link
Contributor Author

Meriipu commented Jun 20, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants