Creating a new QWS screen driver with OpenGL support



  • Hi,

    I apologize in advance since I'm sure this question has been asked before but I wasn't able to find anything relevant after searching for various combinations of QWS and OpenGL so here I am.

    I'm working with Qt on an embedded linux based platform that includes an OpenGL ES 2.0 capable GPU and my current task is to enable accelerated rendering of all Qt content using OpenGL. I know it's possible to enable the OpenGL graphics system with a simple command line switch on many platforms but based on my reading of the documentation it seems that this is not the case for embedded linux (and specifically QWS). Even though OpenGL + QWS doesn't seem to work right out of the box, the documentation also says that one can add a new screen driver for a new EGL / OpenGL driver in order to achieve OpenGL rendering support on a platform.

    Using the powervr example plugin as a starting point I've started working on a driver for my platform based on the following plan:

    1. I've created my own screen and window surface classes that are derived from QGLScreen and QWSGLWindowSurface respectively.

    2. My window surface class creates a QGLFramebufferObject to use as the paint device for each window and adjusts its size accordingly based on the window dimensions.

    3. In my screen class's exposeRegion method I get the texture id from each window surface's frame buffer object and composite the windows on the screen by drawing a series of textured quads*.

    • I know this will not work when using multiple client apps since it will require sharing of GL resources across processes but for now I'm not concerned with this.

    I've had some success with this strategy but unfortunately I've also hit a few very frustrating obstacles. For some reason, no matter what I do, the widgets that have been drawn into a window's frame buffer object are typically always corrupted in some way. For example, if I create a simple window with a single pushbutton widget, all the pieces of the button will be drawn but they are usually not in the right place or at the right orientation when I display the FBO. Also, it seems that the OpenGL2 paint engine is having problems with masking / clipping since the window decorations will often overdraw the window contents.

    It's worth noting that my first attempt at this used the original OpenGL paint engine (not OpenGL2) and QGLPixelbufferObjects instead of FBOs as the backing store for each window surface and this worked without these corruption problems. Unfortunately the performance was unacceptable and it had to be abandoned in favor of the OpenGL2 paint engine which is supposed to be the higher performance solution.

    I guess my questions are:

    1. Has anyone had any success with this sort of solution before, ie using FBOs as the paint device for a custom window surface class?

    2. Is it even possible to accelerate rendering of Qt widgets with OpenGL on a QWS based platform or are there fundamental issues that will cause this to fail? Again, I know this does not work "out of the box" but should it be possible to get it working using a custom screen driver and a reasonable amount of effort?

    Thanks in advance for any information you can provide.

    -Thayer



  • Hi , I have also the exactly same issue what you are facing.

    Have you got any solution to it ?



  • Hi,
    I was looking at the same problem, found this the following article.
    http://labs.qt.nokia.com/2010/08/05/hitching-qtembedded-to-a-framebuffer-opengl-es-2-abstraction/
    It seems that accelerated rendering of QWS is possible and easy when using a PowerVR chipset (TI OMAP), and if you use any other chipset (EGL implementation) you have to do some work (the article suggest where to start from)



  • I have tried to use simplegl driver to render on QGLWidget using opengl-es2 but rendering was not correct.

    I also found that QT is initially failing in setting up EGL configurations als which I have fixed.
    Is this problem faced by anybody ?


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.