libvncclient: enhance tight decoder to support all 32bpp pixel formats #606
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The previous tight decoder was limited in that it only supported a few of the 32bpp pixel formats that TurboJPEG could natively output. This merge request enhances the tight decoder so that it supports all possible 32bpp pixel formats (all possible maximums, shifts, etc.).
This merge request is split into two commits. The first commit enhances the tight decoder so that it covers all four of the 32bpp pixel formats that TurboJPEG can natively output in either big- and little-endian byte orders. Prior to this commit the tight decoder only supported a limited number of the pixel formats that TurboJPEG could natively ouput and the formats supported were dependent on the client's requested byte order. The second commit further expands the pixel format coverage to perform additional conversion if the 32bpp format is not natively supported by TurboJPEG to cover pixel formats with arbitrary maximums, shifts, etc. Thankfully by necessity, since TurboJPEG cannot natively output 16bpp pixel formats, the 16bpp code path was already doing this very conversion, so we can reuse it if the client requests a 32bpp pixel format that TurboJPEG cannot directly output.
Note that this merge request does not change the handling of 16bpp pixel formats, which were already completely covered by the code previously.