23.0.60;show-paren-mode causes abnormal vertical lines on Win32.

23.0.60;show-paren-mode causes abnormal vertical lines on Win32.

[=?gb18030?B?0+G94A==?=]

testcase:
()
^
point
Your point is on the open paren. Emacs highlights the open and close
parens. If you try to input letters now, some letters will begin with
a abnormal vertical line, especial for letters 'f' and 'm'. The lines
have the save color as the background of the highlighted paren.





In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-02-14 on WASP-8DB7BB213F
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: zh_CN
  value of $XMODIFIERS: nil
  locale-coding-system: cp936
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
M-x b u g SPC r <backspace> <backspace> <backspace> 
<backspace> r e p o r SPC b u SPC <backspace> = <backspace> 
<backspace> e SPC SPC <return>

Recent messages:
Warning: Default coding system `chinese-iso-8bit' disagrees with
system codeset `cp936' for this locale.
Loading e:/emacs23/site-lisp/color-theme-el/themes/color-theme-autoloads.elc...done
Loading e:/emacs23/site-lisp/color-theme-el/themes/color-theme-example.el (source)...done
Loading e:/emacs23/site-lisp/color-theme-el/themes/color-theme-example.elc...done
Loading e:/emacs23/site-lisp/color-theme-el/themes/color-theme-library.el (source)...done
Loading e:/emacs23/site-lisp/color-theme-el/themes/color-theme-library.elc...done
Loading e:/emacs23/site-lisp/color-theme-el/themes/color-theme.elc...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Re: 23.0.60; show-paren-mode causes abnormal vertical lines on Win32.

[Jason Rumney]

俞洁 wrote:
> testcase:
> ()
> ^
> point
> Your point is on the open paren. Emacs highlights the open and close
> parens. If you try to input letters now, some letters will begin with
> a abnormal vertical line, especial for letters 'f' and 'm'. The lines
> have the save color as the background of the highlighted paren.
>
>
>
> In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
>   
> configured using `configure --with-gcc (3.4)'
>   

Please try with `configure --with-gcc --enable-font-backend'

If the bug is only in the old font backend, and only in Emacs 23.0.60, 
then it won't be worth fixing.

Re: 23.0.60; show-paren-mode causes abnormal vertical lines on Win32.

[Stefan Monnier]

> If the bug is only in the old font backend, and only in Emacs 23.0.60, then
> it won't be worth fixing.

If that's really how we treat such bugs, then we absolutely need to
make --enable-font-backend the default.


        Stefan "who wouldn't disagree with such a decision"

Re: 23.0.60; show-paren-mode causes abnormal vertical lines on Win32.

[Jason Rumney]

Stefan Monnier wrote:
>> If the bug is only in the old font backend, and only in Emacs 23.0.60, then
>> it won't be worth fixing.
>>     
>
> If that's really how we treat such bugs, then we absolutely need to
> make --enable-font-backend the default.
>   
It will be the default before the release of 23.1. And the old code will 
be removed if I understand correctly, so what point is there in fixing 
minor bugs in it now?

Re: 23.0.60; show-paren-mode causes abnormal vertical lines on Win32.

[Juanma Barranquero]

On Feb 15, 2008 10:44 PM, Jason Rumney <jasonr@gnu.org> wrote:

> And the old code will
> be removed if I understand correctly, so what point is there in fixing
> minor bugs in it now?

As I see it, that is an argument for making the new backend the
default now, not "before the release of 23.1"...

             Juanma

Re: 23.0.60; show-paren-mode causes abnormal vertical lines on Win32.

[Jason Rumney]

yu jie wrote:
> Yes, the bug is only in the old font backend.

I followed your recipe on Emacs 22, and found it was not restricted to
the trunk though.

This problem seems to be related to other Cleartype bugs. Andrew Ng sent
a full patch for these some time ago, but I don't know if his paperwork
has arrived yet. But for this specific problem, I have come up with a
much smaller fix in the meantime. It also appears to fix the overlay
problem reported by Drew Adams 18 months ago.

RE: 23.0.60; show-paren-mode causes abnormal vertical lines on Win32.

[Drew Adams]

> It also appears to fix the overlay
> problem reported by Drew Adams 18 months ago.

Good news; thanks.

Re: 23.0.60; show-paren-mode causes abnormal vertical lines on Win32.

[Jason Rumney]

