From 0fb3aab95bc23d0e91bfc4379552868eb71d94e1 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Fri, 30 Apr 2021 18:44:10 +0200 Subject: [PATCH] Clip-Drag: introduce sub-interface for canvas metric ...previously this was modelled as part of the CanvasHook abstraction, and in fact it will in any case be implemented by delegation to the TimelineLayout or some kind of display manager. We need this to tanslate mouse pixel movements into a time change --- src/stage/model/canvas-hook.hpp | 25 ++++++++-- src/stage/timeline/body-canvas-widget.cpp | 2 +- src/stage/timeline/display-manager.hpp | 9 ++++ wiki/thinkPad.ichthyo.mm | 56 ++++++++++++++++++++++- 4 files changed, 87 insertions(+), 5 deletions(-) diff --git a/src/stage/model/canvas-hook.hpp b/src/stage/model/canvas-hook.hpp index a082527ac..4d3978f36 100644 --- a/src/stage/model/canvas-hook.hpp +++ b/src/stage/model/canvas-hook.hpp @@ -67,6 +67,27 @@ namespace model { + /** + * Mix-in interface to allow for concrete CanvasHooked widgets + * to adapt themselves to the metric currently employed on the canvas. + * In some cases, most notably when a timeline canvas is calibrated to + * represent temporal extension precisely, the widgets (clips, effects) + * within such a display need to adjust themselves. A relevant special + * case is when such a widget _is dragged_ -- receiving mouse move events + * in screen coordinates -- which need to be translated into a resulting + * temporal offset or change as a result of this _interaction gesture._ + */ + class DisplayMetric + { + public: + virtual ~DisplayMetric() { } ///< this is an interface + + /** extension point for time axis zoom management. */ + virtual int translateTimeToPixels (TimeValue) const =0; + }; + + + /** * Interface to represent _"some presentation layout entity",_ * with the ability to _place_ widgets (managed elsewhere) onto it, @@ -80,6 +101,7 @@ namespace model { */ template class CanvasHook + : public DisplayMetric { public: virtual ~CanvasHook() { } ///< this is an interface @@ -117,9 +139,6 @@ namespace model { { return hookedAt (translateTimeToPixels (start), downshift); } - - /** extension point for time axis zoom management. */ - virtual int translateTimeToPixels (TimeValue) const =0; }; diff --git a/src/stage/timeline/body-canvas-widget.cpp b/src/stage/timeline/body-canvas-widget.cpp index 337931c9b..eb9fe80a6 100644 --- a/src/stage/timeline/body-canvas-widget.cpp +++ b/src/stage/timeline/body-canvas-widget.cpp @@ -553,7 +553,7 @@ namespace timeline { } - /* ==== Interface: ViewHook ===== */ + /* ==== Interface: CanvasHook ===== */ void BodyCanvasWidget::hook (Gtk::Widget& widget, int xPos, int yPos) diff --git a/src/stage/timeline/display-manager.hpp b/src/stage/timeline/display-manager.hpp index 052bd1a5e..7cb17a132 100644 --- a/src/stage/timeline/display-manager.hpp +++ b/src/stage/timeline/display-manager.hpp @@ -61,6 +61,13 @@ ** This builds the foundation for implementing UI structures recursively, leading to somewhat ** simplified code, which hopefully is also easier to maintain and extend in the long run. ** + ** \par Avoiding the double-indirect calls? + ** In theory, it would be possible to avoid the double forwarding indirect calls in all the + ** operations of RelativeCanvasHook: We'd have to provide a concrete mix-in to be used already + ** within body-canvas-widget.cpp, and this mixin would hold a _direct reference_ to the embedded + ** Gtk::Layout and provide an additional API to adjust the offset. However, the savings through + ** such an implementation scheme would be dwarfed by the effort for actually rendering a widget. + ** ** @todo as of 10/2018 timeline display in the UI is rebuilt to match the architecture ** @todo WIP-WIP-WIP - drafting the DisplayEvaluation as of 3/2020 ** @todo WIP as of 1/2021 about to build a first preliminary Clip representation @@ -98,6 +105,8 @@ namespace timeline { * @note the ctor uses #getAnchorHook, thus effectively, * for a chain of RelativeCanvasHook instances, * the #refHook_ holds the top level anchor. + * @remark avoiding this 2-step indirect dispatch is not + * justified here, given the overhead of drawing. */ template class RelativeCanvasHook diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index d94308fdc..19e4a798b 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -33130,10 +33130,46 @@ - + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ das Platzieren auf den Canvas ist keine high-Performance-Operation;
vielmehr ist es sogar vernachlässigbar im Vergleich zum Aufwand der Zeichen-Operationen; und letztere werden eben genau aus Performance-Gründen gebatcht und gebündelt.... +

+ + + + + + + @@ -33143,6 +33179,24 @@ + + + + + + + + + +

+ im Gegensatz zum CanvasHook ist das hier durchaus relevant +

+ + + + + +