Emacs defeats ClearType

Emacs defeats ClearType

[David Abrahams]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]


When ClearType
(http://www.microsoft.com/typography/cleartype/tuner/Step1.aspx) is
enabled on an NT build of Emacs, it's very common for emacs to "slice
off" a few antialiased pixels on either side of a character's vertical
member.  It happens especially in lines that are being typed.  You can
see examples in this sentence of characters whose vertical members
appear to be thin, red lines (image enclosed).

I hope that someone who understands Emacs' internals will be able to
quickly make the fix.  If not, though I am not familiar with Emacs'
internals, I would be willing to attempt a fix if someone can point me
at the right area of the code.


[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 32055 bytes --]

[-- Attachment #3: Type: text/plain, Size: 61 bytes --]


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs defeats ClearType

[jasonr]

Quoting David Abrahams <dave@boost-consulting.com>:

> When ClearType
> (http://www.microsoft.com/typography/cleartype/tuner/Step1.aspx) is
> enabled on an NT build of Emacs, it's very common for emacs to "slice
> off" a few antialiased pixels on either side of a character's vertical
> member.  It happens especially in lines that are being typed.  You can
> see examples in this sentence of characters whose vertical members
> appear to be thin, red lines (image enclosed).

This happens because Windows tells lies about the width of characters when
sub-pixel antialiasing is in effect.

You are welcome to investigate a way around this if you want.

Re: Emacs defeats ClearType

[David Abrahams]

jasonr@f2s.com writes:

> Quoting David Abrahams <dave@boost-consulting.com>:
>
>> When ClearType
>> (http://www.microsoft.com/typography/cleartype/tuner/Step1.aspx) is
>> enabled on an NT build of Emacs, it's very common for emacs to "slice
>> off" a few antialiased pixels on either side of a character's vertical
>> member.  It happens especially in lines that are being typed.  You can
>> see examples in this sentence of characters whose vertical members
>> appear to be thin, red lines (image enclosed).
>
> This happens because Windows tells lies about the width of characters when
> sub-pixel antialiasing is in effect.
>
> You are welcome to investigate a way around this if you want.

I would be happy to.  Can someone at least point me at the source
file(s) that are responsible for character display in NT builds of
emacs, so I know where to start looking?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: Emacs defeats ClearType

[jasonr]

Quoting David Abrahams <dave@boost-consulting.com>:

> jasonr@f2s.com writes:
>
> > Quoting David Abrahams <dave@boost-consulting.com>:
> >
> >> When ClearType
> >> (http://www.microsoft.com/typography/cleartype/tuner/Step1.aspx) is
> >> enabled on an NT build of Emacs, it's very common for emacs to "slice
> >> off" a few antialiased pixels on either side of a character's vertical
> >> member.  It happens especially in lines that are being typed.  You can
> >> see examples in this sentence of characters whose vertical members
> >> appear to be thin, red lines (image enclosed).
> >
> > This happens because Windows tells lies about the width of characters when
> > sub-pixel antialiasing is in effect.
> >
> > You are welcome to investigate a way around this if you want.
>
> I would be happy to.  Can someone at least point me at the source
> file(s) that are responsible for character display in NT builds of
> emacs, so I know where to start looking?

Most of the platform specific display is done in w32term.c, but some functions
in w32fns.c are also involved.

Re: Emacs defeats ClearType

[David Abrahams]

[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]

jasonr@f2s.com writes:

> Quoting David Abrahams <dave@boost-consulting.com>:
>
>> When ClearType
>> (http://www.microsoft.com/typography/cleartype/tuner/Step1.aspx) is
>> enabled on an NT build of Emacs, it's very common for emacs to "slice
>> off" a few antialiased pixels on either side of a character's vertical
>> member.  It happens especially in lines that are being typed.  You can
>> see examples in this sentence of characters whose vertical members
>> appear to be thin, red lines (image enclosed).
>
> This happens because Windows tells lies about the width of characters when
> sub-pixel antialiasing is in effect.
>
> You are welcome to investigate a way around this if you want.

Fantastic; it turned out to be easy.  I have enclosed a patch that
works for me.  The use of those strange #defines

#define W32_spi_getfontsmoothing 0x4A
#define W32_spi_getfontsmoothingtype 0x0200A
#define W32_fe_fontsmoothingcleartype 0x2

is because the use of -D_WIN32_WINNT=0x0400 on the compiler
command-line makes the corresponding MS constants unavailable through
<windows.h>.  I wasn't sure what the best way to handle this stuff
might be -- i.e. what's most consistent with regular Emacs coding
practice.  I would be happy to change the approach in whatever way is
deemed necessary.  I also release all rights to my patch to the FSF.

Incidentally, it seemed to work just fine for me if I remove the
checks for whether cleartype is enabled altogether, and just make the
width adjustments unconditionally.  That would eliminate the issue
with those constants described above and probably make a small
difference in speed.  Seems like a viable option to me.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: w32term.patch --]
[-- Type: text/x-patch, Size: 1197 bytes --]

--- w32term.c	25 Mar 2005 19:19:53 -0500	1.224
+++ w32term.c	03 Jun 2005 11:21:29 -0400	
@@ -903,6 +903,29 @@
 	  int real_width;
 	  GetCharWidth (hdc, *char2b, *char2b, &real_width);
 #endif
+
+          BOOL smoothing_enabled;
+          UINT smoothing_type;
+          
+          /* Attempt to account for ClearType antialiasing.
+           * GetCharABCWidths fails to report the fractional pixels
+           * used for subpixel antialiasing
+           */
+#define W32_spi_getfontsmoothing 0x4A
+#define W32_spi_getfontsmoothingtype 0x0200A
+#define W32_fe_fontsmoothingcleartype 0x2
+          
+          if (SystemParametersInfo(W32_spi_getfontsmoothing, 0, &smoothing_enabled, 0)
+              && smoothing_enabled
+              && SystemParametersInfo(W32_spi_getfontsmoothingtype, 0, &smoothing_type, 0)
+              && smoothing_type == W32_fe_fontsmoothingcleartype
+          )
+          {
+              char_widths.abcA -=1;
+              char_widths.abcB +=2;
+              char_widths.abcC -= 1;
+          }
+          
 	  pcm->width = char_widths.abcA + char_widths.abcB + char_widths.abcC;
 #if 0
 	  /* As far as I can tell, this is the best way to determine what

[-- Attachment #3: Type: text/plain, Size: 61 bytes --]


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs defeats ClearType

[jasonr]

Quoting David Abrahams <dave@boost-consulting.com>:

> Incidentally, it seemed to work just fine for me if I remove the
> checks for whether cleartype is enabled altogether, and just make the
> width adjustments unconditionally.

That is not a good idea. Your patch potentially affects performance, since it
tells lies about the width of characters to counteract the system's lies, and
may make them appear to be wider than their bounding box when they are not. If
a character being redisplayed is detected to be wider than its bounding box,
then the next character needs to be redrawn also, possibly cascading out to the
full line in the worst cases. So we should only tell these lies when we know the
system could be lying.

What would be better is to do the test for Cleartype once per font and cache the
result. Actually, you use a system setting for the test, so if there is not a
way to find out if Cleartype is used for a specific font (I think there is),
then a single test at startup is all that will be needed.

Re: Emacs defeats ClearType

[David Abrahams]

jasonr@f2s.com writes:

> Quoting David Abrahams <dave@boost-consulting.com>:
>
>> Incidentally, it seemed to work just fine for me if I remove the
>> checks for whether cleartype is enabled altogether, and just make the
>> width adjustments unconditionally.
>
> That is not a good idea. Your patch potentially affects performance,
> since it tells lies about the width of characters to counteract the
> system's lies, and may make them appear to be wider than their
> bounding box when they are not. If a character being redisplayed is
> detected to be wider than its bounding box, then the next character
> needs to be redrawn also, possibly cascading out to the full line in
> the worst cases. So we should only tell these lies when we know the
> system could be lying.

Yes, if you're concerned about redrawing the minimum possible number
of characters on a line, you don't want to do that.  I think that's a
needless optimization in most cases, but I'm sure there are machines
and buffers where you can observe a difference in speed.

> What would be better is to do the test for Cleartype once per font
> and cache the result. Actually, you use a system setting for the
> test, so if there is not a way to find out if Cleartype is used for
> a specific font (I think there is), then a single test at startup is
> all that will be needed.

But then you'll pay for your evil lies even when the user turns off
ClearType during an emacs session, and the user who turns on ClearType
during an emacs session will get poor visual results and probably
conclude that Emacs doesn't work with ClearType.

Anyway, please let me know if you want to take what I've done and
massage it yourself or if you'd like me to make specific changes so it
can be integrated into the Emacs sourcebase.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: Emacs defeats ClearType

[Miles Bader]

On 6/7/05, David Abrahams <dave@boost-consulting.com> wrote:
> Yes, if you're concerned about redrawing the minimum possible number
> of characters on a line, you don't want to do that.  I think that's a
> needless optimization in most cases, but I'm sure there are machines
> and buffers where you can observe a difference in speed.

Font metric  bogosities that cause greatly excessive redraw can
definitely result in annoying flickering though, even on machines
which are fast enough that you don't notice the actual redrawing.

[This is the case on X11 anyway; unless the ms-windows port is doing
double-buffering, I expect the same is true there.]

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Emacs defeats ClearType

[David Abrahams]

Miles Bader <snogglethorpe@gmail.com> writes:

> On 6/7/05, David Abrahams <dave@boost-consulting.com> wrote:
>> Yes, if you're concerned about redrawing the minimum possible number
>> of characters on a line, you don't want to do that.  I think that's a
>> needless optimization in most cases, but I'm sure there are machines
>> and buffers where you can observe a difference in speed.
>
> Font metric  bogosities that cause greatly excessive redraw can
> definitely result in annoying flickering though, even on machines
> which are fast enough that you don't notice the actual redrawing.

In that case I think the patch I posted is probably the best we can
do.

> [This is the case on X11 anyway; unless the ms-windows port is doing
> double-buffering, I expect the same is true there.]

I haven't noticed it there. FWIW.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

[PING] ClearType Patch

[David Abrahams]

David Abrahams <dave@boost-consulting.com> writes:

> Anyway, please let me know if you want to take what I've done and
> massage it yourself or if you'd like me to make specific changes so it
> can be integrated into the Emacs sourcebase.

Sorry to be a pest, but as easy as it was, solving this problem did
take significant effort on my part.  I'd like to make sure that

a. Other users can benefit from my work and

b. I don't have to apply the patch again the next time I upgrade my
   Emacs

So could someone please either render a judgement about how the patch
should be changed, or check it in as is, or give me CVS write
permission so I can do it myself?

Thanks,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: [PING] ClearType Patch

[Eli Zaretskii]

> From: David Abrahams <dave@boost-consulting.com>
> Date: Wed, 08 Jun 2005 09:45:16 -0400
> 
> Sorry to be a pest, but as easy as it was, solving this problem did
> take significant effort on my part.

Thank you for your work.

However, with only a few days past, you could have waited a few more
before deciding that your patches were ignored.

> So could someone please either render a judgement about how the patch
> should be changed, or check it in as is, or give me CVS write
> permission so I can do it myself?

I'm bothered by the funky W32_* macros, so I'd like to hear from
people who know more than myself about the intricacies of MSVC and
MinGW whether there's no cleaner way to do this.  Hard-coding macros
from system headers (that's what those #define's are, right?) in Emacs
doesn't sound like a good idea to me.

Also, according to what I see in the MinGW headers, I'm not sure I
understand the problem.  I see SPI_GETFONTSMOOTHING in winuser.h,
whose definition is unaffected by the value of _WIN32_WINNT.  I don't
see the other two constants in the MinGW headers.  So please explain
in more detail the problem that caused you to define your own macros:
what macros you wanted to use, where they are defined, and why the
value of _WIN32_WINNT prevents you from using them.

Finally, MSDN seems to indicate that SPI_GETFONTSMOOTHINGTYPE is
unsupported on Windows 9x, so it sounds like your code should be
disabled for those versions of Windows.

A ChangeLog entry for the patches would also be nice, btw.

Re: [PING] ClearType Patch

[David Abrahams]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Abrahams <dave@boost-consulting.com>
>> Date: Wed, 08 Jun 2005 09:45:16 -0400
>> 
>> Sorry to be a pest, but as easy as it was, solving this problem did
>> take significant effort on my part.
>
> Thank you for your work.
>
> However, with only a few days past, you could have waited a few more
> before deciding that your patches were ignored.

Sorry, but I have a lot on my plate, so once I start waiting a few
more days it's likely to drop off my radar screen.

>> So could someone please either render a judgement about how the patch
>> should be changed, or check it in as is, or give me CVS write
>> permission so I can do it myself?
>
> I'm bothered by the funky W32_* macros, so I'd like to hear from
> people who know more than myself about the intricacies of MSVC and
> MinGW whether there's no cleaner way to do this.  Hard-coding macros
> from system headers (that's what those #define's are, right?) 

Yep.

> in Emacs doesn't sound like a good idea to me.

Agreed, but I think the use of -D_WIN32_WINNT=0x0400 on the compiler
command-line may be similarly bad (and is the reason I transcribed
those constants).

> Also, according to what I see in the MinGW headers, I'm not sure I
> understand the problem.  I see SPI_GETFONTSMOOTHING in winuser.h,
> whose definition is unaffected by the value of _WIN32_WINNT.  

I'm compiling with msvc 7.1; I don't know what MinGW does.

> I don't
> see the other two constants in the MinGW headers.  So please explain
> in more detail the problem that caused you to define your own macros:
> what macros you wanted to use, 

SPI_GETFONTSMOOTHING

  This one is in fact available for _WIN32_WINNT == 0x400; I should
  have used it directly.

SPI_GETFONTSMOOTHINGTYPE
FE_FONTSMOOTHINGCLEARTYPE

  These two are only enabled for _WIN32_WINNT >= 0x0501


> where they are defined,

WinUser.h, IIRC

> and why the value of _WIN32_WINNT prevents you from using them.

Because they are #ifdef'd out when _WIN32_WINNT takes certain values.

> Finally, MSDN seems to indicate that SPI_GETFONTSMOOTHINGTYPE is
> unsupported on Windows 9x, so it sounds like your code should be
> disabled for those versions of Windows.

Right, I should use an #ifdef _WIN32_WINNT >= 0x0501 ... except of
course that the build process subverts that by forcing _WIN32_WINNT to
0x400.

> A ChangeLog entry for the patches would also be nice, btw.

I will be happy to write one.  I assume the format to follow is used
in the ChangeLog file at the top of emacs' CVS tree?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: [PING] ClearType Patch

[Stefan Monnier]

> Sorry, but I have a lot on my plate, so once I start waiting a few
> more days it's likely to drop off my radar screen.

I know exactly how that feels.  I have about 1MB of local hacks, which have
all "fallen off the radar": I use them but they're not clean enough to
be installed.

>> Finally, MSDN seems to indicate that SPI_GETFONTSMOOTHINGTYPE is
>> unsupported on Windows 9x, so it sounds like your code should be
>> disabled for those versions of Windows.

> Right, I should use an #ifdef _WIN32_WINNT >= 0x0501 ... except of
> course that the build process subverts that by forcing _WIN32_WINNT to
> 0x400.

I don't use w32 and I know nothing about its APIs, so I don't know how best
to solve the conflict between the -D_WIN32_WINNT=0x0400 and your duplicate
defines, but I think that if the code is left as you've written it, you
should explain it in the code (rather than in this thread) with a comment.
Such a comment can also be used to vent any frustration you may have at
the -D_WIN32_WINNT=0x0400 flag.

This said, I hope some version of your patch will be installed because
I find the truncation of anti-aliased glyphs (which I have noticed the few
rare times I've used NTEmacs) isn't just ugly but makes the use of small
fonts more painful (I love small fonts and find that the ability to use
smaller fonts is one of the main benefits of anti-aliasing).

> I will be happy to write one.  I assume the format to follow is used
> in the ChangeLog file at the top of emacs' CVS tree?

IIRC it's documented in the Emacs manual, but follow the examples in
src/ChangeLog.  Basically: use the present tense and active forms, capitals
after the ":" and don't forget the terminating ".".  Use C-x 4 a (from the
locations in the source code or from the corresponding diff-mode buffer) to
help you write the entries.


        Stefan

Re: [PING] ClearType Patch

[David Abrahams]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> This said, I hope some version of your patch will be installed because
> I find the truncation of anti-aliased glyphs (which I have noticed the few
> rare times I've used NTEmacs) isn't just ugly but makes the use of small
> fonts more painful (I love small fonts and find that the ability to use
> smaller fonts is one of the main benefits of anti-aliasing).

For me it's a similar issue: when the fonts I use are not enormous
(like, anywhere below 14 pt), the lines are too skinny to read
comfortably unless I turn on ClearType.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: [PING] ClearType Patch

[Eli Zaretskii]

> From: David Abrahams <dave@boost-consulting.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 08 Jun 2005 11:46:58 -0400
> 
> Sorry, but I have a lot on my plate, so once I start waiting a few
> more days it's likely to drop off my radar screen.

We all need to cope with this.

> Agreed, but I think the use of -D_WIN32_WINNT=0x0400 on the compiler
> command-line may be similarly bad (and is the reason I transcribed
> those constants).

Jason, could you perhaps tell why this compiler switch is used?  If
that is because we don't want to use features that are unavailable in
older versions of Windows, we could replace that with run-time checks,
like the one I suggest below, can't we?

> SPI_GETFONTSMOOTHING
> 
>   This one is in fact available for _WIN32_WINNT == 0x400; I should
>   have used it directly.
> 
> SPI_GETFONTSMOOTHINGTYPE
> FE_FONTSMOOTHINGCLEARTYPE
> 
>   These two are only enabled for _WIN32_WINNT >= 0x0501
> 
> 
> > where they are defined,
> 
> WinUser.h, IIRC

The MinGW version of winuser.h doesn't have them; perhaps that's a
MinGW bug.  So I think we need to condition the code on
SPI_GETFONTSMOOTHINGTYPE being defined, or perhaps provide a fallback
definition in src/s/ms-w32.h for MinGW.

> > Finally, MSDN seems to indicate that SPI_GETFONTSMOOTHINGTYPE is
> > unsupported on Windows 9x, so it sounds like your code should be
> > disabled for those versions of Windows.
> 
> Right, I should use an #ifdef _WIN32_WINNT >= 0x0501 ... except of
> course that the build process subverts that by forcing _WIN32_WINNT to
> 0x400.

I meant a run-time check, not a compile-time check (because Emacs
built on XP could then be run on Windows 98, for example: think binary
releases).  We have a global variable os_subtype which can be used for
such a run-time test, I think.

> > A ChangeLog entry for the patches would also be nice, btw.
> 
> I will be happy to write one.  I assume the format to follow is used
> in the ChangeLog file at the top of emacs' CVS tree?

Yes.  And in addition, the GNU Coding Standards (standards.texi) which
you can find on the GNU Web site, has a section about writing
ChangeLog entries.

TIA

Re: [PING] ClearType Patch

[David Abrahams]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Abrahams <dave@boost-consulting.com>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 08 Jun 2005 11:46:58 -0400
>> 
>> Sorry, but I have a lot on my plate, so once I start waiting a few
>> more days it's likely to drop off my radar screen.
>
> We all need to cope with this.

I know.  If it drops off my radar and off your radar, it's really
gone, isn't it?  ;->

Look, I wasn't rude (I don't think) and everyone is free to ignore me
if they need to.

>> Agreed, but I think the use of -D_WIN32_WINNT=0x0400 on the compiler
>> command-line may be similarly bad (and is the reason I transcribed
>> those constants).
>
> Jason, could you perhaps tell why this compiler switch is used?  If
> that is because we don't want to use features that are unavailable in
> older versions of Windows, we could replace that with run-time checks,
> like the one I suggest below, can't we?

Seems like a good idea to get a compiler error if possible.  OTOH it
does make using more advanced features, even when protected by runtime
checks, unreasonably difficult and messy.  Also the name _WIN32_WINNT
is reserved to the implementation and unless we're given specific
permission to #define it, doing so is ill.  FWIW.  I don't know
whether that permission is granted for _WIN32_WINNT.

>> SPI_GETFONTSMOOTHING
>> 
>>   This one is in fact available for _WIN32_WINNT == 0x400; I should
>>   have used it directly.
>> 
>> SPI_GETFONTSMOOTHINGTYPE
>> FE_FONTSMOOTHINGCLEARTYPE
>> 
>>   These two are only enabled for _WIN32_WINNT >= 0x0501
>> 
>> 
>> > where they are defined,
>> 
>> WinUser.h, IIRC
>
> The MinGW version of winuser.h doesn't have them; perhaps that's a
> MinGW bug.  So I think we need to condition the code on
> SPI_GETFONTSMOOTHINGTYPE being defined, or perhaps provide a fallback
> definition in src/s/ms-w32.h for MinGW.

The latter seems better.  Why should people who get a MinGW-compiled
executable suffer ugly characters?

>> > Finally, MSDN seems to indicate that SPI_GETFONTSMOOTHINGTYPE is
>> > unsupported on Windows 9x, so it sounds like your code should be
>> > disabled for those versions of Windows.
>> 
>> Right, I should use an #ifdef _WIN32_WINNT >= 0x0501 ... except of
>> course that the build process subverts that by forcing _WIN32_WINNT to
>> 0x400.
>
> I meant a run-time check, not a compile-time check (because Emacs
> built on XP could then be run on Windows 98, for example: think binary
> releases).  

Ah, of course.  But on second thought, I considered this question when
I wrote the code. The calls will return an error on Win98 anyway
because the constants are unsupported, and most of the code will be
skipped.  Unless you're concerned about optimizing away the call into
Windows altogether (which I'm guessing is not worth the complication),
you don't need an explicit check.

> We have a global variable os_subtype which can be used for such a
> run-time test, I think.

When we settle what to do about the #defines I will submit a new
patch...

>> > A ChangeLog entry for the patches would also be nice, btw.
>> 
>> I will be happy to write one.  I assume the format to follow is used
>> in the ChangeLog file at the top of emacs' CVS tree?
>
> Yes.  And in addition, the GNU Coding Standards (standards.texi) which
> you can find on the GNU Web site, has a section about writing
> ChangeLog entries.

...including one for the ChangeLog

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: [PING] ClearType Patch

[jasonr]

Quoting David Abrahams <dave@boost-consulting.com>:

> Look, I wasn't rude (I don't think)

Not rude, just impatient :-)

> Also the name _WIN32_WINNT
> is reserved to the implementation and unless we're given specific
> permission to #define it, doing so is ill.  FWIW.  I don't know
> whether that permission is granted for _WIN32_WINNT.

The compiler is our tool. We do not need permission from anyone to make it do
what we need it to do.

Re: [PING] ClearType Patch

[jasonr]

Quoting Eli Zaretskii <eliz@gnu.org>:

> > Agreed, but I think the use of -D_WIN32_WINNT=0x0400 on the compiler
> > command-line may be similarly bad (and is the reason I transcribed
> > those constants).
>
> Jason, could you perhaps tell why this compiler switch is used?  If
> that is because we don't want to use features that are unavailable in
> older versions of Windows, we could replace that with run-time checks,
> like the one I suggest below, can't we?

It is so we don't use new features ACCIDENTALLY. The runtime checks for old
versions of Windows only work if you know to use them, it is better to do
runtime checks for new versions and have the compiler pick up most of the
accidental uses of new features.

Often things that are only defined for _WIN32_WINNT > 0x0400 are not defined in
the mingw headers, so we need to provide our own definitions anyway. I do think
it makes it easier for future developers if we use the standard constant names
instead of inventing our own though, so

#ifndef SPI_GETFONTSMOOTHINGTYPE
#define SPI_GETFONTSMOOTHINGTYPE 0x0200A
#endif

Usually the system calls are pretty good about returning an error rather than
crashing if you try to use an unsupported feature, so a good runtime check is
to check the return value of the function being called. There are many optional
addons to Windows 95 that add extra functionality (like full Unicode APIs), so
checking os_subtype is an inferior test IMHO - like testing system-type instead
of featurep.

I am worried about the performance impact of making two system calls to query
the configuration potentially every time a character is output (there is some
limited caching for ASCII, but Asian and East European languages that use
completely different scripts especially will suffer). I think performance in
this case is more important than the rare case where a user changes their
system settings during an Emacs session and starts seeing the display problems
(which are really nothing more than a minor annoyance), so I'd be happier
moving the check for Cleartype into w32_initialize() and just checking a file
scope variable in w32_native_per_char_metric()

Re: [PING] ClearType Patch

[David Abrahams]

jasonr@f2s.com writes:

> Often things that are only defined for _WIN32_WINNT > 0x0400 are not defined in
> the mingw headers, so we need to provide our own definitions anyway. I do think
> it makes it easier for future developers if we use the standard constant names
> instead of inventing our own though, so
>
> #ifndef SPI_GETFONTSMOOTHINGTYPE
> #define SPI_GETFONTSMOOTHINGTYPE 0x0200A
> #endif

Makes sense.  I just didn't know how close this was, legally speaking,
to copying MS code into GPL'd code, and didn't want to risk it.  But
if you say it's fine, I'm happy.

> Usually the system calls are pretty good about returning an error rather than
> crashing if you try to use an unsupported feature, so a good runtime check is
> to check the return value of the function being called. There are many optional
> addons to Windows 95 that add extra functionality (like full Unicode APIs), so
> checking os_subtype is an inferior test IMHO - like testing system-type instead
> of featurep.
>
> I am worried about the performance impact of making two system calls to query
> the configuration potentially every time a character is output (there is some
> limited caching for ASCII, but Asian and East European languages that use
> completely different scripts especially will suffer). I think performance in
> this case is more important than the rare case where a user changes their
> system settings during an Emacs session and starts seeing the display problems
> (which are really nothing more than a minor annoyance), 

Unless you happen to actually use ClearType, in which case it's
killer.

> so I'd be happier moving the check for Cleartype into
> w32_initialize() and just checking a file scope variable in
> w32_native_per_char_metric()

Is there some appropriate windows event (like "application just came
to the foreground", however you spell that in Wind-ese) that we can
use to check the state and set the global?  That would be close to
perfect.  If not, I'll be happy to check once in w32_initialize.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: [PING] ClearType Patch

[jasonr]

Quoting David Abrahams <dave@boost-consulting.com>:

> > #ifndef SPI_GETFONTSMOOTHINGTYPE
> > #define SPI_GETFONTSMOOTHINGTYPE 0x0200A
> > #endif
>
> Makes sense.  I just didn't know how close this was, legally speaking,
> to copying MS code into GPL'd code, and didn't want to risk it.  But
> if you say it's fine, I'm happy.

To be safe, I would write the code from the API documentation, not copy from the
headers ;-) Or if the constants are in mingw headers, copy from there.

> > (which are really nothing more than a minor annoyance),
>
> Unless you happen to actually use ClearType, in which case it's
> killer.

Killer implies that Emacs crashes or is otherwise unusable. In this case, a few
characters (w and m mainly, or italics) have slightly thinner lines at the
edges, since we are clipping pixels that the system claims are not there.

>
> > so I'd be happier moving the check for Cleartype into
> > w32_initialize() and just checking a file scope variable in
> > w32_native_per_char_metric()
>
> Is there some appropriate windows event (like "application just came
> to the foreground", however you spell that in Wind-ese)

There is a configuration change event that we could use to reevaluate all our
settings that are made from system configuration. There are others that could
benefit from this as well (system colors, scroll bar widths for example).

Re: [PING] ClearType Patch

[Eli Zaretskii]

> Date: Thu,  9 Jun 2005 09:10:28 +0100
> From: jasonr@f2s.com
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> Quoting David Abrahams <dave@boost-consulting.com>:
> 
> > > #ifndef SPI_GETFONTSMOOTHINGTYPE
> > > #define SPI_GETFONTSMOOTHINGTYPE 0x0200A
> > > #endif
> >
> > Makes sense.  I just didn't know how close this was, legally speaking,
> > to copying MS code into GPL'd code, and didn't want to risk it.  But
> > if you say it's fine, I'm happy.
> 
> To be safe, I would write the code from the API documentation, not copy from the
> headers ;-) Or if the constants are in mingw headers, copy from there.
> 
> > > (which are really nothing more than a minor annoyance),
> >
> > Unless you happen to actually use ClearType, in which case it's
> > killer.
> 
> Killer implies that Emacs crashes or is otherwise unusable. In this case, a few
> characters (w and m mainly, or italics) have slightly thinner lines at the
> edges, since we are clipping pixels that the system claims are not there.
> 
> >
> > > so I'd be happier moving the check for Cleartype into
> > > w32_initialize() and just checking a file scope variable in
> > > w32_native_per_char_metric()
> >
> > Is there some appropriate windows event (like "application just came
> > to the foreground", however you spell that in Wind-ese)
> 
> There is a configuration change event that we could use to reevaluate all our
> settings that are made from system configuration. There are others that could
> benefit from this as well (system colors, scroll bar widths for example).

David, if it is now clear to you, based on these and other comments
from Jason, how to write an improved patch, please post it here and I
will install it.

If you still have questions, please ask here.

TIA

Re: [PING] ClearType Patch

[David Abrahams]

Eli Zaretskii <eliz@gnu.org> writes:

> David, if it is now clear to you, based on these and other comments
> from Jason, how to write an improved patch, please post it here and I
> will install it.

It's close, thanks.

> If you still have questions, please ask here.

I am seeing some minor artifacts that I don't know what to do about.
For example, when I backspace over these parens starting from the end
of the line, I end up with some small remnants of the background color
emacs uses to highlight matching parens for me.  When all the close
parens are gone there's a thin vertical cyan line at the right edge of
each open paren.  Any clues where to attack that?

((((()))))

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: [PING] ClearType Patch

[David Abrahams]

David Abrahams <dave@boost-consulting.com> writes:

> I am seeing some minor artifacts that I don't know what to do about.
> For example, when I backspace over these parens starting from the end
> of the line, I end up with some small remnants of the background color
> emacs uses to highlight matching parens for me.  When all the close
> parens are gone there's a thin vertical cyan line at the right edge of
> each open paren.  Any clues where to attack that?
>
> ((((()))))

Even some vague hints would be a big help here.  This is the only
remaining detail as far as I can tell.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: [PING] ClearType Patch

[David Abrahams]

David Abrahams <dave@boost-consulting.com> writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> I am seeing some minor artifacts that I don't know what to do about.
>> For example, when I backspace over these parens starting from the end
>> of the line, I end up with some small remnants of the background color
>> emacs uses to highlight matching parens for me.  When all the close
>> parens are gone there's a thin vertical cyan line at the right edge of
>> each open paren.  Any clues where to attack that?
>>
>> ((((()))))
>
> Even some vague hints would be a big help here.  This is the only
> remaining detail as far as I can tell.

I have one more piece of information for anyone who can think about
this problem for a moment: When I do `C-s x', the first instance of x
(or whatever character) that is found gets highlighted in purple and
looks right.  The next instance of x on that line gets highlighted in
cyan and looks right.  The rest of the instances of x on that line get
highlighted in cyan, and the highlighting extends one pixel too far to
the left.  On each line thereafter, the first instance of x is
highlighted in cyan and looks right, and the rest of the instances on
that line are highlighted in cyan and look wrong (i.e. the
highlighting extends one pixel too far to nthe left).

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

How is highlighting done in show-paren-mode?

[David Abrahams]

This concerns the one remaining problem with the ClearType patch I'm
trying to clean up and submit.  I hope I don't seem too insistent, but
I've been trying to get a hint for about a week.

David Abrahams <dave@boost-consulting.com> writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> David Abrahams <dave@boost-consulting.com> writes:
>>
>>> I am seeing some minor artifacts that I don't know what to do about.
>>> For example, when I backspace over these parens starting from the end
>>> of the line, I end up with some small remnants of the background color
>>> emacs uses to highlight matching parens for me.  When all the close
>>> parens are gone there's a thin vertical cyan line at the right edge of
>>> each open paren.  Any clues where to attack that?
>>>
>>> ((((()))))
>>
>> Even some vague hints would be a big help here.  This is the only
>> remaining detail as far as I can tell.
>
> I have one more piece of information for anyone who can think about
> this problem for a moment: When I do `C-s x', the first instance of x
> (or whatever character) that is found gets highlighted in purple and
> looks right.  The next instance of x on that line gets highlighted in
> cyan and looks right.  The rest of the instances of x on that line get
> highlighted in cyan, and the highlighting extends one pixel too far to
> the left.  On each line thereafter, the first instance of x is
> highlighted in cyan and looks right, and the rest of the instances on
> that line are highlighted in cyan and look wrong (i.e. the
> highlighting extends one pixel too far to the left).

Can someone please give me some hint as to which entry points to
breakpoint in order to observe these calculations and/or drawing in
action?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Who can explain the display architecture?

[David Abrahams]

I am trying to get a clue as to how this stuff is organized so that I
can fix the problems described below.  Thanks for your attention.

David Abrahams <dave@boost-consulting.com> writes:

> This concerns the one remaining problem with the ClearType patch I'm
> trying to clean up and submit.  I hope I don't seem too insistent, but
> I've been trying to get a hint for about a week.
>
> David Abrahams <dave@boost-consulting.com> writes:
>
>> David Abrahams <dave@boost-consulting.com> writes:
>>
>>> David Abrahams <dave@boost-consulting.com> writes:
>>>
>>>> I am seeing some minor artifacts that I don't know what to do about.
>>>> For example, when I backspace over these parens starting from the end
>>>> of the line, I end up with some small remnants of the background color
>>>> emacs uses to highlight matching parens for me.  When all the close
>>>> parens are gone there's a thin vertical cyan line at the right edge of
>>>> each open paren.  Any clues where to attack that?
>>>>
>>>> ((((()))))
>>>
>>> Even some vague hints would be a big help here.  This is the only
>>> remaining detail as far as I can tell.
>>
>> I have one more piece of information for anyone who can think about
>> this problem for a moment: When I do `C-s x', the first instance of x
>> (or whatever character) that is found gets highlighted in purple and
>> looks right.  The next instance of x on that line gets highlighted in
>> cyan and looks right.  The rest of the instances of x on that line get
>> highlighted in cyan, and the highlighting extends one pixel too far to
>> the left.  On each line thereafter, the first instance of x is
>> highlighted in cyan and looks right, and the rest of the instances on
>> that line are highlighted in cyan and look wrong (i.e. the
>> highlighting extends one pixel too far to the left).
>
> Can someone please give me some hint as to which entry points to
> breakpoint in order to observe these calculations and/or drawing in
> action?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: Who can explain the display architecture?

[Kim F. Storm]

David Abrahams <dave@boost-consulting.com> writes:

> I am trying to get a clue as to how this stuff is organized so that I
> can fix the problems described below.  Thanks for your attention.
>

These's a general overview at the top of src/xdisp.c .

Also look at the data structures in dispextern.h.

And then study the source code ...

In any case, display artifact are typically the result of bugs in the
platform specific files, i.e. xterm.c, w32term.c or macterm.c.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [PING] ClearType Patch

[Stefan Monnier]

> completely different scripts especially will suffer). I think performance in
> this case is more important than the rare case where a user changes their
> system settings during an Emacs session and starts seeing the display problems
> (which are really nothing more than a minor annoyance), so I'd be happier
> moving the check for Cleartype into w32_initialize() and just checking a file
> scope variable in w32_native_per_char_metric()

If you care about changes mid-session, you can check it at each redisplay.
Should be both cheap enough and frequent enough.


        Stefan