[Spice-devel] Native Spice Drawing?

[Alon Levy]

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
> > [1], 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 [2] for it too, but it is not at the level I think you are talking
> > about (but perhaps will suit you).
> > 
> > [1] http://blogs.gnome.org/alexl/2011/03/15/gtk-html-backend-update/
> > [2] 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 [3], 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
  that afair.


[3] http://zrusin.blogspot.com/2010/11/2d-musings.html

> Cheers,
> 
> Lee.