• Review all float constants.
• Review if you can use constfor variables that don't change.

After testing, I'm not sure about Diamond and Triangle shapes... maybe it would be better a simple line perpendicular to use to draw "segments".

Also, I have see some problems in the 2D panel.

In D7608#183363, @Antonio Vazquez (antoniov) wrote:

After testing, I'm not sure about Diamond and Triangle shapes... maybe it would be better a simple line perpendicular to use to draw "segments".

Also, I have see some problems in the 2D panel.

@Antonio Vazquez (antoniov)
About Shapes:

• Triangle is the inverted version of the closed arrow, is the same code but with a negative mult that inverts the position, so it costs nothing to keep.
• Having a segment start/end of line is fine, I think we can re-use the code of the open arrow and invert open arrow for that as they follow the same structure, I think I only need to vary the angle where the calculations are done.

• About the diamond, it's a common shape in this kind of tools, but well.. sure a more squared diamond shape. The cost of having it is relatively low as well as opens a way to bit more complex shapes as have one point more than any other and different structure of how points are following, being 3 groups in this matter: {open arrow + inverted}, {closed arrow + triangle}, {diamond}.
• Having it or not having it is indifferent, it is already done but it can be removed for sure if You think there are *many styles* yet.

About the Interface:

• Not sure why... what's the sense in Blender that the same code is used for header (horizontal) and panel (vertical)?. But yes, I can play a bit with it to fit it well in both places.

Can't find the problem, seems like Blender UI thing related(?
In VIEW_3D it looks nice but not in other spaces... there's a checkbox that it's not in view 3d

Also, for UI team and GP team, what option do you see more consistent over the tool header:

1. "Style" with both enum properties aligned
2. Each property splitted with "Start" and "End" texts
3. Any suggestion?

IMO the line start-end for Annotation should be only the most simple and useful types and avoid lines overlapping.
My proposal:

@Matias Mendiola (mendio) I agree...only doubts about circle (or rounded) shape...this needs a lot of points and I think it don't worth enough to increase internal data structures.

In D7608#183548, @Antonio Vazquez (antoniov) wrote:

@Matias Mendiola (mendio) I agree...only doubts about circle (or rounded) shape...this needs a lot of points and I think it don't worth enough to increase internal data structures.

For the circle/poly it's only 8 points, but you know better the technical implications

In D7608#183543, @Matias Mendiola (mendio) wrote:

IMO the line start-end for Annotation should be only the most simple and useful types and avoid lines overlapping.
My proposal:

@Matias Mendiola (mendio)
Hi Matias, first of all thanks for the proposal and the mockup!

About line overlapping:

• In the closed arrow I can solve it with some low modifications, no problem. How the code works, the arrow is a separated stroke and what you "move" is the end point of the line stroke, the arrow only adapts to that point, that means if we pull the arrow stroke outsides (arrow direction) it will be offset as you can see in the triangle shape, no overlap but not precise (not right under the mouse), the other solution is compressing the line but it will be more of a task and change too much the actual code, I'm not sure if it would be worth it. What are your opinions about this?

About arrow selection:

• I'm ok with this.
• I see the "invert" versions of both arrows are not preset. In terms of code, both, the original version and inverted have the exact same code but a signal that determine what direction should it turns to, so removing that won't be that much than removing few lines.
• The perpendicular line won't be so much difficult to do as only varying the angle of the first one is fine.
• For the circle one I would suggest to not include as far as possible if it's not +90% esential. I can do it for sure but in the worst must be simpler to not increase that much just for one style... What about rectangle or perfect squared diamond (rhombo)

About line overlapping:

• In the closed arrow I can solve it with some low modifications, no problem. How the code works, the arrow is a separated stroke and what you "move" is the end point of the line stroke, the arrow only adapts to that point, that means if we pull the arrow stroke outsides (arrow direction) it will be offset as you can see in the triangle shape, no overlap but not precise (not right under the mouse), the other solution is compressing the line but it will be more of a task and change too much the actual code, I'm not sure if it would be worth it. What are your opinions about this?

I know what you mean, if possible the nice solution should be that the arrows end right under the cursor. Maybe @Antonio Vazquez (antoniov) could give you some clues on how to solve this

About arrow selection:

• I'm ok with this.
• I see the "invert" versions of both arrows are not preset. In terms of code, both, the original version and inverted have the exact same code but a signal that determine what direction should it turns to, so removing that won't be that much than removing few lines.
• The perpendicular line won't be so much difficult to do as only varying the angle of the first one is fine.
• For the circle one I would suggest to not include as far as possible if it's not +90% esential. I can do it for sure but in the worst must be simpler to not increase that much just for one style... What about rectangle or perfect squared diamond (rhombo)

yes, a square could be a fair replacement, without rotation IMO.

About the controls placement on the top bar is better to move them after the placement control to avoid jump when you change between Annotation tools

Start-End types updated

In D7608#183557, @Matias Mendiola (mendio) wrote:

I know what you mean, if possible the nice solution should be that the arrows end right under the cursor. Maybe @Antonio Vazquez (antoniov) could give you some clues on how to solve this

That would be very welcome.

yes, a square could be a fair replacement, without rotation IMO.

That's nice

About the controls placement on the top bar is better to move them after the placement control to avoid jump when you change between Annotation tools

Great, I will take note of that, thanks for the feedback

In D7608#183853, @Julian Eisel (Severin) wrote:

Nice one, guess this is almost ready. Just one note and a few unused-vars to be addressed.

Yuk, the last refactor turned into too much unused vars that I missed, thanks for pointing me out!

There's arrow_start and arrow_end in a permanent runtime struct, but it is still re-filled on every redraw apparently. There's not much sense in keeping it stored then, why isn't geometry just drawn directly?

The temporal struct tGPsdata is not accesible via draw so the only way we saw was to store it in bGPdata_Runtime... The draw is not in the operator but a separated process. By design points are calculated in annotate_paint.c, immediate draw (for preview) in annotate_draw.c and convert them to annotation stroke in annotation_paint.c.

Also, we this doesn't entirely follow our code-style, see https://wiki.blender.org/wiki/Tools/ClangFormat.

I will take a look on that, thanks again.
@Julian Eisel (Severin)