<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Il 09/03/2016 20:32, Yury Shvedov ha
      scritto:<br>
    </div>
    <blockquote cite="mid:56E07A35.1020500@lvk.cs.msu.su" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      Hi, Fabio! Sorry for long silence.<br>
      <pre class="moz-signature" cols="72">Kind regards
Yury Shvedov</pre>
      <div class="moz-cite-prefix">On 03/07/2016 12:12 AM, Fabio Fantoni
        wrote:<br>
      </div>
      <blockquote cite="mid:56DC9D3F.1090006@m2r.biz" type="cite">
        <meta content="text/html; charset=utf-8"
          http-equiv="Content-Type">
        Il 06/03/2016 13:25, Yury Shvedov ha scritto:<br>
        <blockquote cite="mid:56DC21CE.1070500@lvk.cs.msu.su"
          type="cite">
          <meta content="text/html; charset=utf-8"
            http-equiv="Content-Type">
          Hi, Fabio! <br>
          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.<br>
        </blockquote>
        <br>
        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.<br>
        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: <a moz-do-not-send="true"
          class="moz-txt-link-freetext"
          href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775855">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775855</a>
        (was blocked by 814676 - update freerdp)<br>
        There are other cases that make the maintainer of solid
        distributions refractory to support it.<br>
      </blockquote>
      OK then! =)<br>
      <blockquote cite="mid:56DC9D3F.1090006@m2r.biz" type="cite"> <br>
        <blockquote cite="mid:56DC21CE.1070500@lvk.cs.msu.su"
          type="cite"> <br>
          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 <span class="blob-code-inner">SPICE_IMAGE_COMPRESS_INVALID



            value and changed the variable type back to </span><span
            class="blob-code-inner"><span class="pl-c1">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 =)<br>
            </span></span></blockquote>
        <br>
        Thanks, seems very good, in wan compression options case is also
        better having specific error message on each option.<br>
        I did some commits:<br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
          href="https://github.com/Fantu/compositor-spice/commits/test3">https://github.com/Fantu/compositor-spice/commits/test3</a><br>
        Can you cherry-pick since after "Add Spice compositor" if are ok
        for you.<br>
      </blockquote>
      Done! Almost without changes. =)<br>
      <blockquote cite="mid:56DC9D3F.1090006@m2r.biz" type="cite"> 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 have<span id="result_box" class="short_text"
          lang="en"><span class="hps"> enough</span> <span class="hps">time</span></span>
        but I'm not sure.<br>
      </blockquote>
      I'll try too when I'll find much time.<br>
      <blockquote cite="mid:56DC9D3F.1090006@m2r.biz" type="cite"> <br>
        <blockquote cite="mid:56DC21CE.1070500@lvk.cs.msu.su"
          type="cite"><span class="blob-code-inner"><span class="pl-c1">
              <br>
              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.<br>
              <br>
              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.<br>
              <br>
              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.<br>
            </span></span></blockquote>
        <br>
        If will be possible do rendering and image "difference" with
        opengl (or probably better also with vulkan) I think can be very
        useful.<br>
      </blockquote>
      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 <span
        id="result_box" class="short_text" lang="en"><span class="hps">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.<br>
        </span></span>
      <blockquote cite="mid:56DC9D3F.1090006@m2r.biz" type="cite"> Spice
        developers added recently spice-egl for support rendering of vm
        using virgl with 3d but now is only local.<br>
      </blockquote>
      I don't know what they do, but I thought about the next:<br>
      <ol>
        <li>calculate the more accurate region of damage <br>
        </li>
        <li>recognize the type of damage:</li>
        <ul>
          <li>full image replacement (buttons, radios, etc): we can
            cache the control elements on client side to reuse them
            instead of resending<br>
          </li>
          <li>text: spice can send the text maybe we can use this
            somehow.<br>
          </li>
          <li>scrolling: in this case instead of sending whole damage,
            we can send just the little strip of the region edge.<br>
          </li>
          <li>complex changes (movie, game, add): nothing to do here,
            compress and send as is.<br>
          </li>
          <li>the combination: the add in browser while scrolling.<br>
          </li>
        </ul>
        <li>handle each type of damage by its own way.<br>
        </li>
      </ol>
      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.<br>
      <blockquote cite="mid:56DC9D3F.1090006@m2r.biz" type="cite"> For
        remote I don't know if there is something in progress.<br>
        I thinked about better possibility to solve improve latency/<span
          id="result_box" class="short_text" lang="en"><span class="hps">efficiency


            doing all directly with opengl or vulkan (with vk should be
            possible </span></span><span id="result_box"
          class="short_text" lang="en"><span class="hps"><span
              id="result_box" class="short_text" lang="en"><span
                class="hps">better manage</span> <span class="hps">resources</span></span>)
            do directly texture compressed (to avoid </span></span><span
          id="result_box" class="short_text" lang="en"><span class="hps"><span
              id="result_box" class="" lang="en"><span class="hps">some
                software</span> <span class="hps">steps</span> <span
                class="hps">in</span> <span class="hps">that I fear</span>
              <span class="hps">most</span> <span class="hps">are</span>
              <span class="hps">the leading cause of</span> <span
                class="hps">latency and</span> <span class="hps">inefficiency</span></span>),

            I saw bc7 that seems to have high quality, alpha support and
            is mandatory in vulkan but probably still requires too much
            bandwidth.<br>
            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.<br>
          </span></span>S<span id="result_box" class="" lang="en"><span
            class="hps">o I do not know</span> <span class="hps">if my
            idea</span> <span class="hps">can be</span> <span
            class="hps">implemented</span> <span class="hps">in
            practice</span> <span class="hps">or is just</span> <span
            class="hps">utopia.<br>
            I have too little knowledge to better evaluate.<br>
          </span></span></blockquote>
      This is another way of using GPGPU  in our case. May be we need to
      look here first.<br>
      <blockquote cite="mid:56DC9D3F.1090006@m2r.biz" type="cite"><span
          id="result_box" class="" lang="en"><span class="hps"> <br>
            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.<br>
          </span></span></blockquote>
      Just exactly what I was going to say! =)<br>
      <blockquote cite="mid:56DC9D3F.1090006@m2r.biz" type="cite"><span
          id="result_box" class="" lang="en"><span class="hps"> 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 </span></span><span id="result_box"
          class="" lang="en"><span class="hps"><span id="result_box"
              class="" lang="en"><span class="hps">will be better that
                teamviewer and similar</span></span>)<br>
          </span></span></blockquote>
      Yes, I noted this too.<br>
      <blockquote cite="mid:56DC9D3F.1090006@m2r.biz" type="cite"><span
          id="result_box" class="" lang="en"><span class="hps"> <br>
          </span></span>
        <blockquote cite="mid:56DC21CE.1070500@lvk.cs.msu.su"
          type="cite"><span class="blob-code-inner"><span class="pl-c1">
              <br>
              By the way! Thank you again for your help! =)<br>
              <br>
              P.S. What did you learn about </span></span>vdagent?</blockquote>
        <br>
        Is very useful (required for mouse client mode, clipboard copy,
        file transfert, ecc...)<br>
        I saw the difference for example in xen when now pv domUs can't
        support it and is <span class="gt-baf-back"><span
            id="result_box" class="short_text" lang="en"><span
              class="hps">remarkable</span></span>.</span><br>
        It is already implemented in xspice but with a fast look seems
        have xorg specific things.<br>
        I didn't <span id="result_box" class="short_text" lang="en"><span
            class="hps">investigated</span> <span class="hps">in detail
            for now.<br>
          </span></span></blockquote>
      OK will remember this and return to<br>
      <blockquote cite="mid:56DC9D3F.1090006@m2r.biz" type="cite"><span
          id="result_box" class="short_text" lang="en"><span class="hps">
            <br>
            Sorry for my bad english.</span></span><br>
      </blockquote>
      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.<br>
      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. <br>
      <br>
      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? =)<br>
    </blockquote>
    <span id="result_box" class="" lang="en"><span class="hps">In recent</span>
      <span class="hps">years</span> <span class="hps">have</span> <span
        class="hps">done too little</span> <span class="hps">programming
        and my</span><span class="hps"> memory is</span> <span
        class="hps">bad</span> <span class="hps">lately.</span></span><br>
    About the performance problem I remember something like a big
    problem also in xspice that seems improved a lot with deferred fps:<br>
