openshot.developers team mailing list archive

[Jonathan Thomas <jonathan.oomph@xxxxxxxxx>]

Again, my only "fear" of Clutter is that we lose half our user-base, due to
a requirement of OpenGL.  I don't think Clutter will fallback to a
software-based backend if OpenGL is not available.  I could be wrong, so
please correct me if I am wrong.  But there is no "default" app (that I'm
aware of) in any Linux distribution that requires OpenGL... or the app will
just not launch or crash if missing OpenGL.  Even Unity and Gnome Shell have
a "fallback" backend, that only uses software to draw to the screen.

So, if SDL can draw 60+ times a second to the screen, and optionally scale
images using OpenGL (which is does), and only puts stress on a single CPU,
I'm not sure if Clutter would really improve the performance.  For example,
the CPU will still be working hard to convert pixel arrays to the correct
colorspace, type, and shape for Clutter, up to 60 times a second.  OpenGL
only gives us an advantage when scaling the image and displaying the image.
 But I bet the performance would be almost identical to SDL.  Of course, if
we wanted to rotate our video 360 degrees, or wrap our video on a cube,
OpenGL would just be awesome, and destroy SDL.  But, my main point here, is
we only want to display an image for a fraction of a second, and repeat.
 OpenGL just isn't being taken advantage of very much... and thus it doesn't
improve performance very much.

Hopefully this all makes sense. =)

Thanks!
-Jonathan

On Fri, Aug 19, 2011 at 3:35 AM, eolinwen@xxxxxxxxx <eolinwen@xxxxxxxxx>wrote:

> 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
>