aboutsummaryrefslogtreecommitdiffstats
path: root/common/rfb/PixelFormat.cxx
Commit message (Collapse)AuthorAgeFilesLines
* Capitalize some more logging and exceptionsPierre Ossman2024-11-221-2/+2
|
* Use standard library naming for exceptionsPierre Ossman2024-11-061-1/+1
| | | | | This makes things more consistent since we mix with the standard library exceptions so often.
* Use specific class for protocol problemsPierre Ossman2024-11-061-1/+1
| | | | Make it easier to identify communication issues.
* Use standard exception classesPierre Ossman2024-11-061-1/+1
| | | | | Use the more specific already included exception classes for common errors to keep things more understandable.
* Use operator overloading for comparisonPierre Ossman2023-02-041-2/+7
| | | | | It is much more natural than custom methods for this very common operation.
* Remove unused rfb/util.h includesPierre Ossman2023-02-041-1/+0
| | | | | | | | These files don't use anything from this header, so remove the include. This exposes some missing includes in other places, though. So add an explicit include in the files that were relying on an indirect inclusion.
* Use stdint typesPierre Ossman2023-02-011-28/+28
| | | | | Avoid having our own custom stuff and instead use the modern, standard types, for familiarity.
* Use templates for optimized codePierre Ossman2023-02-011-38/+130
| | | | | Avoid preprocessor magic and instead rely on templating to generate optimized functions for performance critical code.
* Be consistent in including config.hPierre Ossman2021-12-301-0/+5
| | | | | | 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.
* Handle pixel formats with odd shift valuesPierre Ossman2019-11-151-0/+6
| | | | | | | | | 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.
* Add sanity checks for PixelFormat shift valuesPierre Ossman2019-11-151-0/+7
| | | | | | | | | | | | 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.
* Fix depth sanity test in PixelFormatPierre Ossman2019-11-151-1/+1
|
* Add unit test for PixelFormat sanity checksPierre Ossman2019-11-151-1/+2
|
* Fix rounding error in pixel down conversionPierre Ossman2018-03-011-6/+12
| | | | | | 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.
* Wrong padding size calculated (copy-paste error)Pierre Ossman2014-10-091-1/+1
|
* Fix endian conversionPierre Ossman2014-09-251-12/+22
| | | | This was just plain wrong, so redo it properly.
* Add optimised buffer conversionPierre Ossman2014-07-091-0/+113
| | | | | | | | | 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.
* Add ability to directly convert between two pixel formatsPierre Ossman2014-07-091-0/+50
| | | | | This is a lot easier and cheaper than having to set up a complete PixelTransformer object.
* Use lookup tables for pixel upconversionPierre Ossman2014-07-091-0/+36
| | | | | | 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.
* Remove full support for colour mapsPierre Ossman2014-07-071-58/+90
| | | | | | | | | 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.
* Avoid code duplication for the linear pixel format conversion methodsPierre Ossman2014-07-071-79/+2
|
* Consistent use of stride vs pitchPierre Ossman2014-07-071-6/+6
| | | | | | | 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.
* Fix possible information leakagePierre Ossman2014-07-071-2/+11
| | | | Zero the padding byte used when converting 24-bit RGB to 32-bit.
* Use the same algorithm for conversionsPierre Ossman2014-07-071-73/+53
| | | | | | Make sure that the routines that convert between buffer and rgb representations follow the same algorithm so it's easier to compare them.
* Optimise the RGB to pixel conversion to simple shiftsPierre Ossman2014-07-071-49/+11
| | | | | 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.
* Remove unused pixel conversion methodPierre Ossman2014-07-071-17/+0
|
* Converting to RGB might involve a precision increasePierre Ossman2014-07-071-4/+11
| | | | | | | 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.
* Make sure we check that PixelFormats we get are actually valid.Pierre Ossman2014-07-031-6/+43
|
* Add fast paths for RGB to 16-bit and 8-bit true color conversionDRC2011-11-041-0/+22
| | | | git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4764 3789f03b-4d11-0410-bbf8-ca57d06f2519
* If the client and server are using identical pixel formats, then perform ↵DRC2011-11-031-0/+55
| | | | | | 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
* Fix compiler warnings uncovered with -WallDRC2011-11-031-2/+0
| | | | git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4752 3789f03b-4d11-0410-bbf8-ca57d06f2519
* Do register reduction to re-normalize the performance at the low levelDRC2011-08-191-8/+19
| | | | git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4643 3789f03b-4d11-0410-bbf8-ca57d06f2519
* Further optimizations to the Tight encoder to eliminate getImage() overhead. ↵DRC2011-08-171-0/+46
| | | | | | 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
* Converting a integer shift to a byte offset of course depends on endiannessPierre Ossman2010-10-131-6/+18
| | | | | | | 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
* Make sure we handle endian problems in the conversion code.Pierre Ossman2009-04-211-5/+11
| | | | git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3784 3789f03b-4d11-0410-bbf8-ca57d06f2519
* Update shift values in pixel format parse routine.Pierre Ossman2009-04-031-0/+3
| | | | git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3748 3789f03b-4d11-0410-bbf8-ca57d06f2519
* Optimise the common pixel format conversion RGB24 to RGB32.Pierre Ossman2009-03-311-0/+38
| | | | git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3730 3789f03b-4d11-0410-bbf8-ca57d06f2519
* Needs to be true colour to be 888.Pierre Ossman2009-03-251-0/+2
| | | | git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3720 3789f03b-4d11-0410-bbf8-ca57d06f2519
* A quick optimisation of the common 32-bit to 24-bit pixel conversion.Pierre Ossman2009-03-251-11/+30
| | | | git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3719 3789f03b-4d11-0410-bbf8-ca57d06f2519
* Consolidate pixel conversion into the PixelFormat class and optimise thePierre Ossman2009-03-061-8/+140
| | | | | | | common cases. git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3636 3789f03b-4d11-0410-bbf8-ca57d06f2519
* Migrating to new directory structure adopted from the RealVNC's source tree. ↵Constantin Kaplinsky2006-05-251-0/+239
More changes will follow. git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@589 3789f03b-4d11-0410-bbf8-ca57d06f2519
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 20:27:55 +0000