Re: [CinCVS] Re: [Sodipodi-list] Sodipodi & Cinelerra integration

[Lauris K. <la...@ka...>]

Hello!

Andraz Tori kirjutas T, 30.12.2003 kell 03:08:
> > But on the other hand - having --cinerella-export-file does not
> > hurt either... We can reserve more generic names for better
> > refactored functionality.
> Maybe it should stay like that until interface somehow gets more
> defined, and documented... if it is of any use to other programs also,
> then change it to more general names

Agree :-)

> > Have you more clear ideas, which UI functions should be modified
> > and/or restricted while working as plugin?
> 
> Yes i have some ... the main thing i am thinking about right now is how
> to communicate between cinelerra and sodipodi what is the size of the
> document and when has the size changed...
> 
> The plugin currently works on assumption that X milimeters means X
> pixels. And changing the size of a document after the sodipodi has been
> run in editing mode is impossible (brings wrong results).
> 
> For starters, it would be nice if all units (everywhere in sodpodi)
> could be locked to one of the choices (i prefer milimeters), so there is
> no mess about it. (or maybe having a special choice called 'pixels', but
> i doubt that is SVG-compliant, and it is really more cosmetical :)
> After units are locked, it is possible to have 1:1 view actually present
> 1 unit = 1 pixel on screen.

According to SVG definition of things:
1pixel == 1 userspace unit
1pt == 1.25 pixels
1mm == 72 / 2.54 points
While printing, sodipodi assumes that 1 SVG pt == 1/72th inch
on paper.
Or in the other words - sodipodi SVG documents are always 96dpi.

I have to think, how and if unit-locking is doable.

> I have to make some mechanism to enable cross notification of
> document(overlay) size change between cinelerra and sodipodi, in both
> directions. 

Yeah... I have wanted to do network-whiteboard like thing from
sodipodi for some time, but never get to any code. As document size
is encoded in SVG tree, it would solve this problem as well (what
is needed, is inter-process notification and modifcation system
form SVG DOM tree in sodipodi - being it CORNA, SOUP or whatever
based).

> The size issue looks trivial/non-important, but is actually a very
> important part of making the things 'just work'.
> 
> dbus looks somewhat promising as a general solution, but for now i think
> i will just use pipes... 
> 
> You are probably the best person to ask... where to put a pipe polling
> in sodipodi?

I think you want to add callbacks into glib main loop

> > Also, if you are interested in developing dynamic SVG layer
> > using sodipodi code, I can probably help you. It is not very
> > different from current SVG viewer, except instead of custom Gtk+
> > widget, we attach NRArena to non-ui GObject, and let it render
> > RGBA buffers for overlay.
> 
> The best thing I see in sodipodi (from a prospective of integrating it
> into full video editing & compositing solution) is it's editing
> capability. The importance of having dynamic layer implemented inside
> cinelerra comes to play only when we have SVG animation capabilities,
> which is currently non-issue.
> 
> What would be interesting is if sodipodi, when run in 'plugin mode',
> could have a non-gui view that would render to RGBA image somewhere in
> memory. Then this memory would be passed to 'host' program as shared
> memory and host program notified of change trough some kind of IPC. This
> would allow real-time change propagation...

Hmmm... I am no way good with IPC :-( But again, some shared document
model is needed. Maybe we should start writing something...
Going back from sodipodi->other app is probably easier, as the
only datatype is RGBA bitmap (plus maybe width, height and update
notification). From other app->sodipodi there can be more API
(if we update document in-memory). Or it can be simple also, if we
trigger just reloads and rerenders of file.

> btw: it is probably impossible to get YUVA or 16 bit per channel depth
> from sodipodi?

Not currently. If someone volunteers to write all missing pixel
composers, it can be added semi-trivially...


Best wishes,
Lauris Kaplinski