Questions about experimental Spice compositor rebase

[Fabio Fantoni]

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.

>
> 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.
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.

>
> 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.
Spice developers added recently spice-egl for support rendering of vm 
using virgl with 3d but now is only local.
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.

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.
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)

>
> 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.

Sorry for my bad english.

> Kind regards
> Yury Shvedov
> On 03/04/2016 04:29 PM, Fabio Fantoni wrote:
>>
>> Thanks, another thing I saw only now:
>> "int compression;" I think should return "spice_image_compression_t 
>> compression;" for the better definition. If I'm not wrong (I not 
>> remember for sure) without it the default (compression = 
>> SPICE_IMAGE_COMPRESS_AUTO_GLZ;) will not works correctly.
>> Tomorrow I'll probably added other things, if you did/do something 
>> commit it, to avoid risk of waste time on same part. I'll try to add 
>> and test other compression types and basic authentication. I take a 
>> look to add vdagent support fast/easy from xspice but seems that 
>> there are things xorg specific that I think will be a problem. 
>> Probably it will require changes in upstream "spice/linux/vd_agent" 
>> before trying to use it here.
>>
>> Sorry for my bad english.
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160306/b560d0fe/attachment-0001.html>