Re: font-backend mechanism on Windows and Mac?

[Adrian Robert]

On 9/14/07, Jason Rumney <address@hidden> wrote:
> Kenichi Handa wrote:
> > Do you mean that the displaying got slower after the recent
> > change?
> >
>
> Perhaps, it does seem a little slower, and the more complex clipping
> masks might have caused that, but I think most of the slowness is from
> the new font-backend itself. It seems to be outputting a character at a
> time, rather than whole lines. It might be due to a workaround in the
> Windows code to avoid a Cleartype bug in the old font code (though I'd
> expect the old code to be similarly slow in that case), or it might be
> not combining multiple redraw requests as the overlapping window is
> moved over the Emacs frame.

Another possibility is the metrics implementation.  In text_extents()
the W32 and Xft impls query the font itself for the metrics every
time.  With Xft this may be fast if the font is client-side (and it
does it for the whole string, not each char), but possibly under
Windows it is not.  In Cocoa nsfont.m metrics are cached in blocks of
256 chars to deal with this.  It would be easy to adapt that to other
terms, though then the code should perhaps go as a utility into
font.c.  (But drivers _should_ do a full-string determination like
xftfont.c does if they can, so they wouldn't need it.)

How is the performance under X without Xft?