Page MenuHome

GPencil: Drawing long strokes turn invisible
Closed, ResolvedPublic

Description

System Information
Operating system: Linux-4.15.0-45-generic-x86_64-with-debian-buster-sid 64 Bits
Graphics card: GeForce RTX 2080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 418.43

Blender Version
Broken: version: 2.80 (sub 74), branch: blender2.7, commit date: 2019-06-09 21:43, hash: rB030c7df19da9

Short description of error
When drawing a very long stroke, at some point the drawing seems to clear (but you still keep drawing) until you release the mouse button.

Exact steps for others to reproduce the error

  1. Load the "2D animation" preset
  2. Draw a zig-zag line for around 10 seconds (be sure to move the mouse around while doing so, so you see the whole stroke).
  3. At some point, the stroke will disappear, but you'll still be drawing.
  4. You can continue doing this and the stroke will continue disappearing every once in a while.
  5. Once you release the button, the entire stroke will re-appear.

Event Timeline

I cannot reproduce on Windows 10 64 bits RTX2080 TI

Antonio Vazquez (antoniov) triaged this task as Waiting for Developer to Reproduce priority.Jun 11 2019, 11:21 AM

Just tried on the same computer with Windows 7 64 bits, it does not happen there.

I also tried it on another Linux desktop, where the bug also happens (so it might be a Linux-only bug?):

System Information
Operating system: Linux-5.0.0-15-generic-x86_64-with-debian-buster-sid 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.14


Further testing reveals:

  • It happens exactly when the "Points" count of the currently drawn stroke reaches 9,999.
  • It does not matter what strokes/points the Grease Pencil object had before drawing.
  • When the started stroke disappears, it starts a new stroke (the two strokes are disconnected from one another after drawing finished).

Here is a video of the bug, with default user preferences:

Sybren A. Stüvel (sybren) lowered the priority of this task from Waiting for Developer to Reproduce to Confirmed, Medium.

Confirmed with Blender 805cabdf177af6c71da6239ff3fc5d2524286a18 on Kubuntu Linux 18.04.

Apparently this is caused by a limit on the amount of data buffered by Blender. The limit is set by the #define GP_STROKE_BUFFER_MAX 5000 line in gpencil_intern.h; decreasing this number causes strokes disappearing after less points.

Do we consider this as a bug? Or is it simply a known limitation? Are these very long strokes actually used in practice?

@Sybren A. Stüvel (sybren) We can consider a "logic" limitation. I don't think is good idea draw a stroke with more than 5000 points.... maybe in some corner case is used, but you need a very long stroke to get the limit. We could just increase the number, but this will use more memory. I don't think it worth to add system parameter for that.

Linux has high-frequency mouse events and will hit that limit much quicker than Windows.

I'm not sure why a limit is needed here at all, can't the points array be dynamically resized as needed? Theoretically the user could draw a very long strong and run out of memory, but that's no different than creating many vertices for example.

There are reason to not doing in a dynamic allocation...response. We tested in other areas (not this one), but to get very fast response to mouse/pen movements you cannot allocate memory dynamically. We are talking of miliseconds.

This array is only used while drawing, the memory is only used while the mouse/pen is moving, so we could increase it...but in real life, almost nobody is drawing anything keeping his pencil over the paper without lifting the pencil for 2 minutes...the drawing is a process of "gesture" drawing..., you make short and very fast movements, so the main point is "feeling", and we cannot allocate memory while the stroke is increasing or we will miss this "feeling".

We have been testing a lot during past months about this "feeling" and its very easy to do something wrong that "breaks" this feeling, so we need to be very carefull with that.

As a solution, we could increase it to 10.000 with almost no impact in memory.

Also, there are differences between creating a mesh and strokes...mesh is created in a very slow process (from the point of view of CPU), because the user moves the mouse, extrude, etc..but this actions take 1 second or more...but draw a stroke maybe take 0.25 seconds or less, so the number of points grow and grow very fast.

What about using a dynamic allocation scheme, but preallocating the same amount of memory as is done now? That should keep things fast up to the same limit, but instead of having the strokes disappear Blender just becomes a bit slower.

You mean, preallocate in chunks?

I can change this to use preallocated size and increase the size if need more in chunks, but I don't think is a good idea to do now with the 2.80 RC here.

I can add this to T63757 and handle after 2.80 release. What do you think?

Indeed, with a big chunk to begin with. Something along the lines of std::vector<...> v; v.reserve(10000).

I don't think it's high priority to have this fixed for 2.80, so can be done after.

Antonio Vazquez (antoniov) renamed this task from Grease Pencil: Drawing long strokes turn invisible to GPencil: Drawing long strokes turn invisible.Jul 23 2019, 11:02 PM