[Spice-devel] Native Spice Drawing?
alevy at redhat.com
Sun Apr 1 05:19:03 PDT 2012
On Sun, Apr 01, 2012 at 12:27:13PM +0100, Lee Essen wrote:
> On 30 Mar 2012, at 22:16, Alon Levy wrote:
> > On Fri, Mar 30, 2012 at 05:12:26PM +0100, Lee Essen wrote:
> >> Hi,
> >> I'm relatively new to spice, and am using it very effectively with qemu, however it strikes me that there is potential to use it as a standalone embedded server for applications who only have a remote display requirement. The obvious candidate is probably some kind of broker, but I'm sure there are many other examples.
> >> Has anyone considered this? Am I missing the point? (which wouldn't be the first time!)
> >> If the "primitives" are relatively easy to get at, then surely it wouldn't be such a tough challenge to build something like an SDL layer for it?
> > Are you talking about using Spice as a sort of graphics toolkit? I don't
> > think that's impossible, but I think the right approach here would be to
> > write something like a gtk/qt backend (for gtk there is already broadway
> > , so yet another backend, but this time using spice).
> Yes, exactly. That's why I suggested an SDL layer (backend is probably a better word), but I guess gtk would also be ok -- or even just a simple set of primitives for basic stuff.
> I hadn't heard of broadway … very nice, the principle is exactly the same.
> > If you want to remote an application without a vm you can already use
> > Xspice  for it too, but it is not at the level I think you are talking
> > about (but perhaps will suit you).
> >  http://blogs.gnome.org/alexl/2011/03/15/gtk-html-backend-update/
> >  http://spice-space.org/download.html#Xspice
> My main thought is around some kind of spice broker, you could probably build it pretty easily into the front-end, but I can't help thinking it would be nice to be able to have the client not care about this and just present it through the normal spice mechanisms - that way any client would work.
> I can't easily see where to attempt to plug-in ... the code seems pretty determined to have the QXL interface in there, so does it make sense to pretend to be the qxl driver? Or is there any easier place?
What would inventing another toolkit achieve? If a toolkit was to be
invented I think it should be a scene graph based one, something like what Zack
Rustin suggested in a blog post once , but the current level that qxl
handles is way lower then that. It could be done in the spice protocol
but would probably require a display channel v2.
That said, you could of course pretend to be qxl and write a library on
top of that, that would then be used by gui applications, or as a
backend to gtk/qt and thus support all existing gtk/qt applications. SDL
- Why do you treat it as a graphics toolkit? it is much lower level then
More information about the Spice-devel