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
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
