openshot.developers team mailing list archive

["eolinwen@xxxxxxxxx" <eolinwen@xxxxxxxxx>]

HI Jonathan,

It will be not helpful but if we could Clutter instead of to use SDL. The
Gnome Team have seen the lack of this librairy (i.e less perform than Compiz
=> 30 fps against 60 fps) and they are working on. Canonical saids that
although they are using Compiz (better in performance actually), Clutter
will be more perform after. Also, Clutter is the future.

Maël is on holidays until the 27 of this month.

Cheers.
2011/8/17 Jonathan Thomas <jonathan.oomph@xxxxxxxxx>

> Hi Maël,
> Sorry I never replied to your email about GTK3 and OpenShot.  I am very
> excited about your progress, and of course, GTK3 will be a big move for the
> OpenShot code-base, and I appreciate your help!
>
> I have been steadily working on the new C++ video editing framework, and
> specifically displaying the frame on the screen.  Creating Pixbufs in pygtk
> (or PyGObject) is very slow (relatively speaking), and in my testing, not
> feasible for creating a native GTK video player widget.  So, naturally, I
> looked back at SDL, which uses X11 draw functions, and just draws over top
> GTK.  However, I'm very interested to know if you have uncovered any new
> information about the lack of a get_xid() method in PyGObject?  Clearly,
> that is going to be a show-stopper for any SDL based application that needs
> to draw onto a GTK window.  I have been investigating this as well, but I
> always end up on a forum, bug report, forum post, or chat log where "you"
> are asking the question, and nobody is answering you. =)  So, it seems like
> you have made a huge effort to reach out to the GTK community and figure out
> a work-around.  Hopefully, you have some good news to share with us...
>
> Here is a recap from my testing:
>
>    - GTK is way too slow to create a native pixbuf-based video player,
>    which needs to update 30 times a second (or faster).  Also, I was able to
>    hook up a Python callback method to draw each frame from my new library, but
>    even the passing pixel arrays to Python was a bit too slow for a video
>    player.  So, I just don't think Python or GTK is going to be able to
>    accomplish a native video player widget.
>    - SDL is incompatible with PyGObject & GTK3, due to the lack of a
>    get_xid() method
>    - Actually, any X11-based drawing library will be unable to draw on GTK
>    without an XID property
>    - Clutter is based on OpenGL, which I don't really want to require for
>    OpenShot... but will if I have no other choice
>
> Also, I have discovered that most video players, including FFplay &
> Gstreamer, use an SDL-based or X11-based drawing method.  Regardless if we
> are using MLT or a new framework, having X11 draw on top of GTK is still
> looking like the best approach... assuming we don't want to require OpenGL.
>
> Somehow, we really need to beg for the get_xid() method to be fixed in
> PyGObject. =)
>
> Thanks!
> -Jonathan
>
>
> On Thu, Jun 30, 2011 at 4:28 AM, <moimael@xxxxxxx> wrote:
>
>> Hi,
>>
>> Here are some news on my actual work.
>> I'm working on the GTK3 version of openshot. Yesterday, i managed to get a
>> first (almost) working Pygobject/GTK3/GooCanvas2 version of openshot. It
>> required lot of changes to actually display the UI.
>>
>> I'm planning to make some modification to start on sane basis :
>>
>> - Port settings to GSetting(multi-os) and make them non-ui dependant (to
>> fix a bug with openshot render)
>> - Remove the melt dependency (as distribution whose ship GTK3 come only
>> with new version of mlt)
>> - Remove the embeded gdata api for youtube and use the system one.
>> - Some UI refinment to use all the GTK3 power (take advantage on the new
>> height for width layout system, use new widgets)
>> - Maybe some long time standing bug will be fixed with the port
>>
>> The biggest problem i encounter in this preliminary version is the
>> get_xid() function to embed the sdl window in our drawingarea, now it popup
>> a new window for the sdl preview. It seems that get_xid() is not
>> introspectable -introspection = 0 in the gir file), so i have to find a
>> replacement. Any idea ?
>>
>> Maybe this work can end up in a 2.0 openshot release ? What do you think ?
>>
>>
>> I think the transition in GTK3 should not happend with the transition from
>> mlt to our new video library. It will be to much changes. A two step
>> transition is better.
>>
>> Thanks !
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openshot.developers
>> Post to     : openshot.developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openshot.developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openshot.developers
> Post to     : openshot.developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openshot.developers
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Olivier
Cenwen un elfe sur la banquise/ an elve on the ice
Mon blog perso  sur le multimédia, Ubuntu, Linux et OpenShot :
http://linuxevolution.wordpress.com/
Le forum d'Openshot où vous me trouverez : http://openshotusers.com/
http://openshotusers.com/forum/index.php