Questions about experimental Spice compositor rebase
fabio.fantoni at m2r.biz
Sun Mar 20 21:59:19 UTC 2016
Il 14/03/2016 00:09, Fabio Fantoni ha scritto:
> 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:
>>>> 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
>> 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 unfortunately had short time also this weekend.
I tried to search a more efficient way to limit fps send to spice
(instead of adding another buffer like xspice) and probably I found
something about increase delay with "wl_event_source_timer_update", I
tried to increased delay set to time_start in
spice_output_start_repaint_loop function but the fps are still up near 1000.
I checked in rdp compositor and seems that delay is in
rdp_output_repaint instead of rdp_output_start_repaint_loop:
I suppose that now in spice compositor there a delay only at the loop
starts and/or "b->core->timer_start (output->wakeup_timer, 1);" in
"on_wakeup" (if is this the 1 ms delay will explain the actual fps near
Can someone tell me if my assumptions are right and if right what is the
better way to add a delay, using it for limit fps and make it settable
(for example max fps minimum to 10, maximum to 100 and default to 30)
without negative effects please?
I also tried to enable a weston debug to understand something faster and
use it as help in some fast tests, I tried with a fast google search
founding only WAYLAND_DEBUG=1 but seems that weston debug output is
partial or missed, is there another way?
I also found a "#define DEBUG 2" in compositor-spice-conf.h, this I
suppose should force weston debug level using spice compositor (with
COMPOSITOR_SPICE_CONF_H) but I did a grep without finding something
using it, can someone help me to understand please?
is the file compositor-spice-conf.h needed or can be removed? (seem used
only for change debug and set spice compositor version but with a grep
version seems unused and I suppose if will be needed can be setted
always and in compositor-spice.c instead)
For any developer reading this thread for the first time, here the spice
compositor repository: https://github.com/ein-shved/compositor-spice
And here latest patch to make faster see the spice compositor
additions/changes rebased on recently weston upstream:
Thanks for any reply and sorry for my bad english.
>>>> 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...
More information about the wayland-devel