[Development] Question on QWS/QPA

[Samuel Rødal]

On 12/06/2012 08:00 PM, Arunprasad Rajkumar wrote:
> Hello Developers,
>
> I'm new to QT. Basically I understood like QWS/QPA reduces porting QT to
> custom embedded devices without touching the core functionality of
> QtGui. Also it is a architectural split down of functionality and
> porting layer. QWS is a legacy model & have some limitation, so we can't
> fully utilize the OpenGL ES-2.0 greater advantages, so QPA born to
> solve. QPA also remove the Windowing Server code, so again it is upto
> the gfx platform to have window server,...
>
> Coming to the picture, :)
>
> We are still stick with the legacy QWS model where we implemented custom
> gfxplugins to work on our graphics stack. We would like to have
> multi-process application model, where each our QT Applications should
> be executed in different address space to address the integrity and
> stability issues. Even-though we would like to have a multi-process app
> model, our graphics hardware doesn't allow us to use it from multiple
> processes. In QWS model, the first application we are running will be
> come the Window Server, which loads the gfxplugins and uses it render on
> the screen, and next running application will become client, bringing
> client to display will be taken care by server. My question is, whether
> gfxcalls of client will be proxied over to server (or) client always
> draws into shared memory(software) and server composites on screen..?

There's no platform plugin that does proxying of rendering commands. If 
you want to have a multi-process model but don't have graphics hardware 
that supports multiple processes, pretty much the only reasonable option 
would be to do rendering into shared memory on the client side and have 
the server composite, as you suggest. QtWayland fully supports that model.

I guess it would be possible to implement a platform plugin that does 
some kind of proxying, but the question is how well it would perform. It 
would also be a lot of work to implement a proxying solution for raw 
OpenGL commands. Implementing a proxying scene graph for QtQuick 2.0 
might be possible, if you disallow or limit the use of QQuickItems using 
custom OpenGL, but there would still be a lot of work involved.

Since QtQuick 2.0 currently requires OpenGL on the client side, without 
OpenGL acceleration (or some kind of OpenGL emulation like llvmpipe, 
with its performance implications) you would pretty much be limited to 
QtWidgets and QtQuick 1.x there.

--
Samuel