FS#72304 - [grafx2] 2.8-1 and before - mouse movement choppy on SDL2 backend

Attached to Project: Community Packages
Opened by Pavle (pio) - Thursday, 30 September 2021, 17:11 GMT
Last edited by Alexander F. Rødseth (xyproto) - Tuesday, 12 October 2021, 11:39 GMT
Task Type Feature Request
Category Upstream Bugs
Status Closed
Assigned To Alexander F. Rødseth (xyproto)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
For some time now, mouse movement in this program is very choppy when using certain tools, more noticeable fullscreen.

The workaround is to use X11 backend instead of SDL2. I've attached the sample PKGBUILD - one additional change was needed to compile.

The bug is reported upstream here: https://pulkomandy.tk/projects/GrafX2/ticket/136

Steps to reproduce:
Maximize the window, start any tool with crosshair cursor (e.g. 'b' key).
   PKGBUILD (1.7 KiB)
This task depends upon

Closed by  Alexander F. Rødseth (xyproto)
Tuesday, 12 October 2021, 11:39 GMT
Reason for closing:  Upstream
Additional comments about closing:  grafx2+SDL2+Wayland is ok, an upstream issue has been created for grafx2+SDL2+X.
Comment by Pavle (pio) - Saturday, 02 October 2021, 15:53 GMT
I've just noticed that X11 backend has another issue with brush display when zoomed, so it's probably best to make a separate grafx2-x11 package in AUR... Didn't try SDL1.2 backend.
Comment by Alexander F. Rødseth (xyproto) - Monday, 11 October 2021, 12:12 GMT
Thanks for reporting the issue and caring about the grafx2 package.

Is it just the combination of X and SDL2 that results in choppy behavior, or is it also choppy under Wayland and SDL2 (like in Sway, for instance)?

As I see it, Wayland is slowly becoming more important than X (if it isn't already), so if it is choppy under X but fine under Wayland, then a package that targets X and is in AUR could be a good solution.

Also, most SDL2 applications are not choppy, neither using the X protocol nor using the Wayland protocol. Perhaps upstream will fix this.
Comment by Pavle (pio) - Monday, 11 October 2021, 15:42 GMT
Hi again! I've run some tests on a netbook with Intel Atom gfx.

Grafx2-SDL2 in Wayland: fine if somewhat slow in general
Grafx2-SDL2 in X: very choppy when using crosshair and big brushes

Grafx2-X11 in X: bigger brushes displayed incorrectly when zooming in

Grafx2-SDL1.2 in Wayland: doesn't run
Grafx2-SDL1.2 in Wayland with xorg-xwayland installed: fine if somewhat slow in general
Grafx2-SDL1.2 in X: everything seems OK

So I can conclude that SDL2 backend works fine on Wayland, but it's subtly broken in X11. The solution to this bug upstream was postponed to a distant milestone. SDL1.2 backend is optimal in X, but requires xorg-xwayland to run in Wayland. X11 backend shouldn't be used because of a different bug: brush getting cropped. I see now there is no optimal solution, so it's best perhaps to keep it as it is, with additional SDL1.2 package in AUR for users of X.
Comment by Alexander F. Rødseth (xyproto) - Tuesday, 12 October 2021, 11:38 GMT
Yes. This sounds like users of Grafx2+SDL2+Wayland can live with the current state of things, that Grafx2+SDL1+X users could use AUR and that upstream could fix remaining issues over time.

Thanks for testing!

Loading...