Re: reducing equality tests in displaying text

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Thu, 29 Jan 2009 09:37:19 +0900, Kenichi Handa <handa@m17n.org> 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
				mituharu@math.s.chiba-u.ac.jp