Juanma Barranquero wrote:
> On Feb 15, 2008 10:44 PM, Jason Rumney <jasonr@gnu.org> wrote:
>
>   
>> And the old code will
>> be removed if I understand correctly, so what point is there in fixing
>> minor bugs in it now?
>>     
>
> As I see it, that is an argument for making the new backend the
> default now, not "before the release of 23.1"...
>   

There are also arguments against that, such as the fact that the new 
backend does not seem to have stabilised yet, with problems like Stefan 
is experiencing now, and which Windows users suffered around the time of 
the merge still a frequent occurrence.

Re: 23.0.60; show-paren-mode causes abnormal vertical lines on Win32.

[Juanma Barranquero]

On Feb 16, 2008 12:16 AM, Jason Rumney <jasonr@gnu.org> wrote:

> There are also arguments against that, such as the fact that the new
> backend does not seem to have stabilised yet, with problems like Stefan
> is experiencing now, and which Windows users suffered around the time of
> the merge still a frequent occurrence.

I know. But nobody ever said the trunk should be stable at all times.
(I use the trunk, I want it to be stable; but I think it's more
important to make the feature available by default sooner so it is
more widely tested.)

Just my 0.02€

             Juanma

font-backend [was Re: 23.0.60; show-paren-mode causes abnormal vertical lines on Win32.]

[Glenn Morris]

"Juanma Barranquero" wrote:

> On Feb 16, 2008 12:16 AM, Jason Rumney <jasonr@gnu.org> wrote:
>
>> There are also arguments against that, such as the fact that the new
>> backend does not seem to have stabilised yet, with problems like Stefan
>> is experiencing now, and which Windows users suffered around the time of
>> the merge still a frequent occurrence.
>
> I know. But nobody ever said the trunk should be stable at all times.
> (I use the trunk, I want it to be stable; but I think it's more
> important to make the feature available by default sooner so it is
> more widely tested.)

Nobody ever answered Eli's question, AFAIK:

http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg00089.html

  Can someone "in the know" please post an explanation of the
  font-backend feature, and what are its advantages/disadvantages?

Re: font-backend

[Miles Bader]

Glenn Morris <rgm@gnu.org> writes:
> Nobody ever answered Eli's question, AFAIK:
>
> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg00089.html
>
>   Can someone "in the know" please post an explanation of the
>   font-backend feature, and what are its advantages/disadvantages?

The reason most people seem to use it (and I think just about
_everybody_ who I've seen mention building unicode-branch or post-merge
emacs, seems to) because they want anti-aliased fonts.

Some other advantages might be better integration with modern
client-side font mechanisms, particularly font-selection, instead of
using the traditional (and largely regarded as "crufty") X font
mechanism.

I dunno if any of that applies to Eli, if he uses windows.

-Miles

-- 
Friendship, n. A ship big enough to carry two in fair weather, but only one
in foul.

Re: 23.0.60; show-paren-mode causes abnormal vertical lines on Win32.

[Stefan Monnier]

>>> And the old code will
>>> be removed if I understand correctly, so what point is there in fixing
>>> minor bugs in it now?
>> As I see it, that is an argument for making the new backend the
>> default now, not "before the release of 23.1"...
> There are also arguments against that, such as the fact that the new backend
> does not seem to have stabilised yet, with problems like Stefan is
> experiencing now, and which Windows users suffered around the time of the
> merge still a frequent occurrence.

If we want it to be the default for 23.1, and given that it works now
and is merged into the trunk, I see no reason not to make it the default
now, so that bugs get found and fixed earlier rather than later.

Any objection to making the "--enable-font-backend" the default?


        Stefan


PS: For what it's worth, I have no idea if my problem appears with the "old
font backend" as well or not.  And if nobody wants to fix it there,
I see no reason to look into it.

Re: 23.0.60; show-paren-mode causes abnormal vertical lines on Win32.

[Dan Nicolaescu]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > >>> And the old code will
  > >>> be removed if I understand correctly, so what point is there in fixing
  > >>> minor bugs in it now?
  > >> As I see it, that is an argument for making the new backend the
  > >> default now, not "before the release of 23.1"...
  > > There are also arguments against that, such as the fact that the new backend
  > > does not seem to have stabilised yet, with problems like Stefan is
  > > experiencing now, and which Windows users suffered around the time of the
  > > merge still a frequent occurrence.
  > 
  > If we want it to be the default for 23.1, and given that it works now
  > and is merged into the trunk, I see no reason not to make it the default
  > now, so that bugs get found and fixed earlier rather than later.
  > 
  > Any objection to making the "--enable-font-backend" the default?

It does not work very well with emacsclient

