bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround
Date: Tue, 07 Aug 2012 20:13:14 +0300

> Date: Tue, 07 Aug 2012 01:19:27 -0700
> From: Daniel Colascione <address@hidden>
> 
> Under remote desktop, Windows returns the wrong number of colors from
> GetDeviceCaps (hdc, NUMCOLORS).  I hit this bug myself, and MSDN
> comments seem to indicate that others hit it as well.  The workaround
> seems harmless: on non-palettized displays, calculating the number of
> display colors based on display bitness should produce good results.
> ---
>  src/w32fns.c |    9 ++++++++-
>  1 files changed, 8 insertions(+), 1 deletions(-)
> 
> diff --git a/src/w32fns.c b/src/w32fns.c
> index b82d4bc..7fc5cf5 100644
> --- a/src/w32fns.c
> +++ b/src/w32fns.c
> @@ -4513,8 +4513,15 @@ If omitted or nil, that stands for the selected 
> frame's display.  */)
>    hdc = GetDC (dpyinfo->root_window);
>    if (dpyinfo->has_palette)
>      cap = GetDeviceCaps (hdc, SIZEPALETTE);
> -  else
> +  else if (dpyinfo->n_cbits <= 8)
> +    /* According to the MSDN, GetDeviceCaps (NUMCOLORS) is valid only
> +       for devices with at most eight bits per pixel.  It's supposed
> +       to return -1 for other displays, but because it actually
> +       returns other, incorrect values under some conditions (e.g.,
> +       remote desktop), only use it when we know it's valid.  */
>      cap = GetDeviceCaps (hdc, NUMCOLORS);
> +  else
> +    cap = -1;
>  
>    /* We force 24+ bit depths to 24-bit, both to prevent an overflow
>       and because probably is more meaningful on Windows anyway */

Last time we spoke, the conclusion (at least mine ;-) was that it
might be better not to call GetDeviceCaps at all, and instead reuse
the code below this, which uses the number of planes and bits per
plane.  If you agree with that reasoning, could you please see if that
change solves your problem?

In any case, let's separate between this patch and the rest of "w32
GUI with Cygwin" patches, as they are really unrelated.  In
particular, as soon as we agree on this one, you cam go ahead and
commit it regardless of the rest.

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]