Problem with cursor lag

[photoken]

This can almost be considered a bug....

Win7 x64 SP1
PL 18.xxx 64-bit

I'm using these settings for the cursor:

cursor settings.png

When drawing, the application of the paint (or effect) lags behind the position of the cursor (as denoted by the crosshairs). This becomes very obvious when using a small brush size:

cursor lag.png

This lag is so obnoxious that it makes painting, etc., very difficult when using small brush sizes -- it's very difficult to anticipate where the paint (or effect) will be applied when the cursor is moving.

[Martin Huber]

TWin7 x64 SP1
PL 18.xxx 64-bit

The real PhotoLine version is quite important.

I'm using these settings for the cursor:

cursor settings.png

When drawing, the application of the paint (or effect) lags behind the position of the cursor (as denoted by the crosshairs).

These settings affect the painting speed only marginally.
The painting speed is mainly controlled by the "Steps" value of the brush.
If you are using a Beta version, other settings may produce an effect similar to lagging, too. But Beta topics should be discussed in the Beta forum.

Martin

[photoken]

The real PhotoLine version is quite important.

I did that intentionally because the lagging effect is the same for both the release version (18.02) and the beta (18.40b10).

The steps value of the brush is the default 10%, and changing it to 1% had no effect on the lagging.

[Martin Huber]

The steps value of the brush is the default 10%, and changing it to 1% had no effect on the lagging.

10% is a good value, 1% is most of the time slower.

I can't reproduce the lagging here. Do you have the problem with any tool or just certain ones? Does the problem appear with any document/image or just with some (certain layer stack or image kind or bit depth)?

Martin

[photoken]

Do you have the problem with any tool or just certain ones? Does the problem appear with any document/image or just with some (certain layer stack or image kind or bit depth)?

The problem is with all tools -- Paintbrush, Eraser, Remove Brush, Darken. The problem happens with any image: with or without layers, even on a simple JPG of moderate size (800px x 533px).

The brush settings, for example with the Darken brush, look like this:

brush settings.png

It makes no difference if the inner radius is less than the outer radius (for a soft edge).

The zoom value makes no difference: Full View, 100%, 200%, etc.

[photoken]

More experimenting revealed that the problem is definitely specific to the application:
No problem with MS Paint, or (surprisingly) Corel PaintShopPro. The lagging does occur with Corel PhotoPaint (and is much worse than with PL).

[Herbert123]

More experimenting revealed that the problem is definitely specific to the application:
No problem with MS Paint, or (surprisingly) Corel PaintShopPro. The lagging does occur with Corel PhotoPaint (and is much worse than with PL).

I work with a Wacom tablet myself, and I tested for this laggy behaviour in a couple of applications.

ALL the major digital painting applications exhibit the same type of lagging depending on the situation:
- Photoshop (cs6) - identical to PL, even with very small sized brushes
- Corel Painter X3 - identical to PL, even with very small sized brushes
- Krita is fine with smaller brushes, but with larger or more complicated ones the same lagging occurs
- Clip Studio is the only one that insist on keeping up exactly with the mouse cursor, but the overall painting experience may become laggy as a whole with large sized brushes - slow screen updates
- MyPaint - identical to PL, even with very small sized brushes

MS Paint also starts lagging behind once the speed picks up, by the way.

It's just something you will have to get accustomed to. I have learned not to draw with the cursor, but pay attention to the drawn line itself. If you wish exact tracking behaviour, switch to either Krita or Clip Studio for this type of drawing - but those will also start lagging with more complex and / or thicker brushes.

[photoken]

I work with a Wacom tablet myself, and I tested for this laggy behaviour in a couple of applications.

Sorry, I should have mentioned this: I'm not using a graphics tablet for this -- I'm controlling the cursor with the touchpad on my notebook PC.

In the case of PL, it's maddening that the cursor (crosshairs) is moving about 5px before the brush itself moves.