emacs -Q -nw -f server-start
emacsclient -c ~/.emacs
C-x 5 0   in the emacsclient frame
After that
emacsclient -c ~/.emacs
just hangs.

Re: font-backend

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Sat, 16 Feb 2008 08:47:11 +0900
> Cc: Juanma Barranquero <lekktu@gmail.com>, Jason Rumney <jasonr@gnu.org>,
> 	emacs-devel@gnu.org
> 
> Glenn Morris <rgm@gnu.org> writes:
> > Nobody ever answered Eli's question, AFAIK:
> >
> > http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg00089.html
> >
> >   Can someone "in the know" please post an explanation of the
> >   font-backend feature, and what are its advantages/disadvantages?
> 
> The reason most people seem to use it (and I think just about
> _everybody_ who I've seen mention building unicode-branch or post-merge
> emacs, seems to) because they want anti-aliased fonts.
> 
> Some other advantages might be better integration with modern
> client-side font mechanisms, particularly font-selection, instead of
> using the traditional (and largely regarded as "crufty") X font
> mechanism.

Thanks, but I also asked about disadvantages.  TANSTAAFL, and I
believe this case is no exception.

> I dunno if any of that applies to Eli, if he uses windows.

Why would this be any different on Windows?

Re: font-backend

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> I dunno if any of that applies to Eli, if he uses windows.
>
> Why would this be any different on Windows?

'cause (1) I thought anti-aliased fonts were already available on
windows, and (2) at least one of the obvious benefits on gnu/linux, the
use of "fontconfig" (a widely used client-side font configuration
mechanism), seems like it wouldn't apply to windows, which I presume(d)
uses a windows specific font-configuration mechanism.

I could obviously be wrong about these, as I rarely use Emacs on
windows.

-Miles

-- 
Success, n. The one unpardonable sin against one's fellows.

Re: font-backend

[Jason Rumney]

Eli Zaretskii wrote:
> Thanks, but I also asked about disadvantages.  TANSTAAFL, and I
> believe this case is no exception.
>   

It has had about 15 years less testing.
It is noticably slower on Windows (not sure about other platforms)
There is no BDF font support on Windows (yet - it will be a cleaner 
implementation though, with a separate backend)


>   
>> I dunno if any of that applies to Eli, if he uses windows.
>>     
>
> Why would this be any different on Windows?
>   

The antialiasing advantage does not apply to Windows, since antialiasing 
does not depend on the APIs used for drawing text.

Re: 23.0.60; show-paren-mode causes abnormal vertical lines on Win32.

[yu jie]

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

Hi,
This bug is only in the old font backend, but you said that the new font
backend is slower on Windows. I have noticed that. Lines of the buffer will
blink when I enable the new font backend. Is there any plan to speed up it
on Windows?
Thanks.

On Feb 15, 2008 5:12 PM, Jason Rumney <jasonr@gnu.org> wrote:

> 俞洁 wrote:
> > testcase:
> > ()
> > ^
> > point
> > Your point is on the open paren. Emacs highlights the open and close
> > parens. If you try to input letters now, some letters will begin with
> > a abnormal vertical line, especial for letters 'f' and 'm'. The lines
> > have the save color as the background of the highlighted paren.
> >
> >
> >
> > In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
> >
> > configured using `configure --with-gcc (3.4)'
> >
>
> Please try with `configure --with-gcc --enable-font-backend'
>
> If the bug is only in the old font backend, and only in Emacs 23.0.60,
> then it won't be worth fixing.
>
>

