Questions about experimental Spice compositor rebase

[Fabio Fantoni]

Il 12/03/2016 23:13, Fabio Fantoni ha scritto:
>
>
> Il 10/03/2016 22:58, Yury Shvedov ha scritto:
>>
>> On 03/10/2016 06:04 PM, Fabio Fantoni wrote:
>>> 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?
>> Of corse this is useful like all the stuff you found in the net last 
>> time. But you chaotically offers me many different things without any 
>> result except my "OK, I will take a look". Because I have not much 
>> time to investigate it with you. You are looking for the answers on 
>> your questions in the internet, while I have a couple in the code. I 
>> see good way for the next steps and have tried to explain them to 
>> you. I'm afraid that you didn't understand them, so I'll try again at 
>> the bottom of this message.
>> After that I suggest to decide and fix what we will do next.
>>> 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.
>> Maybe you better to do something in what you sure? How about fps 
>> tests like ones in your link?
>
> I did a fast test with screen-share for see if it can works also with 
> other compositor instead rdp but was failed and I not found nothing in 
> weston log about.
> I tried to see if was possible have weston working local normal with 
> drm (3d and good performance) and additionally add spice session and 
> after check if was possible and better add a "deferred fps" in 
> screen-share to limit the screen data that spice-compositor must 
> elaborate.
> I take a fast look also to qemu and xspice code trying to understand 
> the initial improvement to do about image processing but seems that 
> qemu do operation with vm qxl drivers and xspice similar copied by it 
> and using qxl driver.
> I I do not know if this is possible in other better way with weston (I 
> have no knowledge to understand if it is something like what you mean 
> about making a spice_renderer).
> Maybe tomorrow I will have a few more hours of time and do not know 
> whether to try anyway to add deferred fps quickly from xspice or 
> looking something about weston things you write below.

Unfortunately I must did other things today and I had only short time to 
give another fast look to code, I did also another test (to find some 
data on how is useful to proceed without waste time), I found high cpu 
usage (only one core, like one spice efficiency problem that I had 
noticed long ago instead weston ifself) even if without any spice 
session, then I enabled spice debug and I see input fps to 967 (with no 
spice session and without any screen change I suppose), then deferred 
fps seems a good fast workaround to do for start (I'll try to implement 
it following xspice next weekend) and try to send only the difference 
(where possible) seems probably the best thing as you said.

>
>
>>> 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.
>> There much more ways to decrease the network usage and increase fps 
>> except compression.
>>> 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.
>> I'm appreciate your help and interest (the windows to linux migration 
>> is really good point!) and I hope one day this project became 
>> something we wand to see.
>>> 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?
>> I'm afraid I didn't catch last sentence. What doing in virtual machine?
>>
>> Returning to our main topic. How do I suppose to increase fps and 
>> decrease network usage?
>> The main idea is to decrease the amount of image data sended via 
>> network. For example, we have an application window moving on the 
>> desktop background. The bad way is to compose the whole desktop image 
>> on each step on the server and send it to client. But the better way 
>> is to send to client 2 images once and tell him to change position of 
>> one of them when it is needed. I think this example is obvious for 
>> you and you should know that spice can perfectly handle such tasks 
>> (moving images remotely and much more). This is the first aim I want 
>> to achieve: to cache the per-application surface on the client side, 
>> and left the building of final desktop image to it.
>> This can be done by creating the spice_renderer and using it instead 
>> of pixman_renderer for distributed painting.
>>
>> Another thing I want to do first is to understand, what does the 
>> rdp-compositor do before sending the image data? The learning how 
>> dose rdp_output_repaint and other functions works will help us to 
>> find another one already passed way to optimisation.
>>
>> What do you think? Do you have another suggestions about the way of 
>> this spice-compositor developing?
>
> I'm having difficulty to understand at least the basics of what is 
> needed in a short time, for sure you know much more.
> Maybe about tips on what to do can be helpful to post the current 
> draft of the patch as an RFC (request for comments) on wayland-devel 
> and spice-devel and probably some expert developers about them can 
> fastly give some advices.
> I did the same with other things and they gave me useful information 
> to make fast patches I needed analyzing a few specific things instead 
> of read/understand all the code of large pieces. Probably also with 
> this can be useful to understand something useful I can do the first 
> weekends instead spent all time to learn, but if learn many things 
> before is really needed I'll try to do it. It seems that unfortunately 
> I'm no longer quick to learn/understand as I did years ago (years ago 
> unfortunately, however, I wasted thousands of hours with unnecessary 
> proprietary projects instead) :(
>
> Thanks for any reply and sorry for my bad english.
>
>>
>> Kind regards
>> Yury Shvedov
>

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