The no hacks solution is what was rolled back; the prevalence of devices with issues is unclear.

Circle select doesn't support resizing either. Also, I think we should have a system for custom pressure curves (like Krita does).

@Antonio Vazquez (antoniov) Thanks for sharing your time for this :)

If the no hacks solution for wintab implies further issues with a minority of devices and drivers, I would go with that. Better having the most commonly used devices working as expected that all the devices half working. Also, with a list of supported devices/drivers at least we can point people at hardware setups that we know they properly work and are supported.
This will also allow us to include other pen based features (like tilt support) in a more predictable way across all platforms.

From what i got from @Antonio Vazquez (antoniov) is that "switching to windows ink for some studio's just is not an option" so I guess we have to support wintab in one form or another

Yes, the problem is really noticeable with brushes with a small size.
From the Grease Point side this issue is one of the most important problem for medium-big 2D animation studios to adopt
GP for the final art in production. Is a recurring feedback report.

Quick outline of the mouse/Wintab/WinInk situation.

In case of sculpt mode, it uses the same input code as the rest of the painting modes (vertex, weights...). This code just interpolates the positions between two regular mouse events to fill the space with a fixed spacing. For brushes that are usually used with a small size (all cutting and clay brushes), the artifacts are really noticeable. These jagged line artifices is probably what some users identify with "performance issues", while it is just the input code missing the events.

With grease pencil I had to add a lot of algorithms to "guess" what is missing and figure out what points are missing. This algorithm reduces the problems, but it kills some of the small movements done by artists. The goal is to remove all these algorithms and get the real information of the pen movements.

Think at one point in time @Nicholas Rishel (nicholas_rishel) had a patch for this, that got reverted for "reasons" (that escape me completely at this moment) and we were planning to bring back for 3.0 ?

@Daniel Martinez Lara (pepeland) Please, put all the results of your tests in this task.

This is related to D7840

The gpencil team has been discussing about this problem and we have decide to swap the coloring change to fill, so in you case the stroke will have the same color you select. Also, we keep the patch done by @Falk David (filedescriptor) to set flat color.

It looks like a duplicate of T87147: Blender increases ram usage until its too laggy to use after a few minutes of use. , but I'm also not sure how to replicate the problem.

I found a slightly better workaround for the anti-aliasing issue. If you put the Gpencil objects and 3d objects on two different View Layers then put them back together in the compositor with a Z Combine node (enable Use Alpha and disable Anti-Alias Z), you will still need to set EEVEE's filter size to 0, but you can keep the Grease Pencial anti-aliasing on. So not perfect but in some cases it might be enough.

@Antonio Vazquez (antoniov) yes, I have already debugged the issue. I think selected_objects_boundbox_calc is called before any call to create_object_list. So the list of selected objects is empty.
I have a fix ready.

do you have a test file?

Outside camera view must use a rectangle with boundbox. Check the boundboux is propertly calculated.

I can confirm this. This is happening when exporting from outside the camera view.
If something is going wrong, there should be at least some error or message pop-up, so I would see this as a bug.

I agree with Kevin'g comment above - this issue seems like a pretty serious limitation, as the one significant competitive advantage Blender Grease Pencil has over 2D animation software is the ability to combine 3D elements in a 2D scene; using textured 3D meshes with alpha transparency is a very powerful tool. I understand if this issue is not high priority and might not get fixed in the near future, but in my opinion it should not be classified as known limitation. Please let me know if I'm missing something. I would appreciate if someone from the dev team can post a point of view on this.

It looks like this issue is about general 2d animation vs general consistency.
Technicaly, reasons to provide the difference between stroke and fill are inderstandable, but realization is rough because is illogical and unexpected.
There are a lot of things in Blender that can be technically solved as local overrides, but following this way is not the best way to design software, because harms general consistency.

ok. Closing.

thanks! works as expected in the newest alpha

Yes, this should be fixed by rB09d7d88cc42a. @Tomasz Kaye (bitbutter) Please try the latest Alpha from https://builder.blender.org/download/ .

Can you test with the build of today? IIRC @Falk David (filedescriptor) fixed!

I have changed the default. It was arbitrary to set default to ON, better set as disabled.

@Antonio Vazquez (antoniov) Yes, I have it works wonderfully.
I was just wondering why the default would be set to "Unselect Ends"?

@Antonio Vazquez (antoniov)

1. Here 2 strokes with very different colors. And they are almost similat in workbench.

With the change proposed by @Falk David (filedescriptor) you just can set as Flat and you get what you want. Grease Pencil main focus is 2D animation, so get the strokes and fills with a slightly different color is very good. Maybe, for you user case can be annoying, but we cannot set something by default that is against general 2D animation.

In T87406#1145347, @Falk David (filedescriptor) wrote:

@Vyacheslav (hitrpr) And why is it an issue to use the material color and not the object color? It seems to me like the object color is not really what you are looking for.

@Vyacheslav (hitrpr) And why is it an issue to use the material color and not the object color? It seems to me like the object color is not really what you are looking for.

@Falk David (filedescriptor) umm…
I would prefer to select technical color manually to see all better.
Can`t agree with such intensions. Similar problem appears with wireframes: I can`t make em exact same color, as I set. They always darker or lighter…
It produces many problems with complex scenes. @Paul Kotelevets (1D_Inc) can explain it better and already did it.

@Vyacheslav (hitrpr) The color shift was done intentionally (to make strokes and fills visually differentiable). The fix attached makes it so that if the Lighting in the VIewport Settings is set to "Flat", all the strokes and fills will be set to the same color.