[-- Attachment #2: Type: text/html, Size: 1385 bytes --]

Re: font-backend

[Kenichi Handa]

In article <uodahkpjy.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > >   Can someone "in the know" please post an explanation of the
> > >   font-backend feature, and what are its advantages/disadvantages?
> > 
> > The reason most people seem to use it (and I think just about
> > _everybody_ who I've seen mention building unicode-branch or post-merge
> > emacs, seems to) because they want anti-aliased fonts.
> > 
> > Some other advantages might be better integration with modern
> > client-side font mechanisms, particularly font-selection, instead of
> > using the traditional (and largely regarded as "crufty") X font
> > mechanism.

I think the biggest advantage is the Emacs can use OTF with
the font-backend mechanism.  For such script as Indic, it's
vital matter.


> Thanks, but I also asked about disadvantages.

Once the code gets stable, I think there's no disadvantage.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: 23.0.60; show-paren-mode causes abnormal vertical lines on Win32.

[Richard Stallman]

    If we want it to be the default for 23.1, and given that it works now
    and is merged into the trunk, I see no reason not to make it the default
    now, so that bugs get found and fixed earlier rather than later.

I agree with that logic.

Re: 23.0.60; show-paren-mode causes abnormal vertical lines on Win32.

[Stefan Monnier]

>> >>> And the old code will
>> >>> be removed if I understand correctly, so what point is there in fixing
>> >>> minor bugs in it now?
>> >> As I see it, that is an argument for making the new backend the
>> >> default now, not "before the release of 23.1"...
>> > There are also arguments against that, such as the fact that the new backend
>> > does not seem to have stabilised yet, with problems like Stefan is
>> > experiencing now, and which Windows users suffered around the time of the
>> > merge still a frequent occurrence.
>> 
>> If we want it to be the default for 23.1, and given that it works now
>> and is merged into the trunk, I see no reason not to make it the default
>> now, so that bugs get found and fixed earlier rather than later.
>> 
>> Any objection to making the "--enable-font-backend" the default?

> It does not work very well with emacsclient

> emacs -Q -nw -f server-start
> emacsclient -c ~/.emacs
> C-x 5 0   in the emacsclient frame
> After that
> emacsclient -c ~/.emacs
> just hangs.

Works just fine for me,


        Stefan

Re: 23.0.60; show-paren-mode causes abnormal vertical lines on Win32.

[Dan Nicolaescu]

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

  > >> >>> And the old code will
  > >> >>> be removed if I understand correctly, so what point is there in fixing
  > >> >>> minor bugs in it now?
  > >> >> As I see it, that is an argument for making the new backend the
  > >> >> default now, not "before the release of 23.1"...
  > >> > There are also arguments against that, such as the fact that the new backend
  > >> > does not seem to have stabilised yet, with problems like Stefan is
  > >> > experiencing now, and which Windows users suffered around the time of the
  > >> > merge still a frequent occurrence.
  > >> 
  > >> If we want it to be the default for 23.1, and given that it works now
  > >> and is merged into the trunk, I see no reason not to make it the default
  > >> now, so that bugs get found and fixed earlier rather than later.
  > >> 
  > >> Any objection to making the "--enable-font-backend" the default?
  > 
  > > It does not work very well with emacsclient
  > 
  > > emacs -Q -nw -f server-start
  > > emacsclient -c ~/.emacs
  > > C-x 5 0   in the emacsclient frame
  > > After that
  > > emacsclient -c ~/.emacs
  > > just hangs.
  > 
  > Works just fine for me,

Yep, Handa-san fixed it a few days ago.

Re: font-backend

[finalpatch]

Kenichi Handa <handa <at> m17n.org> writes:

>  In article <uodahkpjy.fsf <at> gnu.org>, Eli Zaretskii <eliz <at>
> gnu.org> writes: > > > Can someone "in the know" please post an
> explanation of the > > > font-backend feature, and what are its
> advantages/disadvantages?  > > > > The reason most people seem to use it
> (and I think just about > > _everybody_ who I've seen mention building
> unicode-branch or post-merge > > emacs, seems to) because they want
> anti-aliased fonts.  > > > > Some other advantages might be better
> integration with modern > > client-side font mechanisms, particularly
> font-selection, instead of > > using the traditional (and largely regarded
> as "crufty") X font > > mechanism.  I think the biggest advantage is the
> Emacs can use OTF with the font-backend mechanism.  For such script as
> Indic, it's vital matter.  > Thanks, but I also asked about disadvantages.
> Once the code gets stable, I think there's no disadvantage.  --- Kenichi
> Handa handa <at> ni.aist.go.jp

Just tested the font-backend build on windows, and there are 2 obvious
problems I have noticed. 1) the rendering speed is painfully slow, even on my
core2 cpu. 2) it cannot render italic font correctly for non-ascii
chars(they are displayed as boxes). Now the bright side, the annoy vertical
lines and incomplete rendered chars are completely gone, cool. if the above 
mentioned issues are fixed, i see no reason not to use it as the default.

Re: font-backend

[Stefan Monnier]

> Just tested the font-backend build on windows, and there are 2 obvious
> problems I have noticed. 1) the rendering speed is painfully slow, even on my
> core2 cpu.

Question:
What if you start Emacs with --disable-font-backend?
This should give you back the performance and behavior you had before.

It's not a long-term solution, but the first thing I'd like to do is to
get rid of the ENABLE_FONT_BACKEND compile-time choice.


        Stefan

Re: font-backend

