Hi @oxysoft! is it 6~8 millisecond delay? That looks even better than one frame drop at 60 FPS.

I suppose that if the program is unusable the delay must be bigger than that. Do you have a high-DPI mouse or a pen? What screen resolution are you using? Would you like to try other Screen Scaling factor in Edit > Preferences > General > Screen Scaling option? Or reducing the window size?

No, I'd estimate that it is indeed around 6 to 12 milliseconds. Most people will find that okay but to me, that is egregious for 2016 software. My mouse is your standard cheap desktop mice. I've tried other screen scaling factors and it's all the same. Reducing the window size seems to have maybe improved it by 2-3 milliseconds but it's probably just placebo taking effect, it's hard to tell. Of all the configurations I've tried, none of them made the cursor as smooth as the native cursor.

edit: I might add also that there seems to be pretty severe cursor tearing, it just goes invisible when I move it really fast

edit: I might add also that there seems to be pretty severe cursor tearing, it just goes invisible when I move it really fast

Yes, UI drawing message events (i.e. drawing the mouse cursor) are not processed immediately so we can give more priority to mouse input events (in case that there are mouse events in the events queue).

In any case, I see some problems with this issue:

1. we could use native cursors for everything, but one of the most important aspect of Aseprite (the crosshair cursor/brush preview) would be lost
2. if we add an option to disable the crosshair, it would be the same for the drawing process, the screen must be updated to show the painted area
3. we have plans to change the painting processing into a background task, so mouse input can be as fast as you want while a background task consume those input

Anyway, I don't find this issue a high-priority (someone rarely will need to move the mouse faster than 60fps to paint pixel-art), but I'll try to add some options to completely disable the crosshair or try to find a fix to this in other ways.

Meanwhile, could you please record a video with the delay, and drawing in the sprite editor (e.g. moving the mouse at different velocities)? I suspect that the delay should be higher than you might think. Also what CPU are you using?

How about using hardware custom cursors?

@theFroh hi there! yes, that is the first point in my previous comment, the problem is that the crosshair cursor/brush preview cannot be solved with custom hardware/native cursors 😢

My long term plan is to use shaders for the crosshair cursor, there are some steps/tasks:

1. Use custom hardware/native cursors instead of a software overlay
2. Add an option to disable the crosshair cursor and use a native cursor alternative
3. Use shaders to replicate the current crosshair cursor
4. Use a background renderer to update the brush preview and send a signal to the Editor when it's ready to paint in the screen

I've recorded with OBS but it doesn't capture the mouse phasing in and out of view unfortunately. In the recording it appears fine.

My CPU is an intel core i7 860 2.80GHz. It's old (2007-2009) but it was a powerful CPU back at the time.

I think you should let us get rid of the crosshair and any kind of cursor rendered by the application and use all native instead. See Graphics Gale for example. When drawing, it changes the native cursor for a small pencil cursor and it renders under the cursor the changes that would occur were you to click. I personally really don't care for a crosshair, I just want a graphics gale equivalent.

Also note that when moving the canvas around with middle mouse button, it lags intensely. I'm not sure if that's related but that's also unacceptable.

edit: now I don't understand. What do you mean by "crosshair cursor/brush preview cannot be solved with custom hardware/native cursors"? It absolutely can. Just use the native cursor for the lil crosshair or a pencil and the preview below is rendered by the software

Also note that when moving the canvas around with middle mouse button, it lags intensely. I'm not sure if that's related but that's also unacceptable.

Your CPU looks quite good, so it's strange what you are experiencing. I'm suspecting of other thing... maybe some other program is generating more mouse events than necessary or is interfering with the regular behavior of Aseprite, e.g. there are drivers that generate constant mouse events on Windows (years ago I got some bug reports where Aseprite behaves slow but after restarting the machine it just run smoothly). Check the CPU usage of other processes (just in case) in the Window Task Manager while you use Aseprite.

What do you mean by "crosshair cursor/brush preview cannot be solved with custom hardware/native cursors"?

Take a look:

The crosshair could be replaced with a simple custom native cursor (anyway we'd lose the black/white negative with it), but the brush preview is impossible to be replaced (as it uses the same Editor render engine/active tool/ink configuration to show the preview).

I had someone else try it yesterday and he said he also felt some delay. I tried it a few secs ago on my brother's computer but I noticed some differences

• The mouse delay still felt present, but a lot less than on my computer, I'd estimate around 2 to 4 milliseconds. His CPU is weaker but his GPU is a bit stronger than mine (GTX 580 vs 660 or 680, can't exactly remember)
• middle mouse button dragged the canvas around a lot more smoothly than on my computer. On mine it's just a choppy mess
• The cursor did not phase in and out as I moved the cursor around really quickly. I think it did actually but it was a lot less noticeable, like A LOT less. On mine, I can move it not even that fast and I'll notice the problem.

The crosshair could be replaced with a simple custom native cursor (anyway we'd lose the black/white negative with it), but the brush preview is impossible to be replaced (as it uses the same Editor render engine/active tool/ink configuration to show the preview).

So replace it with the native cursor but add a check to not render the crosshair, just the brush preview if you have native cursor enabled? This way, you have the OS' native cursor rendering on top and the preview rendering below.

Also if it can be of any use, when I open a window like the preference window, and I move it around, there are some problems with the edges of the window. You know how there are 1px black lines surrounding it? If I move the window to the right for example, the 1px border on the right will kinda flash in and out as I move faster or slowing, the same happens on all side if I move it in circle or kinda just jiggle it. On the other hand, the side opposite to the direction I move the window towards has a bigger outline. I also had some trouble capturing that with OBS which is weird.

This way, you have the OS' native cursor rendering on top and the preview rendering below.

Yes (my second point here), anyway the brush preview will still have the same delay.

Also if it can be of any use, when I open a window like the preference window, and I move it around, there are some problems...

Yeah, I'd expect all kind of problems moving the mouse in this scenario.

Just to check, you might try to disable the brush preview (uncheck View > Show > Brush Preview option). It might improve a little bit the performance, but not an huge difference.

Yes (my second point here), anyway the brush preview will still have the same delay.

Oh no, I meant once we sort it out and the delay is fixed. No, actually it could be a good way to demonstrate the problem. If I can get a build with the cursor on top, the native cursor would be smooth and the fake cursor below wouldn't, which could be a good way to record it and show it to you in motion.

Just to check, you might try to disable the brush preview (uncheck View > Show > Brush Preview option). It might improve a little bit the performance, but not an huge difference.

I wasn't actually testing the mouse delay on a canvas, I was on the home tab with the main cursor so it's irrelevant. The delay is there even on the home tab when there is no preview!!

I wasn't actually testing the mouse delay on a canvas, I was on the home tab with the main cursor so it's irrelevant. The delay is there even on the home tab when there is no preview!!

I got it, just saying if you wanna to give it a try.

I'll try to experiment with some changes next week with this issue.

To be honest, a native hardware cursor (sorry, in your original reply I didn't make the native -> hardware rendered custom link!) for the crosshair/tool/pointer, and the preview underneath rendered in software shouldn't be too bad. Best of both worlds, downside being a probably noticeable discrepancy between the pointer and preview latency. Best of luck experimenting!

Some news about this issue:

1. Now we use native custom cursors on Windows and OS X
2. We have new options for cursors: