Remote Desktop can throw off rendering of .NET controls in annoying ways, and most of those come down to dithering and other colour-related issues. It can be especially annoying when you have a standard WinForms control that seems to render in one colour just fine, and a UserControl that should be rendering in exactly the same colour looking off by a few shades.
If you’ve encountered this then you’ve probably zoomed into a screenshot of the broken and working controls side-by-side and noticed that your UserControl is dithering the colour while the built-in control is a nice solid hue.
This is down to Remote Desktop running as a terminal session with a lower colour depth than you might be used to on a local machine to improve performance. This means that when you set a colour on your control, it may not be exactly representable by the time it’s been rendered over the RDP session and so the colour will be dithered to give an approximation.
The key is that the built-in controls are using Graphics.GetNearestColor to map the requested colour to one that can be represented without dithering given the settings of the current terminal session. If you’re running locally in full-colour then it’ll just return the colour you asked for. If however you’re running over RDP it’ll give you the best attempt it can.
For example Gainsboro, a named system colour, is defined as #DCDCDC (or 220,220,220). Over a 24-bit-per-pixel RDP session you may find that the Graphics object supplied in your UserControl’s Paint events can only manage #D8DCD8 as a solid tone.
So how does a Label render nicely over RDP when its BackColor is set to Color.Gainsboro and your user control not? Simple – the colour you’re seeing isn’t Gainsboro at all – it’s just as close as the graphics context can manage given the current session’s settings. So if access over a terminal session is a use case you have to handle, consider using Graphics.GetNearestColor to translate your desired colour into something more manageable by the session.




