Questions about experimental Spice compositor rebase

[Fabio Fantoni]

Il 09/03/2016 20:32, Yury Shvedov ha scritto:
> Hi, Fabio! Sorry for long silence.
> Kind regards
> Yury Shvedov
> On 03/07/2016 12:12 AM, Fabio Fantoni wrote:
>> Il 06/03/2016 13:25, Yury Shvedov ha scritto:
>>> Hi, Fabio!
>>> I made 3 new commits. First one updates code to work with new Spice 
>>> API. Here, as I think, must be Spice version check if for example in 
>>> Debian 8 it less than 0.11.
>>
>> Debian 8 have spice-server 0.12.5, debian 7 with backports have 
>> 0.12.4, in any case is good added a check in configure for minimum 
>> required version, I did a commit with >=0.11.2 check based on your 
>> api update, from a fast look I didn't saw newer api. Other optional 
>> cases (like lz4) is/will be with define.
>> Spice compositor differently from rdp one now should support some 
>> stable versions. This I think is good to avoid rdp compositor problem 
>> that make it after some years still unable in some major distros: 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775855 (was blocked 
>> by 814676 - update freerdp)
>> There are other cases that make the maintainer of solid distributions 
>> refractory to support it.
> OK then! =)
>>
>>>
>>> Second one is regarding your remarks. I hurried too much with 
>>> editing your commits. I'm sorry. So I left your logic but in another 
>>> stile. I used "int compression" to handle invalid data. But than 
>>> found SPICE_IMAGE_COMPRESS_INVALID value and changed the variable 
>>> type back to spice_image_compression_t. I think this part is OK now, 
>>> but if you have something to say or change there, fill free to do it =)
>>
>> Thanks, seems very good, in wan compression options case is also 
>> better having specific error message on each option.
>> I did some commits:
>> https://github.com/Fantu/compositor-spice/commits/test3
>> Can you cherry-pick since after "Add Spice compositor" if are ok for you.
> Done! Almost without changes. =)
>> About the wan compression patch I did it very fast and I only checked 
>> build (success) but I not tested it and is possible that have error 
>> or unexpected cases doing it fast, I'll try to do other tests now if 
>> I haveenough time but I'm not sure.
> I'll try too when I'll find much time.
>>
>>>
>>> Third - I remove some rubbish like dprint from my old code. But I'm 
>>> afraid, there still much to do in this sphere. Will be perfect if 
>>> you make the revue, but not now - we have more important things to do.
>>>
>>> For example, next I'm going to read the code of compositor-rdp much 
>>> closely to understand how it works. This needed to know did we miss 
>>> something.
>>>
>>> The second thing after that - is to render the screen on the client 
>>> side. Now whole images composed on the server and sent fully to the 
>>> client.
>>
>> If will be possible do rendering and image "difference" with opengl 
>> (or probably better also with vulkan) I think can be very useful.
> This was the main idea of my diploma. More over, my old university 
> fellow managed to make the drm device work with non-framebuffer 
> memory. We planned to merge our work at the end, but the fate decreed 
> otherwise. The problem, I'm thinking to solve here, is that the 
> frameworks (GTK+ or Qt) uses their own drawers like Cairo to update 
> the windows and sends to desktop manager the whole new window.
>> Spice developers added recently spice-egl for support rendering of vm 
>> using virgl with 3d but now is only local.
> I don't know what they do, but I thought about the next:
>
>  1. calculate the more accurate region of damage
>  2. recognize the type of damage:
>       * full image replacement (buttons, radios, etc): we can cache
>         the control elements on client side to reuse them instead of
>         resending
>       * text: spice can send the text maybe we can use this somehow.
>       * scrolling: in this case instead of sending whole damage, we
>         can send just the little strip of the region edge.
>       * complex changes (movie, game, add): nothing to do here,
>         compress and send as is.
>       * the combination: the add in browser while scrolling.
>  3. handle each type of damage by its own way.
>
> This will decrease the amount of data to render remotely (except the 
> 3rd case). I'm afraid that this is kind of utopia too, but in theory 
> it is possible with using the shaders.
>> For remote I don't know if there is something in progress.
>> I thinked about better possibility to solve improve 
>> latency/efficiency doing all directly with opengl or vulkan (with vk 
>> should be possible better manage resources) do directly texture 
>> compressed (to avoid some software steps in that I fear most are the 
>> leading cause of latency and inefficiency), I saw bc7 that seems to 
>> have high quality, alpha support and is mandatory in vulkan but 
>> probably still requires too much bandwidth.
>> Alternative with streaming with lossy codec like gstreamer project in 
>> development (I already tested in vm) seems too many greedy of 
>> resources and with too many latency.
>> So I do not know if my idea can be implemented in practice or is just 
>> utopia.
>> I have too little knowledge to better evaluate.
> This is another way of using GPGPU  in our case. May be we need to 
> look here first.
>>
>> I suppose start look rdp and trying to improve generic solution 
>> compatible also without hardware acceleration (to keep it usable for 
>> all users/cases) is a good/fast thing to do initially as what seems 
>> you want already do, after we'll think about utopian things.
> Just exactly what I was going to say! =)
>> Another thing to look interesting is screen sharing plugin now usable 
>> only with rdp, if will be possible add spice support easy/fast 
>> probably will be good but I not looked its code for now. (I suppose 
>> can be very useful for user remote assistance thing like teamviewer, 
>> I suppose that this with spice full features will be better that 
>> teamviewer and similar)
> Yes, I noted this too.
>>
>>>
>>> By the way! Thank you again for your help! =)
>>>
>>> P.S. What did you learn about vdagent?
>>
>> Is very useful (required for mouse client mode, clipboard copy, file 
>> transfert, ecc...)
>> I saw the difference for example in xen when now pv domUs can't 
>> support it and is remarkable.
>> It is already implemented in xspice but with a fast look seems have 
>> xorg specific things.
>> I didn't investigated in detail for now.
> OK will remember this and return to
>>
>> Sorry for my bad english.
> But now I suggest you and me to return from sky back to earth. We have 
> many things to do. HW acceleration, vdagend, screen sharing, 
> compression and authentication is good points. But without any 
> acceptable performance they are useless.
> Firstly we need to be not worse than rdp-compositor and we know how to 
> achieve this. In my opinion it is better for us to stop surfing such 
> interesting things like vdagent and vulkan and concentrate on more 
> important things.
>
> Honestly, I spent an our, writing this reply (5 minutes I spent on 
> your commits). I think you spent much time too looking for technology. 
> In fact this was important and realy useful. But now I suggest us to 
> spend this time for nearest problems. What do you think? =)
In recent years have done too little programming and mymemory is bad lately.
About the performance problem I remember something like a big problem 
also in xspice that seems improved a lot with deferred fps:
https://lists.freedesktop.org/archives/spice-devel/2012-August/010276.html
Can be useful for this project or with wayland/weston is possible do 
something similar in a different and/or better way?
In the weekend probably I'll look better the weston code but I not know 
if I'll have needed freetime and knowledge for doing something useful 
for the mainly problem in a short time.
I started to do small things fast and easy for doing something in short 
time and start to watch something about weston and this project code
Things done I think/hope is still something useful because make possible 
do some fast tests (I think useful for a project in development), remote 
use (lan or wan) that I think is the main goal of this project, auth 
(password) is needed for at least an essential security (mainly for wan 
test without vpn), image compression to make it usable on <1gbps network 
and not throttle the network, and additional wan compressions to make it 
usable on wan connections (if are not too bad) based on my spice experience.
I used/tried many remote access softwares, mainly for virtual machine 
but not only, spice is a very good one, with high quality but with 
efficiency/latency issues visible in most recent use cases.
I'm trying to help this project because seems the better quality and 
full open source project I found to reach one of my purpose: remote 
access and remote assistance on linux physical machine; one missed or 
bad thing on actual linux machines and one blocking step for 
windows->linux migration in many cases. There is also xspice project in 
a more advanced state but is based on xorg that is old, with less 
potential and I suppose it is a bad long-term choice.
Another thing is that 3d hw acceration is increasingly necessary and in 
future will be essential for any use (also basis) on any device 
(including virtual machine). Trying to implement the better solution as 
possible to have 3d hw support and improve spice efficiency and latency 
seem more easy and fast here before instead of doing in virtual machine 
or I'm wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160310/b71c4fbe/attachment-0001.html>