<a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/archives/spice-devel/2012-August/010276.html">https://lists.freedesktop.org/archives/spice-devel/2012-August/010276.html</a><br>
    Can be useful for this project or with wayland/weston is possible do
    something similar in a different and/or better way?<br>
    In the weekend probably I'll look better the weston code but I not
    know if I'll have needed freetime and <span id="result_box"
      class="short_text" lang="en"><span class="hps">knowledge for doing
        something useful for the mainly problem in a short time.</span></span><br>
    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<br>
    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 <span id="result_box"
      class="short_text" lang="en"><span class="hps">and not</span> <span
        class="hps">throttle the</span> <span class="hps">network</span></span>,
    and additional wan compressions to make it usable on wan connections
    (if are not too bad) based on my spice experience.<br>
    I used/tried many remote access softwares, mainly for virtual
    machine but not only, spice is a very good one, with high quality
    but <span id="result_box" class="" lang="en"><span class="hps">with</span>
      <span class="hps">efficiency</span><span class="hps">/</span><span
        class="hps">latency issues</span> <span class="hps">visible</span>
      <span class="hps">in most</span> recent use <span class="hps">cases.<br>
        I'm trying to help this project because seems the better quality
        and full open source project I found to reach one of my </span></span><span
      class="gt-baf-back gt-baf-hl">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 </span><span
      class="gt-baf-back gt-baf-hl"><span id="result_box"
        class="short_text" lang="en"><span class="hps">a more advanced
          state but is based on xorg that is old, </span></span></span><span
      class="gt-baf-back gt-baf-hl"><span id="result_box"
        class="short_text" lang="en"><span class="hps"><span
            id="result_box" class="" lang="en"><span class="hps">with
              less</span> <span class="hps">potential and</span> <span
              class="hps">I suppose it is</span> <span class="hps">a
              bad</span> <span class="hps">long-term</span> <span
              class="hps">choice.<br>
            </span></span></span></span>Another thing is that 3d hw
      acceration is </span><span class="gt-baf-back gt-baf-hl"><span
        id="result_box" class="short_text" lang="en"><span class="hps">increasingly
          necessary and in future will be </span></span>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 </span><span id="result_box"
      class="short_text" lang="en"><span class="hps">efficiency and
        latency seem more easy and fast here before instead of doing in
        virtual machine or I'm wrong?<br>
      </span></span>
  </body>
</html>