[Development] Question on QWS/QPA

[Arunprasad Rajkumar]

Hi Samuel,

Thanks for your reply. We would like to have only QtWebKit widget and not
going to use QtQuick at this moment. So by default QPA/QWS client will
render widgets on shared memory allocated via Qt and draws on it. Once done
it request the QPA/QWS server to do the composition of widgets. Am I right?

As I mentioned, I would like to proxy the rendering calls(not all, only few
like blit/fill) to server. Is there anyway to differentiate Server & Client
process in gfxplugin? Some Qt QWS documents
<http://doc.qt.digia.com/qt/qt-embedded-accel.html>says like,

"The connect() <http://doc.qt.digia.com/qt/qscreen.html#connect> and
disconnect() <http://doc.qt.digia.com/qt/qscreen.html#disconnect> are
called by both the server and client processes, while the
initDevice()<http://doc.qt.digia.com/qt/qscreen.html#initDevice>
 and shutdownDevice()<http://doc.qt.digia.com/qt/qscreen.html#shutdownDevice>
functions
are only called by the server process."

Once I differentiate it, then I can proxy the rendering calls.

Kind Regards,
Arun.

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

-- 
*Arunprasad Rajkumar*
http://in.linkedin.com/in/ararunprasad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121211/990e5d73/attachment.html>