[Ardour-Dev] ardour3 video timeline

[Patrick Shirkey]

On 06/29/2010 10:32 AM, Paul Davis wrote:
> On Mon, Jun 28, 2010 at 8:18 PM, Patrick Shirkey
> <pshirkey at boosthardware.com>  wrote:
>
>    
>> Thanks again for the explanation. Is the timeline a canvas too?
>>      
> i suspect that by "the timeline" you mean the set of rulers above
> tracks. its actually a mixture. the editable components are all on a
> canvas; the rulers are actually widgets.
>
>    

Yes.

>> I'm not sure I fully grok the issue but going with the information I have so
>> far it seems that it should be a case of joining the dots to get a canvas
>> item from the timeline to display in the edit canvas. They both have access
>> to the actual timeline else it wouldn't be possible to sync them. So I
>> wonder why Robin has found it requires so much code as to make it
>> particularly difficult? Is the problem that the edit canvas has all the
>> hooks&  returns for editing that are not available for the timeline so the
>> code falls over as it is not receiving enough information from the a
>> timeline item?
>>      
> there is no "timeline item". there is a canvas used by the editor.
> various horizontal items are placed on it, which correspond to tracks.
> within those items are subitems, which correspond to (e.g. regions)
> and within those are sub-sub-items and so on ad infinitum.
>
>    
>> I'm not suggesting it should be a priority for you or anyone else but it
>> seems there is an opportunity here to make the edit canvas a bit more
>> flexible.
>>      
> there is no such oppurtunity. the current canvas is quite flexible
> enough, and the areas in which it is deficient require us to switch to
> an entirely new canvas implementation, something that has been on the
> TODO list for many years.
>
>    

I hope you don't mind revisiting this concept at the moment.

>> In other words it should be possible to have tracks that can't be
>> edited displayed in the edit canvas. This would potentially open up the door
>> for other non editable canvas items such as a "master waveform".
>>      
> there are already such tracks. and there are already non-editable canvas items.
>
>    
>> It would for example provide a way to embed plugins into the edit canvas,
>> Spectrum analysis items, pretty much any canvas item that it not fully
>> editable could be tested that way.
>>      
> i'm not sure you understand the architecture. you need to think in
> different terms than you are right now, i think.
>
> a canvas is basically a drawable, scrollable area. canvas items have a
> position and size on the canvas, and are composited ("layered, with
> opacity") by the canvas. each item draws itself onto the canvas when
> told to do so. what it draws is up to it, and only it. each item can
> receive events (keyboard, mouse and all the other events accessible to
> widgets), which it might handle by itself, or simply pass it along to
> its parent, which might handle it or pass it along to its parent and
> so on until it reaches the top level canvas, at which point it enters
> the "normal widget heirarchy" just as it would without any canvas
> items.
>
> there's no magic to the canvas. its just a set of code that draws
> stuff and handles events. the major difference is that it supports
> z-axis "stacking" and supports drawing with opacity or "alpha channel"
> which historically widgets did not do. when you drag a region or a
> control point around all that is happening is that the canvas is
> telling the items in the area where it used to be to redraw, and the
> items (including the region/control point) where it now is to redraw
> also. the result is a new "image" of the canvas, and that is what you
> see.
>
>    

Thanks for that detailed explanation.


> writing new canvas items is not very hard. integrating them into
> ardour is harder but manageable. robin faces some MUCH harder problems
> than this (which he has solved before, mostly) that relate to (1)
> obtaining the data to display (2) caching it appropriately so that
> scrolling and other activities are handled efficiently. this stuff is
> hard.
>
>    

It seems that he has solved these 2 items in relation to the ruler 
display area.

What I am missing is the specifics on what is different between the 
ruler section and the edit section and why the rulers can't be dropped 
randomly anywhere on the edit canvas.

Am I correct that the ruler is drawn on top of the edit canvas? or is it 
a seperate ruler canvas?

Is it simply that the ruler widgets are not able to be drawn in the edit 
canvas because they are widgets and not canvas items?

Sorry, if this is just rehashing an old discussion. What I am trying to 
do is understand the issues that Robin faces so I can assist with 
implementation details.


-- 
Patrick Shirkey
Boost Hardware Ltd