On 10/30/2015 07:24 AM, jose@xxxxxxxxx wrote: >> Wow! That is astonishing, and well done, congratulations. >> >> >> I've played with it a bit; I had some issues with keyboard problems, and >> it wasn't immediately obvious how to use passwords or ssl. Of course, I >> suspect those are issues that are relatively easy to address. >> > Keyboard support is one of the most advanced and developed part of the > spice web client. By default it is using spanish keyboard, maybe this is > the reason you experienced keyboard issues? Editing run.js and switching layout to 'us' got me my precious '/' key <grin>. Beyond that, though, there seem to be some issues with stuck key states. For example, typing ^U (as I do all too frequently), gets me the source and then a stream of u's. I'm also readily able to get the keyboard in a stuck state, where I can't type. (Haven't worked it out yet; some combination of clicking and typing does it every time, though). Again, I suspect that will be easy to figure out and correct. [snip] > There are three reasons why it is faster. The first one is because of > the image handling optimization. The second one is because it works with > qxl activated. The third one is because of the graphical pipeline with > almost zero copy. For example, in the queue for the receiving socket, if > look at it (socketqueue.js, inside network) there a shadow copy > implemented in javascript to avoid copy and gc work. I'm curious about the details, but may have to wait until I get some time to dig in and look carefully for myself. > > > Wow, thats very interesting. With a linux client using the last chromium > connecting to a remote windows guest the performance of video is way > better with spice web client than with spice-html5. Maybe you have > optimized more for Xspice? We have stil not tested Xspice, neither > optimized for it. Yeah, I focus on only on Xspice. The key feature I added was stream reports, which kicks in some of the rate control logic in spice, which then, in turn, really helps smooth playback. The related patches are here: http://lists.freedesktop.org/archives/spice-devel/2015-June/020123.html (although I now realize, with some embarrassment, that despite ACKs, I never pushed. Partly because I was considering redoing them to do the reports at a later trigger time.) This thread about video performance may also be of interest to you; it sure would be great to collaborate with you on the subject: http://lists.freedesktop.org/archives/spice-devel/2015-June/020147.html And while I'm linking interesting work, I hope you will eventually really come to like this patch <grin>: http://lists.freedesktop.org/archives/spice-devel/2015-October/022960.html > > I don't remember how spice-html5 handles video frames, we do it by using > createObjectUrl to not having to encode the jpeg blob with urlencode, > this increased the video performance a lot. Mmm. I do it with an Image and a data blob; I recall it being quite fast. But you may be taking better advantage of recent improvements in html5; spice-html5 is largely set at 2012 vintage html5; things were really pretty shaky back then. (Well, okay, shakier; I wouldn't claim that things are necessarily robust right now <grin>). [helpful history snipped] > I hope this clarified a bit our intentions and position, i know this has > been done a bit late :) Thanks for the explanation, and thanks for being here now! I think Daniel expressed the licensing concerns well; I'll let you respond in that thread, and presume we can work that out. >From a technical perspective, the most straight forward path would seem to be to deprecate the current spice-html5 and use your implementation as a replacement. I don't see any clean way to merge either work into the other. Your code appears to be more developed, and does have some nice features the current implementation lacks (e.g. better name space handling, unit tests). That's somewhat painful for me to contemplate; as you know, it's a lot of fun to write an html5 spice client <grin>. I'll try to free up some time to look at your work in more detail next week; perhaps I can try adopting your code and see how the process feels and form a stronger opinion with more in depth knowledge. If others lurking have an opinion, or advice, I think that would be welcome; Jose and I are pretty much the definition of biased parties. Cheers, Jeremy _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel