Raw by itself is completely useless. However, using a combination of
Raw tiles and paletted tiles, both encoded using the Tight encoder, is
useful. TurboVNC 0.5 does that for its mathematically lossless modes.
What we found is that there is really no reason to use any encoder other
than the Tigh
On Wed, Mar 11, 2009 at 03:55:11PM +0100, Pierre Ossman wrote:
> On Wed, 11 Mar 2009 15:35:29 +0100
> Adam Tkac wrote:
>
> >
> > If non-SIMD JPEG is not so slower than raw encoding we can prefer
> > Tight JPEG encoding all the time. Otherwise we can use JPEG on low and
> > medium bandwidth nets
On Wed, 11 Mar 2009 15:35:29 +0100
Adam Tkac wrote:
>
> If non-SIMD JPEG is not so slower than raw encoding we can prefer
> Tight JPEG encoding all the time. Otherwise we can use JPEG on low and
> medium bandwidth nets and raw on high bandwidth nets. I think that
> current algorithm which is cur
On Wed, 11 Mar 2009, Adam Tkac wrote:
We should always send "second preferred" encoding to server in case
that server doesn't support JPEG. So, in theory, existing code will be
improved this way:
for speeds >= 16Mbps client sends "Raw, JPEG, hextile, zrle"
for speeds < 16Mbps client sends "JPEG
On Wed, Mar 11, 2009 at 01:40:29PM +0100, Pierre Ossman wrote:
> The current encoding autoselection is not working very well, and is
> fundamentally wrong as it is implemented in the client (which has no
> knowledge of the data and what encoding will be the most efficient).
>
> Fixing this properl
