@Joshua Leung (aligorith) Could you take a look? Not sure how this works (2D Editors).

@Sebastian Parborg (zeddb) I have checked again and the trick is to create the image before do the annotation.

Works:

1. Create Image
2. Do annotation
3. Move

Don't Work:

1. Do annotation
2. Create Image
3. Move

As this is working as it was in 2.79, we can't consider it as bug, no?

@Antonio Vazquez (antoniov) it depends on if this is how it is supposed to work or not. If this is how it was designed to function, then this is not a bug.

@Sebastian Parborg (zeddb) We can consider that it was designed in this way, because this code was ported from 2.79 (not using the same code of grease pencil).

What seems to be truly happening is this;

-If you start with an image, great! It locks!

-But If you don't start with an image, or start with an image but then switch to a 2d view without an image and then annotate, every subsequent stroke, even when you open a new Image in a different 2d editor, doesn't lock the strokes in any 2d view for the entire blendfile ever again.

In 2.79 you at least can change it after in the toolbar, what kind of stroke you want (It's called Stroke placement, view/cursor) in 2.8 you can't. You can only make a new blend file and make sure you accidentally never anotate in a 2d view without an image

I propose to bring the option back, to appear in the topbar, the same way that the Annotation tool in the 3D view already does with the Placement option. And for the default behavior of a new 3d view to be locked to the canvas

That's right, It's because you can't draw (in 2.79) on an empty image, so it reverts to the View. I'm not sure if there are technical reasons to this, the strokes are still visible after removing the image.

You can see this with 2.79:

• Open U/V Image Editor
• Open Toolbar (Stroke placement should be on cursor)
• Start drawing and watch it switch to view.

The same thing is happening in 2.80, it's just that we can't see the options...

In T63402#657637, @Wo!262 (wo262) wrote:

And for the default behavior of a new 3d view 2D editor to be locked to the canvas

Did you mean 2D editor?

IMHO the best solution would be check if there is an image, and if empty, show a warning and cancel annotation.

Ideally I think it should just always stick to the canvas. If you are making notes for UVs that's what you'd want too.

I can't think of any use-case for the current behavior where annotations are relative to the view and not the canvass - we don't do this in the 3D View either.

Umm... @William Reynish (billreynish)

In the 3D view at least it's not the default behavior. Can't really think why one would ever stick annotation lines to the view.

For the UV Editor we could just mirror what we do in the 3D View: By default always attach to canvas/UV space, and have an option to use View.

I agree. Even without an image I make annotations on the positions of UV islands, which needs canvas lock. So the idea of the warning is not ideal either, Annotations definitely have use without an Image open.

In T63402#657946, @William Reynish (billreynish) wrote:

In the 3D view at least it's not the default behavior.

Sorry, I saw an opportunity and I seized it. But it is default behaviour as I explained in T63402#657727

Can't really think why one would ever stick annotation lines to the view.

There are a few reasons why View Placement is important:

• Stroke will stay the same when switching images with different resolutions. Strokes warp/distort on the curser.
• Cursor (Canvis) stroke can't move editor. It's handy having your notes/doodles follow you around from editor to editor.
• View Placed (2D) Annotations don't suffer from the same issues as Cursor (3D) strokes:

Different execution but the same Idea...
https://cloud.blender.org/p/gallery/5beeaec4527ba54c2fe6fbf8

For the UV Editor we could just mirror what we do in the 3D View: By default always attach to canvas/UV space, and have an option to use View.

This is the most rational thing I've heard.

But goal should be to give Annotations (across editors) the same set of tools.

I have been looking at the code (I did not created this area) and I have seen there was an hacky special case for image editor when the image was NULL. The rest of 2D editors always set the annotation locked to canvas (affected by zoom) and never to Screen.

My opinion is to do the same for all 2D annotations and always set to Canvas and never to View. Actually in 2.79 you can select if lock to screen or Canvas, but this is something that came from old grease pencil. I don't think is very user friendly to have two options.... really we want add complexity to UI for a corner case?

How are you making the UX more complicated? I'd argue it's more complicated now because there's no consistency in the Annotations Tool.
The topbar is Empty and we're talking about removing an option we already don't have...

In T63402#658091, @Antonio Vazquez (antoniov) wrote:

always set to Canvas and never to View.

So what would you intend to do with all the View Placement GPencil data in 2.80's Annotations?

What I want to do is keep all 2D editors equal. Today we have a "special" case for Image editor and the rest of 2D editors working differently. The logic, it's to set all 2D editor equal and remove the screen option. It's very weird that you draw an annotation and when you move/zoom the annotation does not move.

If we add a button to define the type of placement, you can add strokes to Screen and to View and it's very confusing to have strokes that moves and others don't. The idea is to make annotations simple.

@Christopher_Anderssarian We cannot use the Topbar because we have only one for screen. If you have a 3D view and a UV editor, you cannot detect what annotation datablock are you using.

In T63402#658112, @Antonio Vazquez (antoniov) wrote:

What I want to do is keep all 2D editors equal.

Yes, that's what I'm saying.

Today we have a "special" case for the Image editor and the rest of 2D editors working differently.

Ah, this is where the confusion may be:

There shouldn't be a distinction between the Image editor and the rest of 2D editors. This is wrong.

Currently All editors implement Annotations differently:

Name	3D Viewport	U/V Image Editor (View)	U/V Image Editor (Paint)	U/V Image Editor (Mask)	Video sequence Editor	Movie Clip Editor	Node editor
Image
Notes	Most worked on most complete				There's no mention on any todo list...	on todo list
Topbar works?	Yes	Shows, doesn't work	No	No	No, N/A, No toolbar	Shows, doesn't work	No
Toolbar?	Yes, New	Yes	Yes	Doesn't exist	Doesn't exist	Old GPencil Implementation (on todo list)	Yes, New
Onion Skin	Yes	No	No	No	Yes	No	No
Can draw on view	Yes	Yes	Yes	Yes	No	Yes	Yes

Requisite blend file:

It's very weird that you draw an annotation and when you move/zoom the annotation does not move.

How is this weird?

In T63402#657978, @Christopher_Anderssarian wrote:

Different execution but the same Idea...
https://cloud.blender.org/p/gallery/5beeaec4527ba54c2fe6fbf8

If we add a button to define the type of placement, you can add strokes to Screen and to View and it's very confusing to have strokes that moves and others don't.

But this is up to the user, with clearly labeled tooltips as to what's going to happen.

The idea is to make annotations simple.

Yes, what I'm saying is that right now it's not simple. Look at the blend file and all the issues listed.

In T63402#658124, @Antonio Vazquez (antoniov) wrote:

@Christopher_Anderssarian We cannot use the Topbar because we have only one for screen. If you have a 3D view and a UV editor, you cannot detect what annotation datablock are you using.

But that's not a Grease Pencil/Annotations issue that's a UI/UX Issue. If/once that's fixed and the active tools are added to added to the editors then there's space and workflow for other options...

Okay the bottom line:

I do not have a problem with removal of features or functionality, as long as it's replaced with something that works. I really do not see this happening before 2.80 release.

IMHO, change annotations is not a primary task for 2.80. Maybe, we could close this task report because the problem is fixed now and open a new task with Annotation ToDos (not only the topbar and space issues).

In T63402#658180, @Antonio Vazquez (antoniov) wrote:

is not a primary task for 2.80.

I know and that's why I didn't report this months ago (and why I don't report all of the bugs/issues/crashes that I still put up with today, because I know it will get removed)

Maybe, we could close this task report because the problem is fixed now and open a new task with Annotation ToDos (not only the topbar and space issues).

This sounds like a good course of action.

@Antonio Vazquez (antoniov) Before this task is closed, can I ask you: Do you at least see where I'm coming from? (just in case)

@Christopher_Anderssarian I understand your points, but we need at some point stop to add things and try to stabilize all. For sure there are a lot of things to fix, but we try to get something good enough... you know, the resources and time are limited. Anyway, it's my opinion only... I'm not part of BF.

Thank you guys!

Thank you @Antonio Vazquez (antoniov) I'll see you in the Annotations todo task ;)