On 12.12.2009, at 16:29, Izik Eidus wrote: > On Sat, 12 Dec 2009 09:13:51 -0600 > Anthony Liguori <[email protected]> wrote: > >> Izik Eidus wrote: >>> On Fri, 11 Dec 2009 21:31:34 -0600 >>> Anthony Liguori <[email protected]> wrote: >>> >>>> Okay, that's in line with what my expectations were. So what's >>>> the future of Spice for X? Anything clever or is Windows the only >>>> target right now? >>>> >>> >>> Offscreen pixmaps, Xrender, opengl 3d commands, Video extention. >>> >>> I dont understand what you want here? >>> >> >> To understand what makes Spice special. > > > Spice is interesting beacuse unlike the great VNC protocol it already > have what it take to make VDI possible to the user. > > If you think all the above features are pointless and if you think that > Windows graphic systems (90% of the world wide desktops users) is not > important, I really dont know what to tell you. > > It is easy to say about everything "We can implment it in VNC..." yes. > and I can write my own new operation system and tell everyone "Haa, > right now i dont have it, but it is easy to implement"... > > It is naive to think that software is all about features..., In this > case Linux / Freebsd are the same thing..., ohh wait they are diffrent > no?. > > Wait, I think Google, Yahoo and Bing, does`nt they all have the same > features????, How come ppl still prefer to use Google in that case? > > VNC is much older than spice, but still why it didnt get all this SPICE > protocol goodies? why? (I mean it is so easy to add this into VNC...)
I think you're getting the wrong message. Let me tell you something about my work on virtio-fb. I did 2 versions. The first one was completely ring and message based. I used the virtio ring topology to send framebuffer updates along to the hypervisor, basically resembling the linux fb callback interface. While that worked, it was _horribly_ slow. I didn't know why. Until I found out that all of this transferring happens synchronously! So on every linuxfb function call we basically got a hypervisor exit, resulting in a lot of overhead. Not to speak of all the vmalloc magic I had to do. If I had known before that this is a bottleneck, I would have designed the protocol differently. In fact, I did for v2 - and ended up having only a single real command in my awesome protocol: "mark dirty". So I ended up basically reimplementing the same framebuffer based interface we use in qemu already. Oh great. If anybody would have been around to tell me that what I'm doing is a bad idea because he went through it before, or if I had simply known before, I wouldn't have made those mistakes. It's all about knowledge. Another example. I'm always having a hard time understanding why VNC is slow. I've seriously always been wondering. And I'm still puzzled as to why RDP is so much superior performance-wise. After all, it basically only implements framebuffer updates too. So now you bring in SPICE to that equation. I don't know _why_ SPICE is faster. I know that it is and I hear all those awesome great features. But I still don't have a feeling on which part of it really is the performance booster. As with the example above, I would never have guessed that doing synchronous updates is the performance killer. I'm still trying to figure out what is going wrong in VNC :-). So don't take this as an offense. It's about learning from you guys. You're the ones that measured what makes things fast - and we want to know! Even if we're not building code on it, but using SPICE, it'd still be very valuable to know why exactly it is performing better. And best case also by how much each single feature saves us. Alex PS: Let me explain my background on those questions: I'm stuck with VNC for SUSE Studio for now. While I can't make fundamental changes to the protocol, I can easily modify the guest and I can also easily modify the VNC viewer to add a few new commands. If I can get a throughput reduction of 50% by using 2 out of 10 features SPICE has as VNC protocol extensions, I'd gladly implement them. That'd just make user experience on our side a lot better. If that means using QXL inside the guest, so be it :-).
