| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Avoid having our own custom stuff and instead use the modern, standard
types, for familiarity.
|
|
|
|
|
| |
Avoid preprocessor magic and instead rely on templating to generate
optimized functions for performance critical code.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This is a lot easier and cheaper than having to set up a complete
PixelTransformer object.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Might as well make it inline at this point as well as it is used
heavily in other routines that convert entire blocks of pixels.
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Tight decoding directly into the viewer's back buffer, rather than going through the slow fillRect/imageRect routines.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4757 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
|
|
|
|
| |
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.)
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4631 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
|
|
| |
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3784 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
|
|
| |
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3730 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
|
|
|
|
|
| |
common cases.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3636 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
More changes will follow.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@589 3789f03b-4d11-0410-bbf8-ca57d06f2519
|