On 03/09/2011 08:48 PM, ext Bill Spitzak wrote:
Samuel Rødal wrote:
On 03/06/2011 08:41 PM, ext Bill Spitzak wrote:
I think the original poster's idea is exactly what is needed:
I the compositor crashes or exits, the clients will detect this. It is
then the client's job to find a new compositor and recreate their
state on the new one. Most toolkits store quite enough redundant
information that they should be able to do this, I would suspect the
biggest trick will be to completely forget any ids from the previous
compositor.
Most OpenGL applications are written expecting that GPU resources do not
suddenly disappear, so I don't know how feasible this would be for an
application that uses raw OpenGL. If the application is written against
Qt (the toolkit I'm familiar with), it would probably be possible to
handle it, unless the application uses Qt's OpenGL abstraction classes,
which are basically just thin wrappers above OpenGL functionality
(QGLFramebufferObject, QGLShaderProgram, etc).
Under Wayland the compositor is not running the OpenGL that a client
uses. The client is running their own instance to draw into the images
that are sent to the compositor. Imagine the client was linked with the
Mesa library and running on a system that otherwise had zero
implementation of OpenGL. All clients are work something like that.
Hardware acceleration is done by the OpenGL library figuring out what
hardware is available to draw the images and using it. Kind of like how
programs could use floating point coprocessors without talking to a
"floating point server".
So no resources disappear.
Right? Or am I misunderstanding how Wayland is intended to work?
The Mesa library has a software implementation of OpenGL, but I don't
think it supports dynamically switching between the software and
hardware implementations at runtime?
--
Samuel
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
