[winswitch] Reducing the colour depth (client side)

[Antoine Martin]

On 03/30/2013 02:25 PM, Nick Burrett wrote:
> On 4 March 2013 10:55, Antoine Martin <antoine at nagafix.co.uk> wrote:
>
>> On 03/04/2013 05:42 PM, Nick Burrett wrote:
>>> On 4 March 2013 09:00, Antoine Martin <antoine at nagafix.co.uk> wrote:
>>>> Hi Nick,
>>>>
>>>> xpra is a compositing window manager, and AFAIK this requires 24bpp or
>>>> higher. I've tried launching Xvfb/Xdummy with 8bpp and Composite gets
>>>> turned off. The -pixdepths switch does not help here. FYI: xpra seems to
>>>> crash rather than exit gracefully, but that's another problem.
>>>>
>>>> As for achieving bandwidth savings by reducing the colour depth, x264
>>>> and vpx encodings use colour subsampling when the quality is lowered
>>>> (switching from 4:4:4 to 4:2:2 and 4:2:0), this is in the chroma+luma
>>>> space rather than plain RGB, but it does save about 50% on image size.
>>>> Also note that newer encodings (x264, webp, etc) are vastly superior to
>>>> the encodings found in VNC, so the bandwidth usage should already be
>>>> much lower (even without colour subsampling).
>>> Alright, that makes sense.   My gnome-terminal data transfer showed as
>>> 420Mbytes for around 6 hours of operation (using x264).  I'll have a
>>> go at tuning the quality some more and extend the time between full
>>> window refreshes.
>>>
>>> I wonder if there's some efficiency to be gained by pre-processing the
>>> image before compression (at the expense of quality) -- perhaps by
>>> masking out the bottom 3 bits of R, G and B values so that the
>>> compressors don't have to try to handle subtle colour variations.
Possibly, this is a pretty narrow use case.
Masking out before passing the data to colourspace conversion / x264
would be a little bit wasteful, ideally we could find a way to tell x264
to do this for us. I haven't found any option to allow us to do this yet.

>>>> If you find that the quality/bandwidth/framerate/latency isn't good
>>>> enough for you use case, let me know - it is quite possible that recent
>>>> versions have focused a little bit too much on the LAN usage scenario..
>>> It's not great at the moment -- it can take 2-3 seconds to switch a
>>> tab in gnome-terminal, for example.  But I'd rather ensure that I've
>>> exhausted my client option settings first.
>> 2 to 3 seconds is way too high, I doubt you can find enough options to
>> lower that enough to make it bearable.
>> There is a lot of information for debugging such problems here:
>> https://www.xpra.org/trac/wiki/WindowRefresh#Debugging
>> Let me know what you find and I can make sure this gets auto-tuned properly
>>
> After some experimentation, I found that the refresh delays of 2-3 seconds
> are really just down to the amount of data transferred to render a full
> window.
2-3 seconds to render a window??
What application are we dealing with here? How many frames per second?
Using png or rgb24 on a 100Mbit/s LAN, a 1080p frame can reach the
client fast enough that you should not be able to notice any lag. Even
low-powered clients can render it very quickly too (and even quicker in
the 0.9.0 beta with OpenGL)
And even with x264/vpx, on a fairly modern CPU the encoding should be
fast enough (~60ms)
> For an x264 encoding, setting min-quality to 25 and auto-refresh-delay to
> 25+ seconds made a considerable difference to the usability of xpra over a
> 110ms+ latency link.  I suspect that further improvements could be possible
> by supporting bframes, at a small cost to latency.
OK, I'll see if I can lower the min-quality without getting too many
complaints about "bad picture quality".
As for auto-refresh and high latency, the code is supposed to take the
latency into account to prevent the auto-refresh from kicking in too
early, I'll have to verify that this works as it should. I can't imagine
why you would ever need to set auto-refresh to values greater than a few
seconds.
B-frames could be used, but this would require some changes to ensure
that we do send an I-frame no later than N milliseconds after it (with N
calculated in a similar way to auto-refresh), by triggering an I-frame
even if no changes have occurred. Not extremely difficult, but probably
not worth the effort in most cases, and also likely to cause other
problems similar to the one you encountered with auto-refresh.

> For PNG encodings, I would have thought that changing the encoding in
> PIL_encode() from 'RGB' to 'P' (palette indexed) may reap some rewards,
> since the actual size of the resultant PNG image should be smaller the
> number of colours in the image to be encoded is small enough.  For
> terminals/emacs etc, I'd imagine that there'd certainly be less than 256.
>  Additionally setting optimize=1 on the im.save() call may help.
Indeed, PNG 8-bit would probably save a fair amount of bandwidth, this
would need to be a separate encoding option from the current "png"
option, I'll see what I can do for the next release:
https://www.xpra.org/trac/ticket/305
I'm less convinced about the "optimize=1" option, having run hundreds of
benchmarks comparing different releases I have always found the PNG
encoding to be a CPU pig (and also pretty bad for latency), the optimize
flag is unlikely to improve this situation, but I'll run some automated
tests and see what the impact is.

> I'll have to experiment with this next week
Keep us posted!

Thanks
Antoine


>
>
>>
>>
>>> Regards,
>>>
>>> Nick
>>>
>>>>
>>>> On 03/03/2013 07:26 PM, Nick Burrett wrote:
>>>>> Hi,
>>>>>
>>>>> Is it possible to reduce the colour depth client side when performing
>>>>> xpra attach?
>>>>>
>>>>> I'm attempting to use xpra over a 3G modem link where the X server is
>>>>> 140ms away.  For a while, I've been using a VNC setup in exactly this
>>>>> way and found that reducing the colour from 24bits to 8bits had a
>>>>> considerable impact on usability.
>>>>>
>>>>> Xvfb has a -pixdepths option, which appears to be a list of supported
>>>>> colour depths.  I just would like to get the client to allow the
>>>>> choice to be determined at connection time.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Nick.
>>>>> _______________________________________________
>>>>> shifter-users mailing list
>>>>> shifter-users at lists.devloop.org.uk
>>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>>>>
>>>> _______________________________________________
>>>> shifter-users mailing list
>>>> shifter-users at lists.devloop.org.uk
>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>