Re: reducing equality tests in displaying text

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 29 Jan 2009 09:37:19 +0900, Kenichi Handa <address@hidden> said:

> 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.

Yes, it gives a good result.  Thanks.

        675.1 ms        emacs   mark_object     
        164.5 ms        libfreetype.6.dylib     tt_cmap4_char_map_binary        
        133.0 ms        emacs   mark_vectorlike 
        117.6 ms        emacs   Fgarbage_collect        
        41.5 ms emacs   x_produce_glyphs        
        41.4 ms emacs   char_table_ref  
        33.3 ms emacs   fontset_find_font       
        32.3 ms emacs   get_next_display_element        
        29.5 ms emacs   display_count_lines     
        29.3 ms emacs   assq_no_quit    
        28.3 ms emacs   face_for_char   
        24.3 ms mach_kernel     ml_set_interrupts_enabled       
        24.3 ms libXft.2.dylib  XftCharIndex    
        24.3 ms emacs   append_glyph    
        24.3 ms libXft.2.dylib  XftGlyphExtents 
        24.2 ms emacs   hash_lookup     
        23.2 ms emacs   sub_char_table_ref      
        22.3 ms emacs   find_interval   
        22.2 ms emacs   Fcons   
        22.2 ms emacs   sort_overlays   

>> 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.

I don't think it's unnatural for font listing layers to provide
`has_char' functionality, because that layer already involves
supported charset inclusion test in its core part.

> 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.

Of course, it makes sense for font driving layers to provide
alternative implementations of `has_char', if it is more efficient
than the underlying counterpart in the font listing layer.

Another (maybe cleaner) design would be to separate the current
`has_char' function into that for font entities (font listing layer)
and that for font objects (font driving layer).

                                     YAMAMOTO Mitsuharu
                                address@hidden