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

FLTK on NetBSD very slow on X11 with Unicode locale #935

Closed
ManoloFLTK opened this issue Mar 17, 2024 · 5 comments
Closed

FLTK on NetBSD very slow on X11 with Unicode locale #935

ManoloFLTK opened this issue Mar 17, 2024 · 5 comments
Assignees
Labels
fixed The issue or PR was fixed. Platform: X11 platform specific (Unix/X11))

Comments

@ManoloFLTK
Copy link
Contributor

This is the transposition of STR#2961 to a github issue.
The overall message from that STR is that the call to XOpenIM() performed each time a window gets closed renders FLTK very slow under NetBSD with Unicode locale. The effect is particularly noticeable when using a menubar where each time the mouse changes toplevel menu a window is closed.

To Reproduce
Run test/editor under NetBSD with Unicode locale.
Open a menu and move the mouse left or right to change menu.

Expected behavior
Menu changes should be swift but they are very slow.

FLTK Version

  • Version: 1.3.x or 1.4 : same cause, same effect

Operating System / Platform:

  • OS: NetBSD
  • With Debian, no slowdown but the frequent calls to XOpenIM() do occur

Linux/Unix Runtime, if applicable:

  • X11
@ManoloFLTK ManoloFLTK added the Platform: X11 platform specific (Unix/X11)) label Mar 17, 2024
@ManoloFLTK ManoloFLTK self-assigned this Mar 17, 2024
@ManoloFLTK
Copy link
Contributor Author

ManoloFLTK commented Mar 17, 2024

@michaelbaeuerle To Michael Bäuerle: please apply the attached patch to the current version of FLTK 1.4 and report here whether the slowdown disappears under NetBSD and a Unicode locale. I would really expect it does.
If so, I will commit that change. I could also apply it to branch 1.3 if you need to keep using 1.3.

issue935.patch

@ManoloFLTK ManoloFLTK added the waiting for confirmation waiting for someone's confirmation label Mar 17, 2024
@michaelbaeuerle
Copy link

Yes, with this patch there is no delay anymore.
Thank you for looking at this problem!

@ManoloFLTK ManoloFLTK removed the waiting for confirmation waiting for someone's confirmation label Mar 18, 2024
@ManoloFLTK ManoloFLTK added the fixed The issue or PR was fixed. label Mar 18, 2024
@Albrecht-S
Copy link
Member

👍 @ManoloFLTK Awesome, thank you very much for fixing this long-standing issue!

Manolo wrote:

I could also apply it to branch 1.3 if you need to keep using 1.3.

@michaelbaeuerle What about your further usage of 1.3?

@ManoloFLTK Would you like to add this to 1.3 as well? I'm planning to release 1.3.10 soon (either before 1.4.0 or shortly after 1.4.0).

@ManoloFLTK
Copy link
Contributor Author

@Albrecht-S I've also committed to branch 1.3 (807d205) the fix for this issue.

@Albrecht-S
Copy link
Member

@ManoloFLTK Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fixed The issue or PR was fixed. Platform: X11 platform specific (Unix/X11))
Projects
None yet
Development

No branches or pull requests

3 participants