(BTW, I don't notice any lag in MS Paint, no matter how fast I move the cursor.)

Added:
As a test, I installed the latest Paint.Net 4.0 beta, and there is no cursor lag (but the crosshairs disappear when painting...).

Further testing with PaintShopPro reveals that the cursor moves maybe one or two pixels before the brush itself moves, which for all practical purposes is no lag.

[photoken]

Using Win7 SP1 x64.
PL 18.02 64-bit.

I'm escalating this problem to bug status because the lag causes the program's functionality to fail:

The bad news is that not only does the brush lag behind the cursor; but when the left mouse button is released, the brush jumps forward to the position of the cursor. This causes the paint (or other effect) to draw past the last position of the brush into areas where it's not wanted.

Here's an example (at 200%):

paintbrush cursor down.png

The screenshot shows the positioning of the cursor and brush with the left mouse button down. The paint line was drawn down to where the brush was exactly touching the horizontal rope.

Now the left mouse button is released:

paintbrush cursor released.png

The brush jumps to center itself at the last position of the cursor, and obliterates the rope. Not good.

[Herbert123]

That does not happen with a mouse or the Wacom. I cannot reproduce that behaviour on my side. Perhaps others can chime in as well, and test for this?

Btw, all those applications respond the same when I draw with the mouse.

[photoken]

I cannot reproduce that behaviour on my side.

I'm using a circular brush with a size of 10px.

Further testing showed the lagging and the brush "jumping" to the cursor position is worst at 100% and less. Progressively higher magnifications reduce the effect, which explains why I never noticed it before -- when I'm editing a mask, for example, I usually work at 400% or greater with a brush size of about 5px.

[Martin Huber]

Now I know what's happening. There are two reasons for what you are seeing:

- Because of a discussion in the past (http://www.pl32.com/forum3/viewtopic.ph ... ggy#p28539 jaggy drawing with low zoom) PhotoLine now interpolates mouse positions. The lag should be at most 5 screen pixels (not image pixels). This "lagging" can be seen best when drawing slowly.
- In order to allow better interpolation between mouse positions PhotoLine only draws up to the second last mouse position. Therefore painting is always behind the mouse position. This can be seen best when drawing fast.

Now the left mouse button is released:

paintbrush cursor released.png

The brush jumps to center itself at the last position of the cursor, and obliterates the rope. Not good.

Both methods close up to the mouse position after releasing the mouse button. I will change that.

Martin

[photoken]

Now I know what's happening. There are two reasons for what you are seeing:

- Because of a discussion in the past (http://www.pl32.com/forum3/viewtopic.ph ... ggy#p28539 jaggy drawing with low zoom) PhotoLine now interpolates mouse positions. The lag should be at most 5 screen pixels (not image pixels). This "lagging" can be seen best when drawing slowly.

Yes, now I remember that discussion. 5 screen pixels is about right from what I noticed in my tests.

- In order to allow better interpolation between mouse positions PhotoLine only draws up to the second last mouse position. Therefore painting is always behind the mouse position. This can be seen best when drawing fast.

Whew! I thought I was going nuts when I was testing this and getting inconsistent results, depending on the drawing speed.

Now the left mouse button is released:

paintbrush cursor released.png

The brush jumps to center itself at the last position of the cursor, and obliterates the rope. Not good.

Both methods close up to the mouse position after releasing the mouse button. I will change that.

Thank you. So are you saying that also the lag will be eliminated when drawing? In other words, when PL changed its drawing method to interpolate the mouse position in order to smooth jaggies when drawing at low magnifications, that created a worse problem -- the lagging behind when drawing.

[bkh]

Now I know what's happening. There are two reasons for what you are seeing:

- Because of a discussion in the past (http://www.pl32.com/forum3/viewtopic.ph ... ggy#p28539 jaggy drawing with low zoom) PhotoLine now interpolates mouse positions. The lag should be at most 5 screen pixels (not image pixels). This "lagging" can be seen best when drawing slowly.

- In order to allow better interpolation between mouse positions PhotoLine only draws up to the second last mouse position. Therefore painting is always behind the mouse position. This can be seen best when drawing fast.

Just two thoughts:

– Wouldn't it be better to draw the brush outline at the current mouse position? In this way, the brush outline would follow the (jaggy) mouse movements, not the interpolated ones.

– Does it make sense to add a timeout so that if there is no movement, then the line will be fully drawn, and interpolation re-starts afterwards (just like releasing the mouse button and pressing it again). Btw., I think that such a timeout may also be useful when using big brushes and the resulting large step sizes – in order to precisely position the brush, one has to release the mouse button and press it again if one is within one step from the previous brush position.

Cheers

Burkhard.

[photoken]

– Wouldn't it be better to draw the brush outline at the current mouse position?

Yep. Essentially, that's what I'm asking for.

If drawing with zero lag and smoothing drawn lines at small magnifications using interpolation are mutually exclusive, then there probably should be an item in the program settings to enable or disable the interpolation.