bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround

[Daniel Colascione]

On 12/29/11 8:13 AM, Juanma Barranquero wrote:
> On Thu, Dec 29, 2011 at 15:05, Daniel Colascione <dancol@dancol.org> wrote:
> 
>> The workaround
>> seems harmless: on non-palettized displays, calculating the number of
>> display colors based on display bitness should produce good results.
> 
> Even so, why fix what is not broken? Why can't you just do
> 
> === modified file 'src/w32fns.c'
> --- src/w32fns.c      2011-12-04 08:02:42 +0000
> +++ src/w32fns.c      2011-12-29 16:10:33 +0000
> @@ -4511,5 +4511,12 @@
>      cap = GetDeviceCaps (hdc, SIZEPALETTE);
>    else
> -    cap = GetDeviceCaps (hdc, NUMCOLORS);
> +    {
> +      cap = GetDeviceCaps (hdc, NUMCOLORS);
> +      /* GetDeviceCaps (NUMCOLORS) is buggy under remote desktop and
> +         sometimes returns the number of system reserved colors (20)
> +         instead of the actual number of available colors.  */
> +      if (cap == 20)
> +        cap = -1;
> +    }

Why? What's the point of adding the extra complexity?
Setting cap to -1 leads to this line

    1 << min (dpyinfo->n_planes * dpyinfo->n_cbits, 24);

which produces a reasonable result for direct color displays.
Why keep using NUMCOLORS, which we know to be broken?

>    /* We force 24+ bit depths to 24-bit, both to prevent an overflow
> 
>> +    // GetDeviceCaps (NUMCOLORS) is buggy under remote desktop and sometimes
>> +    // returns the number of system reserved colors (20) instead of
>> +    // the actual number of available colors.
> 
> Please, don't use "C++ / modern C" style comments; use /* */ instead.
> 

That block slipped through.

signature.asc
Description: OpenPGP digital signature