emacs-devel
[Top][All Lists]
Advanced

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

Re: reducing equality tests in displaying text


From: Kenichi Handa
Subject: Re: reducing equality tests in displaying text
Date: Thu, 29 Jan 2009 09:37:19 +0900

In article <address@hidden>, YAMAMOTO Mitsuharu <address@hidden> writes:

> > Are you sure that those calls mostly return nil?  Could you
> > please check if this patch surely improve the performance?

> Here is the result.

>       750.9 ms        emacs   mark_object     
>       153.4 ms        libfreetype.6.dylib     tt_cmap4_char_map_binary        
>       126.7 ms        emacs   Fgarbage_collect        
>       106.8 ms        emacs   mark_vectorlike 
>       64.8 ms emacs   x_produce_glyphs        
>       61.5 ms emacs   char_table_ref  
>       47.5 ms emacs   fontset_find_font       
>       33.3 ms emacs   get_next_display_element        
>       30.3 ms emacs   face_for_char   
>       29.3 ms libXft.2.dylib  XftGlyphExtents 
>       29.3 ms emacs   assq_no_quit    
>       29.3 ms emacs   find_interval   
>       27.3 ms emacs   hash_lookup     
>       26.3 ms emacs   make_uninit_multibyte_string    
>       25.2 ms emacs   sub_char_table_ref      

Ummm, this result is surprising, but I found a bug in
fontset_get_font_group that is the culprit of so many calls
of char_table_ref_and_range.  I simply forgot to record the
result of previous call in the case of nil.  I should have
noticed it when you wrote that from and to were never used
in such a case.  :-(

Anyway, please try the new code.  I think that the calls of
char_rable_ref itself is reduced.

> > Hmmm.  I've just found that Xft has the function
> > XftCharExists now.  I remember that it didn't exist in a
> > rather old vesion.  Does your Xft library have this
> > function?

> It exists.  But it simply uses the `charset' member in struct _XftFont:

> _X_EXPORT FcBool
> XftCharExists (Display            *dpy,
>              XftFont      *pub,
>              FcChar32    ucs4)
> {
>     if (pub->charset)
>       return FcCharSetHasChar (pub->charset, ucs4);
>     return FcFalse;
> }

> Is there any reason you prefer an Xft-level routine to
> fontconfig-level?  By adding some `FcCharSet *' member in struct
> ftfont as I said, you don't need to "override" `has_char' function in
> the xft driver, and the ftx driver can also benefit from it for free.

In ftfont.c, fontconfig is used only to list fonts.  The
other actual font driving is done directly by freetype.
Currently, the exception is ftfont_has_char, but I want to
find a way to avoid using fontconfig here too.

The reason why I want to keep this separation is that
listing fonts and using a font is different tasks, and, in
the future, I want to allow different combinations of them.

On the other hand, as Xft is so tightly combined with
fontconfig, and it already has `charset' member in XftFont
structure, it is nonsense not to utilize it.

---
Kenichi Handa
address@hidden




reply via email to

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