Line tool not starting and stopping where it is supposed to

[kgschlosser]

 

 

 

In in the image below you can see the grab points. The grab point at the bottom is where I started the line and the grab point at the top is where I stopped the line. If you notice the grab points are not on positioned on the line properly.

 

 

[Pixey]

This could be because you are zoomed in so much.  I can't reproduce this.  Which version of paint.net are you using?

[Rick Brewster]

Why'd you blur the titlebar? 🤔 Can't tell what version you're using. First, make sure you're on the latest, which is currently v4.3.12.

[null54]

10 hours ago, Rick Brewster said:

Why'd you blur the titlebar?

 

Probably to hide the image/document name.

[kgschlosser]

That is correct @null54

 

I am running the latest version of Paint.NET

 

It does this whether or not I am zoomed in. It could have something to do with the project I am working on.

8000 x 16920 with 70 layers.

 

I will add that it takes Paint.NET a long time to do something as simple as just changing to a different layer. Sometimes it's fast, other times the program state changes to not responding for 30 seconds to a minute before it changes the layer. I haven't nailed down why it's fast sometimes and slow others. It has nothing to do with how much is drawn on a layer.

 

Machine specs

AMD Threadripper PRO 3955WX 16 Cores (32 thread) @ 4.3gHz

256GB RAM

512GB PCI-E 4.0 NVMe SSD

NVIDIA Quadro RTX 4000

 

No page faults happening at all that would cause the slowdown. and not sure why the problem above is happening.

 

I am going to check and see if it only happens with this one project I am working on. It may have something to do with memory corruption because of the large number of layers and the size of the image.

 

 

[NinthDesertDude]

Maybe it's because aliased pixel mode will round to the pixel grid, but all the points in the screenshot are evenly spaced so it's unlikely you messed with that. When I tested this, it actually prefers rounding up, not down. So if the drag point is above middle, it fills the pixel above. That's opposite to what's shown. This is odd behavior. I tested the 4 permutations of drawing near the top/bottom of the starting pixel to the top/bottom of the ending pixel and they all draw the same as you'd normally expect, so I can't repro the bug easily.

[Rick Brewster]

The performance in this case is because you're working on a large image with a ton of layers. Simple as that. An image that large uses almost 38GB of memory for the image, and when you make changes all 70 layers have to be re-rendered (albeit clipped to the changed region). You certainly have enough RAM to avoid paging, so that's unlikely the problem, but there's still linear performance with respect to layer count, although different blend modes require more or less CPU time for rendering (Normal is the fastest, of course). You'll likely see paintdotnet.exe in Task Manager consuming a lot of CPU -- although with 32 logical cores it may only say 3% (which is 100% of 1 core).

 

If you really want to dig in, you can take a performance trace and analyze it with Windows Performance Analyzer to see where in the app's code (or elsewhere) the CPU time is being spent. I can also look at the trace, although it'll probably be very large (I've found it's best to keep it to 30 seconds or less with that many CPUs). I have done a lot of work to improve performance for very large (width X height) and very deep (# of layers) images, but images of that size are still beyond what I've managed to pull down to Earth so far.