Re: Clutter in Fremantle (Alpha SDK)
On Tue, 2009-03-17 at 18:04 +0100, ext Henrik Hedberg wrote: Kimmo Hämäläinen wrote: On Tue, 2009-03-17 at 08:37 +0100, ext Henrik Hedberg wrote: Is this somehow related to this statement: It is assumed that we will have only one OpenGL drawing context, and thus a single process running in the system will be using Clutter at a time. This process will be the window manager and the implementor of all challenging graphical UI effects on the screen. [2] This we have assumed in the design, but it does not mean that multi- context does not work. As Kate has already proven, multi-context works. But as long as you have hildon-desktop running in the background, you will not render directly to the screen even if you use Clutter/QtGraphicsView/EGL+OpenGLES2.0/whatnot in your application. When hildon-desktop is running, it is the only one drawing on the screen (with the exception of XVideo). So, killing hildon-desktop is the only way to get direct rendering to the screen at the moment. (We might have something more elegant for this in the future...) Could you clarify what does this mean in practice? Is the performance of 3D rendering significantly slower in applications, for example? I suppose that even if off-screen rendering is used it is still hardware accelerated. Thus, compositing in window manager level should not be a big issue, and we can live with that (for now) if everything just work fast enough. Who needs direct rendering anyway. :) Keeping the compositor around has some performance impact, because after the application draws to an offscreen pixmap (the window), the X server sends Damage events (saying this part of the pixmap changed) to hildon-desktop, and hildon-desktop asks the 3D HW to use this pixmap in a OpenGL texture and draw it to the screen. So, there is some extra delay (maybe 10-25ms) after the application's drawing is visible. Second implication is that you cannot use HW accelerated zooming and moving of textures for the whole graphical pipeline. You can use it for drawing into your window, but when hildon-desktop draws to the screen, it cannot use it (e.g. it cannot say move this content to there). It will just get a big damage area that is updated by updating the OpenGL texture content. Third implication: to save memory, we are using the texture-from-pixmap GL extension to allow the X server and 3D HW share the pixmap data. This means that while 3D HW is accessing the pixmap data (while transferring it to the 3D chip), X server cannot access it. Thus, while the compositor is updating the screen, it is slowing down X drawing. However, it's not mandatory to use texture-from-pixmap, but then you are paying the price in increased RAM usage. BR; Kimmo BR, Henrik ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Clutter in Fremantle (Alpha SDK)
Hendrik, I assume that to use clutter in your application is to somehow get the window manager to shutdown the opengl context and then open yours for the duration before once again reopening the window manager. A somewhat challenging prospect! Whilst its possible to use x11 compositing to bring in a gtk or qt window, I assume there is no extension to composite an opengl window itself. And since its difficult to allow sharing of data between applications this is not something that could be fixed elegently. really makes you appreciate the underlying beauty of x11 :) I'm getting round this by designing my framework to allow both standalone unshared instances to be run (multiple XV overlays are allowed) and I have also put the core principles in place for dynamically loading shared application widgets into the playground. It should be as simple as a change in the makefile to switch a properly designed application between standalone or shared :) gary On Tue, Mar 17, 2009 at 7:37 AM, Henrik Hedberg henrik.hedb...@innologies.fi wrote: Hi, How is Clutter supposed to work in applications in Fremantle? Will the Clutter-GTK library be included in the final SDK? I have tried to run a Clutter application that works in desktop environment. It compiles fine, but nothing happens when starting it in the Alpha SDK. Also, even the simplest example application from Programming with Clutter tutorial does not work [1]. Is this somehow related to this statement: It is assumed that we will have only one OpenGL drawing context, and thus a single process running in the system will be using Clutter at a time. This process will be the window manager and the implementor of all challenging graphical UI effects on the screen. [2] What is the trick to get a working Clutter stage in Fremantle application? BR, Henrik [1] http://www.openismus.com/documents/clutter_tutorial/0.8/docs/tutorial/html/sec-stage.html#sec-stage-basics [2] http://maemo.org/development/sdks/maemo5_alpha_overview/ -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Clutter in Fremantle (Alpha SDK)
ext Henrik Hedberg wrote: Hi, How is Clutter supposed to work in applications in Fremantle? Will the Clutter-GTK library be included in the final SDK? I have tried to run a Clutter application that works in desktop environment. It compiles fine, but nothing happens when starting it in the Alpha SDK. Also, even the simplest example application from Programming with Clutter tutorial does not work [1]. Is this somehow related to this statement: It is assumed that we will have only one OpenGL drawing context, and thus a single process running in the system will be using Clutter at a time. This process will be the window manager and the implementor of all challenging graphical UI effects on the screen. [2] I have tried and got both native OpenGL-ES2.0 applications and Qt4.5 OpenGL-ES2.0 applications working together with Hildon desktop composite window manager. I tried same thing with clutter but there is some issue with it. I have not yet had time to investigate more, i just returned from my Bossa conference trip. We are here considering to set up wiki pages avbout how to use 3d acceleration in Fremantle and collect there instructions needed to get it running. Kate What is the trick to get a working Clutter stage in Fremantle application? BR, Henrik [1] http://www.openismus.com/documents/clutter_tutorial/0.8/docs/tutorial/html/sec-stage.html#sec-stage-basics [2] http://maemo.org/development/sdks/maemo5_alpha_overview/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Clutter in Fremantle (Alpha SDK)
Till Harbaum wrote 17.03.2009 13:38: Am Dienstag 17 März 2009 schrieb Henrik Hedberg: How is Clutter supposed to work in applications in Fremantle? Will the Clutter-GTK library be included in the final SDK? I have tried to check the clutter-gtk libs into the fremantle extras-devel but this failed due to some problems in the sdk, see: https://bugs.maemo.org/show_bug.cgi?id=4197 I have been able to compile it locally and to run the demo application that comes with clutter-gtk. I compiled the Clutter-GTK, and it really worked! So, the trick is documented somewhere in the gtk-clutter-embed.c source file. :) Thank you for the hint. However, I think that the Clutter-GTK should be included in the official SDK. Could someone from Maemo Software comment on this? Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Clutter in Fremantle (Alpha SDK)
ext Henrik Hedberg wrote: However, I think that the Clutter-GTK should be included in the official SDK. Could someone from Maemo Software comment on this? Yes, it needs to be. Hopefully in the beta SDK will be there. A reason for the delay has been that we are aiming to have Clutter 1.0 in the final release. Before integrating that version it was not critical to have the clutter-gtk bindings in the SDK. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Clutter in Fremantle (Alpha SDK)
Quim Gil wrote 17.03.2009 14:29: A reason for the delay has been that we are aiming to have Clutter 1.0 in the final release. Before integrating that version it was not critical to have the clutter-gtk bindings in the SDK. Thank you for this very important information. It should be noted that Clutter 1.0 is not API compatible with Clutter 0.8. All developers interested in Clutter should look at the Clutter 0.9, which is the development branch leading towards the Clutter 1.0. http://www.clutter-project.org/blog/?p=66 http://www.clutter-project.org/docs/clutter/0.9/ Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Clutter in Fremantle (Alpha SDK)
Hi, but there's no clutter-gtk for clutter-0.9 yet. Till Am Dienstag 17 März 2009 schrieb Henrik Hedberg: Quim Gil wrote 17.03.2009 14:29: A reason for the delay has been that we are aiming to have Clutter 1.0 in the final release. Before integrating that version it was not critical to have the clutter-gtk bindings in the SDK. Thank you for this very important information. It should be noted that Clutter 1.0 is not API compatible with Clutter 0.8. All developers interested in Clutter should look at the Clutter 0.9, which is the development branch leading towards the Clutter 1.0. http://www.clutter-project.org/blog/?p=66 http://www.clutter-project.org/docs/clutter/0.9/ Henrik ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Clutter in Fremantle (Alpha SDK)
Gary: I, too, am trying to get my OpenGL ES 2.0 application to work nicely within the Maemo environment. I'm currently testing by killing off the window manager and other related stuff - back to the old X11 wallpaper pattern, then running my app. Works fine, as it goes. I knew I'd have to come up with a solution one day, but since the conversation on this list recently (below), I thought I'd take this opportunity to probe a little deeper. I'm getting round this by designing my framework to allow both standalone unshared instances to be run (multiple XV overlays are allowed) and I have also put the core principles in place for dynamically loading shared application widgets into the playground. Fact is, I don't understand this, and was hoping you'd elaborate... =0) -- Does anyone else on the list know the Official Maemo Way to develop OpenGL ES 2.0 applications? My approach is that I just run the PowerVR SDK in the X86 mode. I notice that the lib/.h files have now arrived for cross-compiling to ARM. By the way, it's amazing how many levels and layers you can go through. In case anyone else is put off trying it: I run in X86 SDK mode to the PVR ES 2.0 emulation lib, which presumably uses the X86 SDK's GL libraries and then goes to the Xephyr X11 app. This then runs into my Ubuntu's X11, which is created by VMWare inside Windows XP inside a laptop with Intel Graphics chips. (So I'm not expecting great performance! But it works fine for testing. =0) I get direct rendering: Yes from glxinfo inside my VMWare guest, so there's a slight chance that there is some acceleration going on somewhere in the pipes... Anyone else got experiences to report? Perhaps we should start a wiki page somewhere to give the official instructions for GL app devs, and to document successes and failures like this? Cheers! Duncan Cragg -- *Q:* /What's The Killer App for Mobile 2.0?/ *A:* See http://the-u-web.org Subject: Re: Clutter in Fremantle (Alpha SDK) From: gary liquid liq...@gmail.com Date: Tue, 17 Mar 2009 09:28:34 + To: Henrik Hedberg henrik.hedb...@innologies.fi CC: maemo-developers@maemo.org Hendrik, I assume that to use clutter in your application is to somehow get the window manager to shutdown the opengl context and then open yours for the duration before once again reopening the window manager. A somewhat challenging prospect! Whilst its possible to use x11 compositing to bring in a gtk or qt window, I assume there is no extension to composite an opengl window itself. And since its difficult to allow sharing of data between applications this is not something that could be fixed elegently. really makes you appreciate the underlying beauty of x11 :) I'm getting round this by designing my framework to allow both standalone unshared instances to be run (multiple XV overlays are allowed) and I have also put the core principles in place for dynamically loading shared application widgets into the playground. It should be as simple as a change in the makefile to switch a properly designed application between standalone or shared :) gary On Tue, Mar 17, 2009 at 7:37 AM, Henrik Hedberg henrik.hedb...@innologies.fi mailto:henrik.hedb...@innologies.fi wrote: Hi, How is Clutter supposed to work in applications in Fremantle? Will the Clutter-GTK library be included in the final SDK? I have tried to run a Clutter application that works in desktop environment. It compiles fine, but nothing happens when starting it in the Alpha SDK. Also, even the simplest example application from Programming with Clutter tutorial does not work [1]. Is this somehow related to this statement: It is assumed that we will have only one OpenGL drawing context, and thus a single process running in the system will be using Clutter at a time. This process will be the window manager and the implementor of all challenging graphical UI effects on the screen. [2] What is the trick to get a working Clutter stage in Fremantle application? BR, Henrik [1] http://www.openismus.com/documents/clutter_tutorial/0.8/docs/tutorial/html/sec-stage.html#sec-stage-basics [2] http://maemo.org/development/sdks/maemo5_alpha_overview/ -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Clutter in Fremantle (Alpha SDK)
:) Duncan, its harder to explain than to do and I only know about this stuff in relation to liqbase (which has a number of parallels to the way clutter has been constructed and diverges in others). to show you properly I would have to release my code and its not ready just yet. You will have to readup on dynamic linking and see whats available to you. I had planned to get the first iteration out the door by now so that me and the patient beta guys could get hammering away at solidifying it and creating the apps we have discussed but with a full dayjob and family I don't get nowhere near enough time to work on it as I would like :) gary 2009/3/17 Duncan Cragg m...@cilux.org Gary: I, too, am trying to get my OpenGL ES 2.0 application to work nicely within the Maemo environment. I'm currently testing by killing off the window manager and other related stuff - back to the old X11 wallpaper pattern, then running my app. Works fine, as it goes. I knew I'd have to come up with a solution one day, but since the conversation on this list recently (below), I thought I'd take this opportunity to probe a little deeper. I'm getting round this by designing my framework to allow both standalone unshared instances to be run (multiple XV overlays are allowed) and I have also put the core principles in place for dynamically loading shared application widgets into the playground. Fact is, I don't understand this, and was hoping you'd elaborate... =0) -- Does anyone else on the list know the Official Maemo Way to develop OpenGL ES 2.0 applications? My approach is that I just run the PowerVR SDK in the X86 mode. I notice that the lib/.h files have now arrived for cross-compiling to ARM. By the way, it's amazing how many levels and layers you can go through. In case anyone else is put off trying it: I run in X86 SDK mode to the PVR ES 2.0 emulation lib, which presumably uses the X86 SDK's GL libraries and then goes to the Xephyr X11 app. This then runs into my Ubuntu's X11, which is created by VMWare inside Windows XP inside a laptop with Intel Graphics chips. (So I'm not expecting great performance! But it works fine for testing. =0) I get direct rendering: Yes from glxinfo inside my VMWare guest, so there's a slight chance that there is some acceleration going on somewhere in the pipes... Anyone else got experiences to report? Perhaps we should start a wiki page somewhere to give the official instructions for GL app devs, and to document successes and failures like this? Cheers! Duncan Cragg -- *Q:* *What's The Killer App for Mobile 2.0?* *A:* See http://the-u-web.org Subject: Re: Clutter in Fremantle (Alpha SDK) From: gary liquid liq...@gmail.com liq...@gmail.com Date: Tue, 17 Mar 2009 09:28:34 +To: Henrik Hedberg henrik.hedb...@innologies.fihenrik.hedb...@innologies.fi CC: maemo-developers@maemo.org Hendrik, I assume that to use clutter in your application is to somehow get the window manager to shutdown the opengl context and then open yours for the duration before once again reopening the window manager. A somewhat challenging prospect! Whilst its possible to use x11 compositing to bring in a gtk or qt window, I assume there is no extension to composite an opengl window itself. And since its difficult to allow sharing of data between applications this is not something that could be fixed elegently. really makes you appreciate the underlying beauty of x11 :) I'm getting round this by designing my framework to allow both standalone unshared instances to be run (multiple XV overlays are allowed) and I have also put the core principles in place for dynamically loading shared application widgets into the playground. It should be as simple as a change in the makefile to switch a properly designed application between standalone or shared :) gary On Tue, Mar 17, 2009 at 7:37 AM, Henrik Hedberg henrik.hedb...@innologies.fi wrote: Hi, How is Clutter supposed to work in applications in Fremantle? Will the Clutter-GTK library be included in the final SDK? I have tried to run a Clutter application that works in desktop environment. It compiles fine, but nothing happens when starting it in the Alpha SDK. Also, even the simplest example application from Programming with Clutter tutorial does not work [1]. Is this somehow related to this statement: It is assumed that we will have only one OpenGL drawing context, and thus a single process running in the system will be using Clutter at a time. This process will be the window manager and the implementor of all challenging graphical UI effects on the screen. [2] What is the trick to get a working Clutter stage in Fremantle application? BR, Henrik [1] http://www.openismus.com/documents/clutter_tutorial/0.8/docs/tutorial/html/sec-stage.html#sec-stage-basics [2] http://maemo.org/development/sdks
Re: Clutter in Fremantle (Alpha SDK)
Duncan, one more thing (slightly less publicly oriented), doesn't something feel OTT with the development process? I came to linux because I knew I might need to touch the metal (prior to this I've coded in .net compact...), you have so many things in the way its hard to know whats real and whats not. simplicity is the key, I compile directly on my n810 and run with direct hardware and no emulation or vmware or scratchbox or anything and testing is live and I touch my code and its such a liberating feeling! I get better performance on my n810 than I see and hear people getting on other more capable platforms :) My framework is very simplistic compared to clutter, but will allow me to build my kind of applications. For now it is so immature, but if you take a look here: http://www.youtube.com/watch?v=iMXp0Dg_UaY (and at my other videos) you will see I have broken all the rules but for the right reasons :) its coming along nicely and I've taken the lessons I learnt with my monolithic app (which was half a framework internally anyway) and am expanding it to cater for outside development. Its a little seed that is built from the kind of goodness I expected my handheld to have and will continue to evolve with time and energy gary 2009/3/17 Duncan Cragg m...@cilux.org Gary: I, too, am trying to get my OpenGL ES 2.0 application to work nicely within the Maemo environment. I'm currently testing by killing off the window manager and other related stuff - back to the old X11 wallpaper pattern, then running my app. Works fine, as it goes. I knew I'd have to come up with a solution one day, but since the conversation on this list recently (below), I thought I'd take this opportunity to probe a little deeper. I'm getting round this by designing my framework to allow both standalone unshared instances to be run (multiple XV overlays are allowed) and I have also put the core principles in place for dynamically loading shared application widgets into the playground. Fact is, I don't understand this, and was hoping you'd elaborate... =0) -- Does anyone else on the list know the Official Maemo Way to develop OpenGL ES 2.0 applications? My approach is that I just run the PowerVR SDK in the X86 mode. I notice that the lib/.h files have now arrived for cross-compiling to ARM. By the way, it's amazing how many levels and layers you can go through. In case anyone else is put off trying it: I run in X86 SDK mode to the PVR ES 2.0 emulation lib, which presumably uses the X86 SDK's GL libraries and then goes to the Xephyr X11 app. This then runs into my Ubuntu's X11, which is created by VMWare inside Windows XP inside a laptop with Intel Graphics chips. (So I'm not expecting great performance! But it works fine for testing. =0) I get direct rendering: Yes from glxinfo inside my VMWare guest, so there's a slight chance that there is some acceleration going on somewhere in the pipes... Anyone else got experiences to report? Perhaps we should start a wiki page somewhere to give the official instructions for GL app devs, and to document successes and failures like this? Cheers! Duncan Cragg -- *Q:* *What's The Killer App for Mobile 2.0?* *A:* See http://the-u-web.org Subject: Re: Clutter in Fremantle (Alpha SDK) From: gary liquid liq...@gmail.com liq...@gmail.com Date: Tue, 17 Mar 2009 09:28:34 +To: Henrik Hedberg henrik.hedb...@innologies.fihenrik.hedb...@innologies.fi CC: maemo-developers@maemo.org Hendrik, I assume that to use clutter in your application is to somehow get the window manager to shutdown the opengl context and then open yours for the duration before once again reopening the window manager. A somewhat challenging prospect! Whilst its possible to use x11 compositing to bring in a gtk or qt window, I assume there is no extension to composite an opengl window itself. And since its difficult to allow sharing of data between applications this is not something that could be fixed elegently. really makes you appreciate the underlying beauty of x11 :) I'm getting round this by designing my framework to allow both standalone unshared instances to be run (multiple XV overlays are allowed) and I have also put the core principles in place for dynamically loading shared application widgets into the playground. It should be as simple as a change in the makefile to switch a properly designed application between standalone or shared :) gary On Tue, Mar 17, 2009 at 7:37 AM, Henrik Hedberg henrik.hedb...@innologies.fi wrote: Hi, How is Clutter supposed to work in applications in Fremantle? Will the Clutter-GTK library be included in the final SDK? I have tried to run a Clutter application that works in desktop environment. It compiles fine, but nothing happens when starting it in the Alpha SDK. Also, even the simplest example application from Programming with Clutter tutorial
Re: Clutter in Fremantle (Alpha SDK)
On Tue, 2009-03-17 at 08:37 +0100, ext Henrik Hedberg wrote: Hi, Hi, How is Clutter supposed to work in applications in Fremantle? Will the Clutter-GTK library be included in the final SDK? I have tried to run a Clutter application that works in desktop environment. It compiles fine, but nothing happens when starting it in the Alpha SDK. Also, even the simplest example application from Programming with Clutter tutorial does not work [1]. Is this somehow related to this statement: It is assumed that we will have only one OpenGL drawing context, and thus a single process running in the system will be using Clutter at a time. This process will be the window manager and the implementor of all challenging graphical UI effects on the screen. [2] This we have assumed in the design, but it does not mean that multi- context does not work. As Kate has already proven, multi-context works. But as long as you have hildon-desktop running in the background, you will not render directly to the screen even if you use Clutter/QtGraphicsView/EGL+OpenGLES2.0/whatnot in your application. When hildon-desktop is running, it is the only one drawing on the screen (with the exception of XVideo). So, killing hildon-desktop is the only way to get direct rendering to the screen at the moment. (We might have something more elegant for this in the future...) What is the trick to get a working Clutter stage in Fremantle application? I don't know yet, I haven't had the time to play with it... BR; Kimmo BR, Henrik [1] http://www.openismus.com/documents/clutter_tutorial/0.8/docs/tutorial/html/sec-stage.html#sec-stage-basics [2] http://maemo.org/development/sdks/maemo5_alpha_overview/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Clutter in Fremantle (Alpha SDK)
gary liquid wrote: I touch my code and its such a liberating feeling! Oh, too much information Gary ;) gary Regards, Jamie -- http://www.linuxuk.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Clutter in Fremantle (Alpha SDK)
Kimmo Hämäläinen wrote: On Tue, 2009-03-17 at 08:37 +0100, ext Henrik Hedberg wrote: Is this somehow related to this statement: It is assumed that we will have only one OpenGL drawing context, and thus a single process running in the system will be using Clutter at a time. This process will be the window manager and the implementor of all challenging graphical UI effects on the screen. [2] This we have assumed in the design, but it does not mean that multi- context does not work. As Kate has already proven, multi-context works. But as long as you have hildon-desktop running in the background, you will not render directly to the screen even if you use Clutter/QtGraphicsView/EGL+OpenGLES2.0/whatnot in your application. When hildon-desktop is running, it is the only one drawing on the screen (with the exception of XVideo). So, killing hildon-desktop is the only way to get direct rendering to the screen at the moment. (We might have something more elegant for this in the future...) Could you clarify what does this mean in practice? Is the performance of 3D rendering significantly slower in applications, for example? I suppose that even if off-screen rendering is used it is still hardware accelerated. Thus, compositing in window manager level should not be a big issue, and we can live with that (for now) if everything just work fast enough. Who needs direct rendering anyway. :) BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
