Bugzilla – Bug 5753
Gradients show banding with rdesktop
Last modified: 2018-02-27 09:59:02
You need to
before you can comment on or make changes to this bug.
Created an attachment (id=661) [details]
Sample gradient with banding from WordPad
Windows 2012 R2, CentOS 7 x86_64, ThinLinc-4.5.0post-4970
How to reproduce:
- Connect to Windows server with tl-run-rdesktop.
- Start WordPad.
- Zoom out until you see the background gradient on each side of the empty
The gradient should be smooth, but it's showing clear banding, which would
indicate a bit depth problem. The attached image shows the problem clearly.
This warning from rdesktop is most likely the problem:
> WARNING: Remote desktop does not support colour depth 24; falling back to 16
Pierre mentioned something about Windows moving to 32-bit color instead of 24.
Vendor drop r32951 introduces support for 32-bit color.
I can't reproduce the original problem with rdesktop from 4.5.0, 4.7.0 and
4.8.0 (and obviously not 4.8.0post). Connecting to the Windows Server 2012 lab
(In reply to comment #4)
> I can't reproduce the original problem with rdesktop from 4.5.0, 4.7.0 and
> 4.8.0 (and obviously not 4.8.0post). Connecting to the Windows Server 2012 lab
As in the server supports 24-bit color? I believe this bug report was based on
the assumption that a server could support 32-bit but not 24-bit color. I
believe that this could very well be a bad assumption though.
To some extent, this problem is still unsolved and probably unsolvable. Running
"rdesktop -a 16 ..." will still give you banding artifacts in gradients. We
need to control the server side to be able to introduce dithering or other
techniques to combat the banding.
I just got this message when connecting to our Windows 2012R2 cluster:
> Remote desktop does not support colour depth 24; falling back to 32
So it appears that there ARE systems that support 32- but not 24-bit color.
This means that we're not falling back to 16-bit color if there are better
alternatives present. The banding still occurs at 16-bit but that's acceptable.
I haven't yet seen any problems with running 32-bit colors so the color
conversion routines seem to work as expected. I'm considering this bug tested.
Forgot release notes.