Editor::redisplay_tempo() is called early on, before
Editor::set_timecode_ruler_scale() and Editor::compute_bbt_ruler_scale ()
are called. That is a bug which needs fixing (initial tempo+grid display)
. Still, uninitialized vars are not good.
If pending_visual_change.pending was zero when calling idle_visual_changer
the handler_id was never reset. and the idle-handler was never called
again.
This is necessary to allow calculation of correct intersection of visible
canvas area and items for the new Item::prepare_for_render() API.
samples_per_pixel must be set first to calculate the new horizontal canvas
position in Editor::set_horizontal_position and then
WaveView::set_samples_per_pixel will eventually call
WaveView::prepare_for_render for those items that are visible on the new canvas
position at the new position.
Or if there is not a change to zoom state then call Canvas::prepare_for_render
explicitly.
Also changes so that each method is only called once during
Editor::visual_changer
First visual change will be processed as normal and then blocked until the
canvas renders the change. If further visual changes need processing then
Editor::pre_render callback will schedule another expose/redraw/render.
This prevents an issue where idle_visual_changer is called many times in
response to events(keys/motion/etc) but the canvas does not get a chance to
render any but the last one which results in a big pause/jump.
This results in a more responsive canvas and in particular a smoother and more
predictable zooming experience.
This can be hard to reproduce and I have not been able to work out the steps to
reproduce reliably, but as it is still occuring work around the issue by just
checking the variable is valid before dereferencing it.
Resolves: #7304
- save mode separately for Editor-sidebar and Location Window
- cache mode (multiple calls to set_session())
- fix restore: after creating the editor, instant_save() is called,
potentially overwriting the previous value.
snap now fills in a struct (MusicFrame) which contins a snapped frame
along with a music divisor.
this gives useful information wrt magnetic snap which may or may not
have rounded to an exact musical position.
region position may now be set musically (using quarter notes for now).
this patch fixes several problems in the current code:
- dragging a list of music-locked regions now maintains correct
musical offsets within the list.
- splitting regions using magnetic snap works correctly (#7192)
- cut drag should now work correctly with magnetic snap.
- musical length of split midi regions is no longer frame based.
