That's quite disappointing. <br><br>I'm looking forward to seeing further news about "game mode," I guess.<br><br><div class="gmail_quote">2009/6/2 Kimmo Hämäläinen <span dir="ltr"><<a href="mailto:kimmo.hamalainen@nokia.com">kimmo.hamalainen@nokia.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>
<div class="im"><br>
On Wed, 2009-06-03 at 00:53 +0200, ext Qole wrote:<br>
><br>
><br>
> On Tue, Jun 2, 2009 at 3:04 PM, David Greaves <<a href="mailto:david@dgreaves.com">david@dgreaves.com</a>><br>
> wrote:<br>
><br>
><br>
> I understood that GL wasn't going to be available to the apps<br>
> on the device...<br>
> something about the window manager permanently taking the only<br>
> viewport?<br>
><br>
> I am not sure if this is a beta-phase bug or a hardware or<br>
> GLES issue.<br>
><br>
> David<br>
> --<br>
> "Don't worry, you'll be fine; I saw it work in a cartoon<br>
> once..."<br>
><br>
><br>
> I think you are referring to the following two posts, both by Kimmo<br>
> Hämäläinen. I don't believe they say that GL won't be available, but<br>
> that there will be a performance hit<br>
<br>
</div>OpenGL is not available in the device but OpenGL ES2 is. Notice that<br>
this is a big problem when porting OpenGL applications from the desktop<br>
PC world. Some kind of OpenGL to OpenGLES conversion layers are<br>
possible but with some FPS cost, I assume.<br>
<div class="im"><br>
> because the apps will have to go through Hildon-Desktop to render,<br>
> rather than rendering directly.<br>
<br>
</div>Yes, about 30% penalty with the compositor, but I'm working on "non-<br>
composited" or "game mode" for hildon-desktop that allows shutting down<br>
the compositor and rendering directly to the screen (without killing<br>
hildon-desktop). I still need to get it working with dialogs and menus<br>
popping on top of the non-composited application, but I guess it'll work<br>
in the end somehow.<br>
<br>
BR; Kimmo<br>
<div><div></div><div class="h5"><br>
><br>
> <a href="http://lists.maemo.org/pipermail/maemo-developers/2009-" target="_blank">http://lists.maemo.org/pipermail/maemo-developers/2009-</a><br>
> March/018639.html<br>
><br>
> As Kate has already proven, multi-context works.<br>
> But as long as you have hildon-desktop running in the<br>
> background, you<br>
> will not render directly to the screen even if you use<br>
> Clutter/QtGraphicsView/EGL+OpenGLES2.0/whatnot in your<br>
> application. When<br>
> hildon-desktop is running, it is the only one drawing on the<br>
> screen<br>
> (with the exception of XVideo). So, killing hildon-desktop is<br>
> the only<br>
> way to get direct rendering to the screen at the moment. (We<br>
> might have<br>
> something more elegant for this in the future...)<br>
><br>
> <a href="http://lists.maemo.org/pipermail/maemo-developers/2009-" target="_blank">http://lists.maemo.org/pipermail/maemo-developers/2009-</a><br>
> March/018645.html<br>
><br>
> Keeping the compositor around has some performance impact,<br>
> because after<br>
> the application draws to an offscreen pixmap (the window), the<br>
> X server<br>
> sends Damage events (saying "this part of the pixmap changed")<br>
> to<br>
> hildon-desktop, and hildon-desktop asks the 3D HW to use this<br>
> pixmap in<br>
> a OpenGL texture and draw it to the screen. So, there is some<br>
> extra<br>
> delay (maybe 10-25ms) after the application's drawing is<br>
> visible.<br>
><br>
> Second implication is that you cannot use HW accelerated<br>
> zooming and<br>
> moving of textures for the whole graphical pipeline. You can<br>
> use it for<br>
> drawing into your window, but when hildon-desktop draws to the<br>
> screen,<br>
> it cannot use it (e.g. it cannot say "move this content to<br>
> there"). It<br>
> will just get a big damage area that is updated by updating<br>
> the OpenGL<br>
> texture content.<br>
><br>
> Third implication: to save memory, we are using the texture-<br>
> from-pixmap<br>
> GL extension to allow the X server and 3D HW share the pixmap<br>
> data. This<br>
> means that while 3D HW is accessing the pixmap data (while<br>
> transferring<br>
> it to the 3D chip), X server cannot access it. Thus, while the<br>
> compositor is updating the screen, it is slowing down X<br>
> drawing.<br>
> However, it's not mandatory to use texture-from-pixmap, but<br>
> then you are<br>
> paying the price in increased RAM usage.<br>
><br>
><br>
><br>
><br>
> --<br>
> enthusiast, n. "One whose mind is wholly possessed and heated by what<br>
> engages it; one who is influenced by a peculiar fervor of mind; an<br>
> ardent and imaginative person."<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>enthusiast, n. "One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person."<br>