Page MenuHome

VSE, marker area is invisibly blocking the strips
Confirmed, NormalPublicKNOWN ISSUE

Description

System Information
Xbuntu / AMD

Blender Version
e85aa8b

Short description of error
When working in the VSE, if you create a marker there's an invisible "marker area" that's created a the bottom but you can still see the strips underneath even though you can't interact with them in this area. The marker area would really need to be its own thing and push the rest of the VSE upwards so those two areas are not in visual conflict.

Note: Pablo (Vazques) asked me to report this as a bug.

Exact steps for others to reproduce the error
New file
Go to the VSE
Add a strip on layer 0 (bottom layer)
Create a marker
Try to interact with the strip with the cursor at the bottom of the VSE

Event Timeline

Wouldnt it be enough to restrict the horizontal clickable "hotspot" to some extend around the actual marker position? (as of now it seems to total region width is occupied for that -- indicated by a slight transparent overlay [which goes away if you have no markers at all]).
(Just saying, because pushing the whole area upwards would mean wasting quite some vertical space, no?)

Brecht Van Lommel (brecht) lowered the priority of this task from 90 to Normal.Nov 22 2018, 1:11 PM

Markers were designed to work this way, overlapping the contents of the editor also in the dopesheet for example.

This could be improved, if there is a design for it perhaps it can be added to the UI paper cuts. But I'm not sure I would consider this a bug.

Problem is, that blocked area is absolute, regardless of timeline zoom and it can block lower channels., as you can not pan below zero.

Simplest thing would be turn markers upside down. so they are selected on the upper part of timeline.
Should I write patch for this?

I am unable to reproduce can you provide a simple .blend file.

Richard Antalik (ISS) changed the subtype of this task from "Report" to "Known Issue".

The issue is demonstrated in this image

Problem is, that blocked area is absolute, regardless of timeline zoom and it can block lower channels., as you can not pan below zero.

Simplest thing would be turn markers upside down. so they are selected on the upper part of timeline.
Should I write patch for this?

Putting the marker on the top won't help because it would then block the sequences on the top.

I try to get this fixed as quickly as possible in order to get it into 2.82

Problem is, that blocked area is absolute, regardless of timeline zoom and it can block lower channels., as you can not pan below zero.

Simplest thing would be turn markers upside down. so they are selected on the upper part of timeline.
Should I write patch for this?

Putting the marker on the top won't help because it would then block the sequences on the top.

You can pan, to put upper sequences lower in view.
It would be good idea to discuss this with @William Reynish (billreynish) first. I will seek approval of UI team anyway.

If not changing placement you can offset drawing bottom channel or make markers area auto-hide.

I think the best solution is to offset the strips so the bottom ones aren't always covered. Or, make it possible to scroll past the bottom layer.

I don't think we should move the marker region to the top. It would make things inconsistent, but it's also a workaround exposed as feature.

To fix this, we should progressively push in a margin at the bottom, so that the strip always stays in view. Like demonstrated here (the video player controls overlap the important bit, move the mouse away to make them disappear):

This is the hack I used to get this behavior:

1diff --git a/source/blender/editors/space_sequencer/sequencer_draw.c b/source/blender/editors/space_sequencer/sequencer_draw.c
2index 333a51e2eac..d558db45103 100644
3--- a/source/blender/editors/space_sequencer/sequencer_draw.c
4+++ b/source/blender/editors/space_sequencer/sequencer_draw.c
5@@ -2003,6 +2003,12 @@ static void draw_cache_view(const bContext *C)
6 GPU_blend(false);
7 }
8
9+static bool sequencer_has_markers(const bContext *C, SpaceSeq *sseq)
10+{
11+ const ListBase *markers = ED_context_get_markers(C);
12+ return (sseq->flag & SEQ_SHOW_MARKERS && markers && !BLI_listbase_is_empty(markers));
13+}
14+
15 /* Draw Timeline/Strip Editor Mode for Sequencer */
16 void draw_timeline_seq(const bContext *C, ARegion *ar)
17 {
18@@ -2010,9 +2016,13 @@ void draw_timeline_seq(const bContext *C, ARegion *ar)
19 Editing *ed = BKE_sequencer_editing_get(scene, false);
20 SpaceSeq *sseq = CTX_wm_space_seq(C);
21 View2D *v2d = &ar->v2d;
22+ const bool has_markers = sequencer_has_markers(C, sseq);
23+
24 View2DScrollers *scrollers;
25 short cfra_flag = 0;
26 float col[3];
27+ /* View space */
28+ float pad_bottom_view = 0.0f;
29
30 seq_prefetch_wm_notify(C, scene);
31
32@@ -2026,6 +2036,20 @@ void draw_timeline_seq(const bContext *C, ARegion *ar)
33 }
34 GPU_clear(GPU_COLOR_BIT);
35
36+ if (has_markers) {
37+ float yscale;
38+
39+ UI_view2d_scale_get(v2d, NULL, &yscale);
40+
41+ /* Effectively, what this does is: If the yscale is smaller than the marker region, add the
42+ * difference as bottom offset so that no channel gets stuck behind the marker region. */
43+ if (yscale < UI_MARKER_MARGIN_Y) {
44+ pad_bottom_view = ((UI_MARKER_MARGIN_Y + 2) / yscale) - 1.0f;
45+ }
46+ }
47+ /* Scale up current rect at the bottom, making space for markers if needed. */
48+ v2d->cur.ymin -= pad_bottom_view;
49+
50 UI_view2d_view_ortho(v2d);
51
52 /* calculate extents of sequencer strips/data
53@@ -2122,4 +2146,6 @@ void draw_timeline_seq(const bContext *C, ARegion *ar)
54 BLI_rcti_init(&rect, 0, 15 * UI_DPI_FAC, 15 * UI_DPI_FAC, ar->winy - UI_TIME_SCRUB_MARGIN_Y);
55 UI_view2d_draw_scale_y__block(ar, v2d, &rect, TH_SCROLL_TEXT);
56 }
57+
58+ v2d->cur.ymin += pad_bottom_view;
59 }

Note however that this only covers drawing. Input handling (e.g. selecting strips) does not get the offset applied and is therefore notably off.
What we'd have to do is consistently apply an offset, wherever coordinates are accessed - in both, drawing and handling. I'd suggest adding a runtime struct to SpaceSeq so that the offset can be accessed like SpaceSeq.runtime.offset_bottom. It would be set/updated on drawing.
Not the easiest task, although most of it is probably "monkey work".

For reference: I did something similar for the file browser file list header (the bar saying "Name", "Date Modified" and "Size"): It is part of the main region, but the file list and the vertical scrollbar get offset to make space for it. See SpaceFile.layout.offset_top.

Ideally these offsets would be supported by View2D, but that is another can of worms.

I agree with adding offset in bottom part.

Thanks for suggestion to add offset in sseq.