The generally recommended way is to include it from source files, not
headers. We had a mix of both. Let's try to be consistent and follow the
recommended way.
Move image encoding logic into a central EncodeManager class
This allows us to apply a lot more server logic
independently of which encoder is in use.
Most of this class are things moved over from the
Tight encoder.
Use PixelBuffer objects as the interface for encoders and decoders
This avoid a lot of unnecessary middle men. This also pushes the
responsibility for pixel format conversion into the encoders and
decoders. The new bufferFromBuffer() is used for direct conversion,
rather than PixelTransformer/TransImageGetter.
Encoders/decoders should track the connection object
The connection object is a much more appropriate object for the
decoders and encoders to keep track of. Besides the streams, it also
contains state like connection parameters.
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.
Fix regression caused by r4841. That patch assumed that JPEG encoding always uses the raw buffer, which is not true. If pixel translation is necessary, then JPEG images will sometimes be encoded from the translated (intermediate) buffer instead.
The Tight encoder uses the pixel buffer as a scratch pad, which doesn't
work so well with the new optimisation to feed it the raw frame buffer.
Reorganise and clean up the code to handle this, and make the raw frame
buffer pointer const so that we might avoid such bugs in the future.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4841 3789f03b-4d11-0410-bbf8-ca57d06f2519
Increase the default compression level to cater to a broader range of users
(bandwidth is often the limiting factor, rather than CPU). Further increases
give little returns, so 2 is currently deemed the best tradeoff.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4811 3789f03b-4d11-0410-bbf8-ca57d06f2519
Add support for TurboVNC pseudo-encodings and Grayscale JPEG compression so that, when a TurboVNC viewer is connected, the TigerVNC Server will behave exactly like the TurboVNC Server.
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.)
Ported encoding optimizations from TurboVNC. The changes to the Tight parameters were determined through extensive low-level profiling (see http://www.virtualgl.org/pmwiki/uploads/About/turbototiger.pdf). The other enhancements involved: (1) porting the solid subrectangle pre-computation code from TightVNC/TurboVNC (it makes a pretty big difference-- see report), (2) encapsulating the JPEG encoder in its own class (this eliminates a buffer copy, and the JPEG buffer is now set to a decent size where it shouldn't ever need to be paged or re-allocated, except in rare corner cases), (3) adding support for last rect. encoding (necessary to support the solid rectangle pre-computation enhancements.
Change JPEG quality/subsampling map to produce meaningful compression ratios, as defined by the VirtualGL project study of rendered frames from SPECviewperf 9
The percieved quality isn't really linear compared to the actual quality
setting, so make it a bit more top heavy. Also disable color subsampling
at some levels and make the highest quality lossless.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3660 3789f03b-4d11-0410-bbf8-ca57d06f2519
Pierre Ossman
Michal Srb
DRC
Constantin Kaplinsky
Peter Åstrand