openshot.developers team mailing list archive
-
openshot.developers team
-
Mailing list archive
-
Message #07344
Re: GTK3 port
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
>
>
Follow ups
References