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

Cursor ghosting/flickering #418

Open
Willgheminass opened this issue Jan 4, 2021 · 11 comments
Open

Cursor ghosting/flickering #418

Willgheminass opened this issue Jan 4, 2021 · 11 comments
Labels
bug Something isn't working

Comments

@Willgheminass
Copy link

Pixelorama version:
v0.8.2-stable

OS/device including version:
Windows 10 w/ GTX 1650 Super EVGA

Issue description:
Whenever I move my cursor around inside of the pixelorama window, there's a ghost of the crosshair cursor and a normal cursor beside it and a ghost cursor shows up beside the original crosshair. I'm running this on a 144Hz display but when I change the refresh rate of my monitor to 60Hz and run the program, the issue goes away. The flickering/ghosting also arises when I run the program at 120Hz

Steps to reproduce:
Run program with the monitor running at 144 Hz or in 120 Hz. (Probably anything higher than 60 Hz)

@Willgheminass Willgheminass added the bug Something isn't working label Jan 4, 2021
@OverloadedOrama
Copy link
Member

Unfortunately I don't have a 120 or 144Hz monitor to test it, but in 8daacba I added an option that lets the user set a limit for the application's FPS. If you set it to 60 from there, will that fix the problem? It would be great if you could test it, you can find an early access build in the Actions tab or in the Early Access Web version.

@Willgheminass
Copy link
Author

Willgheminass commented Jan 6, 2021

I got some interesting results. The problem went away when I used pixelorama to work on a piece without changing the settings you mentioned, but when I changed the "Set application FPS limit:" to 60, the ghosting appeared. I also had performance issues while running the program with no FPS limit and also when I originally had this issue happen. It only happens after using it for a while and then I would have to restart my PC in order to have it run normally again. I have no trouble running demanding games that require the specs that I have at high framerates. Pixelorama usually takes ~20% usage of my GPU when I was painting a 160 x 90 image.

@CornThatLefty
Copy link

Hi,

I'm using a 144Hz monitor, and am also experiencing this issue.
Limiting FPS in the performance tab doesn't seem to resolve the issue, and my guess is that, for some reason, the application is not capturing the cursor from Windows at the correct frame rate, and so the cursor is not being modified in every frame.

Here is a gif demonstrating what is happening:
https://i.gyazo.com/111b2a2b5031596ca86b3b9320beb8c4.mp4

It's difficult to capture due to the nature of the bug, but if you scrub the gif at 5 seconds while the cursor is on the right of the screen, you can see one frame in which the correct cursor is missing, and the windows cursor has appeared. (Please take into account the gif was captured at a much lower frame rate. In reality I am seeing the Windows mouse cursor just about every other frame. It's incredibly annoying.)

Not a developer, but if there were a way to decouple the cursor modification from the frame rate, it would likely solve the issue.

@farfalk
Copy link

farfalk commented Mar 29, 2021

I'm having this issue as well. VERY annoying flickering between the default windows cursor and the cursor shape intended for canvas (cross) or for buttons (pointing hand)
It doesn't happen every time, though:

  1. Probability of happening increases if I use a dual monitor setup (may not help that I have a monitor at 120Hz and the other at 60Hz)
  2. Probability increases also if I use a wacom tablet and hover with the pen on the pixel canvas for a while (windows ink enabled, cursor hid)
  3. Also increases with time.

When it starts happening, the only way to solve it is to restart - sometimes the application, sometimes the PC itself.

Windows 10, latest 20H2 update, both 0.8.2-stable and latest 0.8.3-dev (FPS control doesn't change anything)

@quinnyo
Copy link

quinnyo commented Feb 13, 2022

Hello! I believe this is the same as Godot #48309

@OverloadedOrama
Copy link
Member

I suppose we need to wait for the issue to get fixed in Godot. In the meantime, I have added an option in the Preferences under the Cursor tab that lets you disable the crosshair cursor for the canvas. This should work fine as a workaround, but since it's not a proper fix, I will keep this issue open.

@Bug-Ninja
Copy link

Exact the same thing is happening here, on Linux mint 20.3 (Derivative of Ubuntu 20.04). I have version 0.92.
The refresh rate of my monitor is 60hz, resolution 1920x1080.

Besides from the flickering I noticed that it is taking a bit long for the cursor/cross hair to to follow the cross hair / mouse pointer. So let's say I move my mouse to the left: I see the blue shape of the brush moving immediately, but the cursor (flickering between cross hair and default arrow) follows roughly half a second later.
It did not help to lower the fps in the settings. I tried to record this phenomenon, nut the default arrow simply doesn show up in the recording.

My laptop is heating up quite a bit when Pixelorama is started. It really frustrates me: my son has a much slower pc system and he has no problem whatsoever. He has the same linux mint version. Hopefully it's the bug in godot and it will be solved soon...

@Cuperino
Copy link

Possible duplicate: #725

I'm facing a similar issue when using the latest Flatpak on a Linux system running KDE Plasma. The issue is not present on the same system when using the Snap package version.

@samedii
Copy link

samedii commented Nov 18, 2023

Seeing this on master 417102d
Using Linux 64bit from github actions build.

Still happens when I limit the fps to 1.

@outp1
Copy link

outp1 commented Apr 25, 2024

Same. Arch Linux with an i3 wm.

@Cuperino
Copy link

@outp1 Try using Sway instead of i3. It's practically the same WM, but uses the Wayland protocol instead of X11.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

9 participants