<br><br><div class="gmail_quote">On Tue, Jun 2, 2009 at 3:04 PM, David Greaves <span dir="ltr"><<a href="mailto:david@dgreaves.com">david@dgreaves.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
</div>I understood that GL wasn't going to be available to the apps on the device...<br>
something about the window manager permanently taking the only viewport?<br>
<br>
I am not sure if this is a beta-phase bug or a hardware or GLES issue.<br>
<br>
David<br>
<font color="#888888">--<br>
"Don't worry, you'll be fine; I saw it work in a cartoon once..."<br>
</font></blockquote></div><br><br>I think you are referring to the following two posts, both by Kimmo Hämäläinen. I don't believe they say that GL won't be available, but that there will be a performance hit because the apps will have to go through Hildon-Desktop to render, rather than rendering directly.<br>
<br><a href="http://lists.maemo.org/pipermail/maemo-developers/2009-March/018639.html">http://lists.maemo.org/pipermail/maemo-developers/2009-March/018639.html</a><br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
As Kate has already proven, multi-context works.<br>But as long as you have hildon-desktop running in the background, you<br>will not render directly to the screen even if you use<br>Clutter/QtGraphicsView/EGL+OpenGLES2.0/whatnot in your application. When<br>
hildon-desktop is running, it is the only one drawing on the screen<br>(with the exception of XVideo). So, killing hildon-desktop is the only<br>way to get direct rendering to the screen at the moment. (We might have<br>something more elegant for this in the future...)<br>
</blockquote><br><a href="http://lists.maemo.org/pipermail/maemo-developers/2009-March/018645.html">http://lists.maemo.org/pipermail/maemo-developers/2009-March/018645.html</a><br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
Keeping the compositor around has some performance impact, because after<br>the application draws to an offscreen pixmap (the window), the X server<br>sends Damage events (saying "this part of the pixmap changed") to<br>
hildon-desktop, and hildon-desktop asks the 3D HW to use this pixmap in<br>a OpenGL texture and draw it to the screen. So, there is some extra<br>delay (maybe 10-25ms) after the application's drawing is visible. <br><br>
Second implication is that you cannot use HW accelerated zooming and<br>moving of textures for the whole graphical pipeline. You can use it for<br>drawing into your window, but when hildon-desktop draws to the screen,<br>
it cannot use it (e.g. it cannot say "move this content to there"). It<br>will just get a big damage area that is updated by updating the OpenGL<br>texture content.<br><br>Third implication: to save memory, we are using the texture-from-pixmap<br>
GL extension to allow the X server and 3D HW share the pixmap data. This<br>means that while 3D HW is accessing the pixmap data (while 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 drawing.<br>
However, it's not mandatory to use texture-from-pixmap, but then you are<br>paying the price in increased RAM usage.<br><br></blockquote><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>