[Feng Li]

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

On Sat, Feb 23, 2008 at 3:43 AM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > Just tested the font-backend build on windows, and there are 2 obvious
> > problems I have noticed. 1) the rendering speed is painfully slow, even
> on my
> > core2 cpu.
>
> Question:
> What if you start Emacs with --disable-font-backend?
> This should give you back the performance and behavior you had before.
>
> It's not a long-term solution, but the first thing I'd like to do is to
> get rid of the ENABLE_FONT_BACKEND compile-time choice.
>
>
>        Stefan
>


Yes, I can confirm starting with --disable-font-backend works fine. not
super fast, but acceptable, just like before. And non-ascii italic
characters are rendered correctly.

-- 
Feng Li

[-- Attachment #2: Type: text/html, Size: 1096 bytes --]

Re: font-backend

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 22 Feb 2008 14:00:00 +0000 (UTC), finalpatch <fengli@gmail.com> said:

> obvious problems I have noticed. 1) the rendering speed is painfully
> slow, even on my core2 cpu. 

I'm developing a font backend driver using Core Text, which is a new
framework available from Mac OS X 10.5.  It was slower than Emacs 22
first, but now it shows good performance with caching the results of
metrics calculations.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: font-backend

[Jason Rumney]

YAMAMOTO Mitsuharu wrote:
> I'm developing a font backend driver using Core Text, which is a new
> framework available from Mac OS X 10.5.  It was slower than Emacs 22
> first, but now it shows good performance with caching the results of
> metrics calculations.
>   
Yes, it is definitely the metrics calculations that are slowing things 
down on Windows too. I added some code to cache the metrics for ASCII 
characters some time ago, but the problem remains for buffers containing 
many non-ASCII characters.

Re: font-backend

[Jason Rumney]

finalpatch wrote:
> 2) it cannot render italic font correctly for non-ascii
> chars(they are displayed as boxes).
>   

I can't reproduce this. Was the problem perhaps fixed by recent changes?

Re: font-backend

[Feng Li]

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

On Sat, Feb 23, 2008 at 1:28 PM, Jason Rumney <jasonr@gnu.org> wrote:

> finalpatch wrote:
> > 2) it cannot render italic font correctly for non-ascii
> > chars(they are displayed as boxes).
> >
>
> I can't reproduce this. Was the problem perhaps fixed by recent changes?
>
>
how to reproduce:

1) start emacs with "runemacs -q"
2) load a txt file with some chinese text in it. it should look fine at this
stage.
3) shift-left click the emacs window, and select an italic variant of a font
.
4) the characters become boxes.

-- 
Feng Li

[-- Attachment #2: Type: text/html, Size: 841 bytes --]

Re: font-backend

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 23 Feb 2008 02:23:26 +0000, Jason Rumney <jasonr@gnu.org> said:

>> I'm developing a font backend driver using Core Text, which is a
>> new framework available from Mac OS X 10.5.  It was slower than
>> Emacs 22 first, but now it shows good performance with caching the
>> results of metrics calculations.

> Yes, it is definitely the metrics calculations that are slowing
> things down on Windows too. I added some code to cache the metrics
> for ASCII characters some time ago, but the problem remains for
> buffers containing many non-ASCII characters.

But it still does get_frame_dc and SelectObject even for the
ASCII-only case.  I think this can be deferred until cache miss
happens.

FWIW, below shows what the Core Text font backend is doing on the
metrics caching.  I assume the height of a valid metrics value is
always nonnegative.


				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

/* The actual structure for Mac Core Text font that can be casted to
   struct font.  */

struct ctfont_info
{
  struct font font;
  CTFontRef ctfont;
  unsigned synthetic_italic_p : 1;
  unsigned synthetic_bold_p : 1;
  short metrics_nrows;
  struct font_metrics **metrics;
};

#define METRICS_NCOLS_PER_ROW	(128)

enum metrics_status
  {
    METRICS_INVALID = -1,  /* metrics entry is invalid */
    METRICS_WIDTH_VALID = -2 /* width is valid but others are invalid */
  };

#define METRICS_STATUS(metrics)	((metrics)->ascent + (metrics)->descent)
#define METRICS_SET_STATUS(metrics, status) \
  ((metrics)->ascent = 0, (metrics)->descent = (status))

static int
ctfont_glyph_extents (font, glyph, metrics)
     struct font *font;
     CGGlyph glyph;
     struct font_metrics *metrics;
{
  struct ctfont_info *ctfont_info = (struct ctfont_info *) font;
  CTFontRef ctfont = ctfont_info->ctfont;
  int row, col;
  struct font_metrics *cache;
  int width;

  row = glyph / METRICS_NCOLS_PER_ROW;
  col = glyph % METRICS_NCOLS_PER_ROW;
  if (row >= ctfont_info->metrics_nrows)
    {
      ctfont_info->metrics =
	xrealloc (ctfont_info->metrics,
		 sizeof (struct font_metrics *) * (row + 1));
      bzero (ctfont_info->metrics + ctfont_info->metrics_nrows,
	     (sizeof (struct font_metrics *)
	      * (row + 1 - ctfont_info->metrics_nrows)));
      ctfont_info->metrics_nrows = row + 1;
    }
  if (ctfont_info->metrics[row] == NULL)
    {
      struct font_metrics *new;
      int i;

      new = xmalloc (sizeof (struct font_metrics) * METRICS_NCOLS_PER_ROW);
      for (i = 0; i < METRICS_NCOLS_PER_ROW; i++)
	METRICS_SET_STATUS (new + i, METRICS_INVALID);
      ctfont_info->metrics[row] = new;
    }
  cache = ctfont_info->metrics[row] + col;

  if (METRICS_STATUS (cache) == METRICS_INVALID)
    {
      cache->width =
	CTFontGetAdvancesForGlyphs (ctfont, kCTFontDefaultOrientation,
				    &glyph, NULL, 1) + 0.5;
      METRICS_SET_STATUS (cache, METRICS_WIDTH_VALID);
    }
  width = cache->width;

  if (metrics)
    {
      if (METRICS_STATUS (cache) == METRICS_WIDTH_VALID)
	{
	  CGRect bounds;

	  bounds = CTFontGetBoundingRectsForGlyphs (ctfont,
						    kCTFontDefaultOrientation,
						    &glyph, NULL, 1);
	  if (ctfont_info->synthetic_italic_p)
	    bounds = CGRectApplyAffineTransform (bounds, synthetic_italic_atfm);
	  if (ctfont_info->synthetic_bold_p)
	    {
	      CGFloat d = - synthetic_bold_factor * CTFontGetSize (ctfont) / 2;

	      bounds = CGRectInset (bounds, d, d);
	    }
	  bounds = CGRectIntegral (bounds);
	  cache->lbearing = CGRectGetMinX (bounds);
	  cache->rbearing = CGRectGetMaxX (bounds);
	  cache->width = width;
	  cache->ascent = CGRectGetMaxY (bounds);
	  cache->descent = -CGRectGetMinY (bounds);
	}
      *metrics = *cache;
    }

  return width;
}

static int
ctfont_text_extents (font, code, nglyphs, metrics)
     struct font *font;
     unsigned *code;
     int nglyphs;
     struct font_metrics *metrics;
{
  int width, i;

  BLOCK_INPUT;
  width = ctfont_glyph_extents (font, code[0], metrics);
  for (i = 1; i < nglyphs; i++)
    {
      struct font_metrics m;
      int w = ctfont_glyph_extents (font, code[i], metrics ? &m : NULL);

      if (metrics)
	{
	  if (width + m.lbearing < metrics->lbearing)
	    metrics->lbearing = width + m.lbearing;
	  if (width + m.rbearing > metrics->rbearing)
	    metrics->rbearing = width + m.rbearing;
	  if (m.ascent > metrics->ascent)
	    metrics->ascent = m.ascent;
	  if (m.descent > metrics->descent)
	    metrics->descent = m.descent;
	}
      width += w;
    }
  UNBLOCK_INPUT;

  if (metrics)
    metrics->width = width;

  return width;
}

Re: font-backend

[Jason Rumney]

YAMAMOTO Mitsuharu wrote:
> But it still does get_frame_dc and SelectObject even for the
> ASCII-only case.  I think this can be deferred until cache miss
> happens.
>   
This indeed may result in a minor improvement. I have changed it to 
defer these operations.

Re: font-backend

[finalpatch]

Jason Rumney <jasonr <at> gnu.org> writes:

> 
> YAMAMOTO Mitsuharu wrote:
> > But it still does get_frame_dc and SelectObject even for the
> > ASCII-only case.  I think this can be deferred until cache miss
> > happens.
> >   
> This indeed may result in a minor improvement. I have changed it to 
> defer these operations.
> 
> 

Wow~~, that's not just minor improvement. I tested the trunk head today,
it's much faster now, quite comparable to the before font-backend version.

Great work!