diff --git a/doc/devel/uml/Timeline-clip-display.png b/doc/devel/uml/Timeline-clip-display.png new file mode 100644 index 000000000..b0a1fe17e Binary files /dev/null and b/doc/devel/uml/Timeline-clip-display.png differ diff --git a/uml/Lumiera.xmi b/uml/Lumiera.xmi index 1195c8e62..20a400692 100644 --- a/uml/Lumiera.xmi +++ b/uml/Lumiera.xmi @@ -1,5 +1,5 @@ - + umbrello uml modeller http://umbrello.kde.org @@ -16,6 +16,7 @@ + @@ -36,10 +37,45 @@ - + + + + + + + + + + + + + + - + + + + + + + + + + + + + + + + + + + + + + + @@ -66,13 +102,110 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + + + + + + + + + + + + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -93,7 +226,7 @@ - + @@ -117,9 +250,21 @@ - + + + + + + + + + + + + + @@ -133,7 +278,1431 @@ - + + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + +
+ +
+ + + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + +
+ +
+ + +
+ +
+ +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + +
+ +
+ + +
+ +
+ +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + +
+ +
+ + + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + +
+ +
+ + +
+ +
+ +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + +
+ +
+ + + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + +
+ +
+ + +
+ +
+ +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + +
+ +
+ + + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + +
+ +
+ + + + + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + + + +
+ +
+ + + + + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + + + +
+ +
+ + + + + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + + + +
+ +
+ + + + + + + + + + + +
+ +
+ + +
+ +
+ + + + + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + + + +
+ +
+ + + + + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + + + +
+ +
+ + + + + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + + + +
+ +
+ + + + + + + + + + + +
+ +
+ + +
+ +
+ + +
+ +
+ +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + + + + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + + + +
+ +
+ + + + + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + + + +
+ +
+ + + + + + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + +
+ +
+ + + +
+ +
+ + + + + +
+ +
+ + + + + + + + + + + +
+ +
+ + +
+ +
+ + +
+ +
+ +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + + + + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + +
+ +
+ + +
+ +
+ + + + + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + +
+ +
+ + +
+ +
+ + +
+ +
+ +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + + + + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + +
+ +
+ + +
+ +
+ + + + + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + +
+ +
+ + +
+ +
+ + +
+ +
+ +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + + + + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + +
+ +
+ + +
+ +
+ + + + + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + + + +
+ +
+ + +
+ +
+ + + diff --git a/wiki/renderengine.html b/wiki/renderengine.html index b0479b4e7..5e685af99 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -1432,6 +1432,17 @@ Lumiera agrees to this common understanding (of most film editing and sound hand → PipeHandling +
+
//mediating entity used to guide and control the presentation of a clip in the UI.//
+
+The clip representation in the UI links together two distinct realms and systems of concerns. For one, there are the properties and actions performed on the clip for sake of editing a movie. Everything which has a tangible effect on the resulting render. These information and operations are embodied into the HighLevelModel and can be manipulated script driven, without relying on an UI. But beyond that, there is also the local mechanics of the interface, everything which makes working on the edit and interacting with the model into a smooth experience and workflow. With respect to this concerns, a clip is a self-contained entity which owns its own state and behaviour. The ClipPresenter is the pivotal element to link together those two realms.
+
+[>img[Clip presentation control|uml/Timeline-clip-display.png]]
+Regarding the global angle, the ClipPresenter is an UI-Element connected to the UI-Bus, and it is added as child element to some parent entity, typically the UI representation of a [[fork ("track")|Fork]]. Commands manipulating the clip can be sent via the embedded bus terminal, and status regarding clip properties and nested child elements (effects, transitions) is received as messages via the bus, which insofar plays the role of model and controller.
+
+But regarding the local UI behaviour, the ClipPresenter acts autonomous. It controls an actual {{{ClipWidget}}} for presentation, negotiating the display strategy with some overarching presentation manager. Active parts of the widget are wired back to handling methods of the presenter.
+
+
Background: #fefefd
 Foreground: #000
@@ -2441,7 +2452,7 @@ we need a test setup for this investigation.
 * realistic: shall reflect the situation in our actual UI
-
+
//The representation of a [[media clip|Clip]] for manipulation by the user within the UI.//
 Within Lumiera, a clip is conceived as a //chunk of media,// which can be handled in compound. Clip as such is an abstract concept, which is treated with minimal assumptions...
 * we know that a clip has //media content,// which need not be uniform and can be inherently structured (e.g. several media, several channels)
@@ -2470,11 +2481,22 @@ This is unfortunate, since it defeats a self-contained control structure, where
 
 This creates a tension related to the kind of architecture we want to build with the help of the UI-Bus. The intention is to split and separate between the application global concerns, like issuing an editing command or retrieving changed model contents, and the //local UI mechanics.// This separation can only work, if -- with respect to the global concerns -- the UI-Bus embodies (actually mediates) the roles of model //and// controler, while the UI widgets take on the role of a "mere view". While, for the local concerns, the same widgets are to act self-contained. But now, already the existence of aforementioned widgets becomes dependent from another, obviously local concern, which unfortunately cross-cuts the 1:1 relation between model entities and view counterpart.
 
-Starting from the architecture as predetermined by the UI-Bus, it is clear that we have to add a UI-Element for every tangible child entity represented in the (abstracted) model. And the parent entity receiving a diff and adding such a child element is also in charge of that element, controlling its lifecycle. Yet this child element is not necessarily bound to be a widget. This is our chance here: what "adding" means is completely within the scope of the parent element and basically an implementation detail. So the parent may create and own a tracker or controller object to stand for the clip, and the latter may create and adjust the actual widget in negotiation with a display strategy.
+Starting from the architecture as predetermined by the UI-Bus, it is clear that we have to add a UI-Element for every tangible child entity represented in the (abstracted) model. And the parent entity receiving a diff and adding such a child element is also in charge of that element, controlling its lifecycle. Yet this child element is not necessarily bound to be a widget. This is our chance here: what "adding" means is completely within the scope of the parent element and basically an implementation detail. So the parent may create and own a tracker or controller object to stand for the clip, and the latter may create and adjust the actual widget in negotiation with a display strategy. So effectively we're introducing a //mediator,// which represents the clip (as far as the modelling is concerned) and which at the same time communicates with a global display manager. We call this mediating entity a ClipPresenter
 
 !!!how to carry out the clip appearances
-Initially, one could think that we'd need to build several widgets to realise the wide variety of clip appearances. But in fact it turns out that we're able to reshape a single base widget to encompass all the necessary presentation styles. This base widget is a simple, one-element container, with {{{Gtk::Frame}}} being the most obvious pick. This gives us already a rectangular covered space, and the ability to add a label widget, optionally with controlled alignment of the label. All the more elaborate presentation styles can be achieved by adding a canvas widget into this frame and then placing additional stuff on top of that.
+Initially, one could think that we'd need to build several widgets to realise the wide variety of clip appearances. But in fact it turns out that we're able to reshape a single base widget to encompass all the necessary presentation styles. This base widget is a simple, one-element container, with {{{Gtk::Frame}}} being the most obvious pick. This gives us already a rectangular covered space, and the ability to add a label widget, optionally with controlled alignment of the label. All the more elaborate presentation styles can be achieved by adding a canvas widget into this frame and then placing additional stuff on top of that. The only tricky part arises in overview display, when just some clip rectangle can stand-in for a whole series of clips, which themselves remain hidden as UI elements.
 
+A prime consideration regarding this whole clip presentation strategy is the performance concern. It is quite common for movie edits to encompass several hundred individual clips. Combined with several tracks and an elaborate audio edit, it may well happen that we end up with thousands of individual UI objects. If treated naively, this load might seriously degrade the responsiveness of the interface. Thus we need to care for the relevant infrastructure to enable optimisation of the display. For that reason, the memory footprint of the ClipPresenter and the basic widget has to be kept as small as possible. And moreover, since we do our own layout management in the timeline display, in theory it is possible any time just to add those widgets to the enclosing GTK container, which are actually about to become visible. (if we follow this approach, a problem yet to be solved is how to remove widgets falling out of sight, since removing N widgets easily turns into a quadratic operation).
+
+!clip content rendering
+In a typical editing application, the user can expect to get some visual clue regarding the media content of a clip. For example, sound clips can be visualised as waveform, while movie clips might feature a sequence of images taken from the video. Our intention is to ''use our own rendering engine'' to produce these thumbnails. In fact, our engine is perfectly suited for this task: it has precisely the necessary media decoding and rendering abilities, plus it offers an elaborate system of priorities and deadlines, allowing to throttle the load produced by thumbnail generation. In addition to all those qualities, our engine is planned to be complemented by an "intelligent" frame cache, which, given proper parametrisation, ensures the frequently requested thumbnails will be available for quick display. For this approach to work, we need to provide some infrastructure
+* we need to configure and maintain a //preview rendering strategy.//
+* the request for rendering has to be cast "just somewhere" as message, obviously via the UI-Bus
+* actually rendered content will likewise arrive asynchronously as message via UI-Bus.
+* we still need to work out how buffer management for this task will be handled; it should be a derivative of typical buffer management for display rendering.
+* the clip widget needs to provide a simple placeholder drawing to mark the respective space in the interface, until the actual preview arrives.
+
+To start with, mostly this means to avoid a naive approach, like having code in the UI to pull in some graphics from media files. We certainly won't just render every media channel blindly. Rather, we acknowledge that we'll have a //strategy,// depending on the media content and some further parameters of the clip. This might well just be a single ''pivot image'' chosen explicitly by the editor to represent a given take. And the actual implementation of content preview rendering will largely be postponed until we get our rendering engine into a roughly working state.
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 56651d29c..ed8374660 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -99,8 +99,7 @@ - - + @@ -117,19 +116,21 @@ Verwende das als Leitgedanke, um das Layout zu entwickeln

- - + + + + @@ -138,6 +139,95 @@ + + + + + + + + + + + + + +

+ UI-Bus gilt nur für globale Belange +

+ + + + + + + + + + + + + + + + + + +

+ es geht nur um Rollen +

+ + + + + + + + + + + + + +

+ das lokale Element muß nur als View fungieren +

+ + + + + + + + + + + + + + + + + + + +

+ kann sich selbst +

+

+ transformieren +

+ + + + + + + + + + + @@ -9681,8 +9771,7 @@ Kind-Widgets noch gar nicht festgelegt war (denn das passiert erst beim draw).

- - +