This must be solved with the yesterday commit 76747d0a1158

I agree that the many types of brushes is confusing, I think we should ideally get down to three types of brushes :

• Raster brushes : texture paint, image paint, weight paint (not sure for this one)
• Vector brushes : grease pencil
• Sculpt brushes : sculpt mode, but also gp sculpt

So this is a known limitation that would be good to solve, but not considered a bug at this moment.

A slower solution could also be part of the smoothing option, available as a post-processing setting.

@Antonio Vazquez (antoniov) perhaps we could add a rendered mode for GP too? That way we can keep the fast drawing that we have now but also have a much more costly mode with higher quality results.

Yes, this is a limitation of the current drawing method. We are looking for a solution, but it's not easy to fix without adding a lot of drawing overhead.

I just checked on another computer. At least it is not a problem of AMD graphic cards.
LinuxMint / Nvidia looks similar:

I think that this is a limitation because GP actually draws its geometry in 3D space.
Perhaps we could do some smart tricks to remedy this.

@Antonio Vazquez (antoniov) hm why is moving a layer assigned to click in the first place? Why does it even work in a locked layer?
Mixed feelings about letting poll return true, since it is not the real fix I think.

@Dalai Felinto (dfelinto) Yes, I think this is the issue... the eraser poll return false because no active strokes, so the next operator is executed.

Isn't it for the same reason trying to fill a locked layer activates the Move operator?
I guess the operator poll is returning false, and the next operator in line is the move?

Really Ctrl+F must be removed. This is a code from old grease pencil. I'm going to remove this keymap.

The keybinding is indeed bound to change the eraser radius. However if you change it in draw mode, it will not update the eraser radius and then it will not change the actual radius of the eraser when you are in eraser mode either.

Note that this is only an issue with left click select.

69b2f5268114-windows32 has brush damaged... maybe it's the template.

Okay, new update, I had been running with --debug (I'm having the same problems as reported in T60089 and with debug is the only way to run Blender)
For some spontaneous reason, Blender* launched (without the debug command)
Here's what I found:
Launching Blender's 32-Bit & 64-Bit build (-69b2f5268114-) both with --debug --factory-startup show different results:

Updated task!

I think we can close this report because the crash is fixed. If we need work on modal operators, we can reopen it or create a new task.

The eraser brush is damaged and the same for the default draw brush.

@Jacques Lucke (JacquesLucke) I got to open it once...now get the assert. The problem is related to brushes. They have forgotten the gp_settings... I'm investigating.

I get an assert when I open this file. Bisecting...

If you can open the file with the fix, the corruption is fixed (the read process review the error and fix it automatically). THe reason of the corruption is more related to modal operators.

I can confirm that the current version (69f50e6ea98) no longer crashes. I have produced a file in that newer version using the process described in my previous comment. It also results in a crash when opened in a version before the fix, so I assume that file is equally corrupted.

Nice, thanks for the swift fix! I will test this as soon as I can get a build that includes the fix.
The corrupt file was produced by saving while Blender was in the state of waiting for the confirmation or cancellation of the drawing of the ellipse. I mistook this state for a hang, because I had never worked with the tool before and chose it by mistake.
So in order to reproduce, first you need to save a new file (the 2D animation preset works fine). Try to choose the ellipse tool, draw an ellipse, possibly change it a few times, then try to choose the pencil tool again (nothing happens) and then directly try to close the Blender window. The popup offering to save the file should appear and you need to confirm. It doesn't work if you have not saved the file before because the file chooser will be unresponsive in that state.\
What in my opinion should happen is that the drawing of the ellipse should be automatically confirmed when you try switching tools. That's what most other drawing programs do that allow you to draw temporarily adjustable shapes. As a user I don't like to be locked into some state and I can always undo changes I don't like.

I have done a change, and now the open file crash has gone (b85d5dd9b1a0).

I can see the crash opening your file, but it looks the file gets corrupted for any reason.

Can confirm, working in viewport, not in render. thanks!

This is a known issue that should definitely be fixed. When there’s not enough space in the top bar, all the content just disappears. We could start by making it work like the headers, where things just start to scroll.

There is an underlying UI issue. We can move options to a popover but I tested it and the options don’t display in the side panel.

This is a problem with the size of topbar, not only a grease pencil problem.

In T61071#611415, @José Ricarte (ciriaco) wrote:

Hi, I'm not a programmer, but here's an idea.:

http://paperjs.org/examples/path-intersections/

http://paperjs.org/examples/boolean-operations/

Thanks for your great work, GP every day is better

I have been looking at the code and the missing feature is in gp_stroke_delete_tagged_points() function and not only affect the cutter, but any delete operation when the stroke is cyclic.

Hi, I'm not a programmer, but here's an idea.:

Hmmmm. I can see this is a tricky problem as strokes have a start and end point. Only thing I can think of is that the cutter tool treats cyclic strokes differently and joins the start end points by reordering the stroke.

This is not a bug, it's a limitation of the box primitive (same for circle).