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: Daniel Colascione
Subject: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround
Date: Tue, 07 Aug 2012 10:33:23 -0700
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0

On 8/7/12 10:13 AM, Eli Zaretskii wrote:
>> Date: Tue, 07 Aug 2012 01:19:27 -0700
>> From: Daniel Colascione <dancol@dancol.org>
>>
>> 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?

Sorry about that --- I'm bringing a lot of this up form very cold
mental storage. It's been a little while since I've had a chance to do
any Emacs hacking.

I'm perfectly happy using the planes-and-bits code instead of calling
GetDeviceCaps. I'll remove this patch from the cygw32 changeset and
check the (now, much simpler) fix for the colors issue into the trunk,
if that's all right.


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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