[winswitch] Reducing the colour depth (client side)

[Nick Burrett]

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

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.

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.

I'll have to experiment with this next week


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