Bug 427335

Summary:	Render brush cursor separately from the canvas pixels ?
Product:	[Applications] krita	Reporter:	stephen <tgdev001>
Component:	General	Assignee:	Krita Bugs <krita-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	wishlist	CC:	halla
Priority:	NOR
Version First Reported In:	4.4.0-beta2
Target Milestone:	---
Platform:	unspecified
OS:	Microsoft Windows
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description stephen 2020-10-04 19:12:51 UTC

SUMMARY
Greetings guys.
Can you please separate the brush cursor's render process
from that of the Canvas' ? There's a weird and slight stutter/delay just after the end of each stroke while painting. The issue is even more obvious with Instant Preview mode active.

STEPS TO REPRODUCE
1. with a pixel engine brush selected, paint multiple strokes like if
you wanted to do hatching lines. Instant preview is inactive.
2. repeat step 1 by painting as fast as you can and see if the brush cursor doesn't jump to catch up(might be frame drop at the end of each stroke, I don't know)
3. repeat step 1 with but this time with Instant Preview active.

OBSERVED RESULTS
At the end of each Stroke, the brush cursor stops moving or freezes for a brief amount of time then jumps to its correct position. With instant preview inactive, the impact is dampened. But with Instant preview active, it's just obvious.

Tested on a Krita plus stable build : version 4.4.1 alpha(git b20cb06).

OS : Windows 10 1909

Comment 1 Halla Rempt 2020-10-05 07:45:23 UTC

Sorry, but, no, that cannot be done.

Comment 2 stephen 2020-10-05 16:33:04 UTC

(In reply to Boudewijn Rempt from comment #1)
> Sorry, but, no, that cannot be done.

If that can not be done, then how did you manage to implement
the brush Cursor Shape which moves effectively in real time according to user input ?
It never lags, it's always responsive, and we need those pros for the Outline Shape as well. But, do you, at least, understand the issue ? It's what matter the most; if you do, then it's good and we can expect for change sooner or later.

Comment 3 Halla Rempt 2020-10-05 16:41:21 UTC

Of course I understand the issue. I first ran into this in 2004. Cursors are drawn by the display manager of the window system. That system cannot be used to draw the brush outline.

Btw, do not change the status of bugs: only developers should do that.

Comment 4 stephen 2020-10-06 00:02:39 UTC

(In reply to Boudewijn Rempt from comment #3)
> Of course I understand the issue. I first ran into this in 2004. Cursors are
> drawn by the display manager of the window system. That system cannot be
> used to draw the brush outline.
> 
> Btw, do not change the status of bugs: only developers should do that.

OK...
But there's got to be a way.
Maybe this would help you in the future. 
https://docs.microsoft.com/en-us/windows/win32/learnwin32/setting-the-cursor-image

Comment 5 stephen 2020-10-14 03:08:40 UTC

(In reply to stephen from comment #4)
> (In reply to Boudewijn Rempt from comment #3)
> > Of course I understand the issue. I first ran into this in 2004. Cursors are
> > drawn by the display manager of the window system. That system cannot be
> > used to draw the brush outline.
> > 
> > Btw, do not change the status of bugs: only developers should do that.
> 
> OK...
> But there's got to be a way.
> Maybe this would help you in the future. 
> https://docs.microsoft.com/en-us/windows/win32/learnwin32/setting-the-cursor-
> image

Alright. It turns out, things are much smoother with OpenGL renderer active rather than DX11 ANGLE. And so, brush cursor spped might not be an issue anymore.
However the Black/White color change option is still awaited, guys.