Our fast paths assume that each channel fits in to a separate byte.
That means the shift needs to be a multiple of 8. Start actually
checking this so that a client cannot trip us up and possibly cause
incorrect code exection.
Issue found by Pavel Cheremushkin from Kaspersky Lab.
Otherwise we might be tricked in to reading and writing things at
incorrect offsets for pixels which ultimately could result in an
attacker writing things to the stack or heap and executing things
they shouldn't.
This only affects the server as the client never uses the pixel
format suggested by th server.
Issue found by Pavel Cheremushkin from Kaspersky Lab.
Simple shifting can give noticable rounding errors if there is a large
difference in the number of bits between the formats. Do the proper
thing via a lookup table, the same way things are done for up conversion.
Handles the common cases when the target or source are in
the preferred 888 format.
If one of the buffers is not 888, then it must also be properly
aligned (which is commonly the case). Performance is now in many
cases on par with PixelTransformer.
You have to loop many times when converting e.g. 2 bits to 8,
so have a couple of lookup tables to speed things up. We still
use bit replication to get from 8 bits to 16 bits though.
Gets rid of a loooot of code and complexity.
Colour map clients are still supported through an
automatically generated map, but we lose the ability to
develop a client or server that uses colour maps
internally.
Consistently use the term stride rather than pitch. Also
consistently represent the stride in number of pixels rather
than number of bytes. There is so much code that assumes
proper alignment already that we do not need the extra resolution.
Converting to RGB might involve a precision increase
Need to do more than a simple shift to get the appropriate
new value. This isn't quite as exact as a proper multiplication
and division, but the error is so small it's not worth the
extra cycles.
If the client and server are using identical pixel formats, then perform Tight decoding directly into the viewer's back buffer, rather than going through the slow fillRect/imageRect routines.
Further optimizations to the Tight encoder to eliminate getImage() overhead. The encoder now directly accesses the framebuffer for solid rectangle computation, JPEG encoding, and color counting (if pixel translation is not required.) Also moved everything in tightEncode.h into the TightEncoder class to eliminate all of the static mess (this will be important later on if we decide to multi-thread the encoder.)
Converting a integer shift to a byte offset of course depends on endianness
as the first byte might be either shift 0 or shift 24.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4165 3789f03b-4d11-0410-bbf8-ca57d06f2519
Changed all user-visible strings from colour to color.
Also, the Windows viewer now accepts arguments with both spellings.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@69 3789f03b-4d11-0410-bbf8-ca57d06f2519
Pierre Ossman
DRC
Constantin Kaplinsky
Peter Åstrand