grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Faster text rendering by optimizing font glyph lookup


From: Vladimir 'phcoder' Serbinenko
Subject: Re: [PATCH] Faster text rendering by optimizing font glyph lookup
Date: Thu, 11 Jun 2009 23:31:25 +0200

On Thu, Jun 11, 2009 at 12:28 PM, Felix Zielcke<address@hidden> wrote:
> Am Montag, den 09.02.2009, 08:24 -0800 schrieb Colin D Bennett:
>> On Mon, 9 Feb 2009 15:11:16 +0100
>> Robert Millan <address@hidden> wrote:
>>
>> > On Sun, Feb 08, 2009 at 01:49:53PM -0800, Colin D Bennett wrote:
>> > > This patch greatly—*tremendously*, even, if higher-numbered Unicode
>> > > characters are used—speeds up retrieving a glyph for a particular
>> > > Unicode character.  This makes text rendering in general much faster.
>> > >
>> > > My text benchmark shows the new text rendering speed is somewhere from
>> > > 2.6x to 31x of the previous speed.  Basically, PFF2 font files are now
>> > > required to have the character index ordered in ascending order of code
>> > > point.
>> > >
>> > > Fonts created by 'grub-mkfont' already satisfy this requirement.  Fonts
>> > > created by my old Java 'fonttool' do not, and cannot be used any longer.
>> > >
>> > > The font loader verifies that fonts fulfill the character ordering
>> > > requirement, refusing to load invalid fonts, but the primary change is
>> > > in the 'find_glyph()' function, which now uses a binary search rather
>> > > than a linear search to find the glyph.
>> >
>> > Very nice!
>> >
>> > With this patch, how does retrieving glyphs from the complete unicode font
>> > compare to retrieving glyphs (without the patch) from the ascii ascii one?
>>
>> Here is the result of my benchmark with two kinds of text:
>> (1) 104 characters of ASCII English text, and
>> (2) 104 Unicode characters randomly selected from the characters in
>>     unifont, uniformly distributed over all 61050 characters in the
>>     font.
>>
>> Also, I ran the tests with both the 'ascii.pf2' and 'unicode.pf2' font
>> files generated by GRUB's Makefile.  Here are the results:
>>
>> ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>> 9 February 2009 videotest bench, text rendering
>> benchmark 640x480 resolution
>>                               ASCII Text  Unicode Text
>> Algorithm       Unifont used   (Chars/s)   (Chars/s)
>> --------------- ------------- ----------  ------------
>> Linear search   ASCII Font      255113       12098 [1]
>> Linear search   Unicode Font    250874       23068 [2]
>> Binary search   ASCII Font      255746       96231 [1]
>> Binary search   Unicode Font    255113      194741 [2]
>>
>> [1] Note that using the ASCII font for Unicode text results in a
>>     performance hit because the grub_font_draw_string() function will
>>     use font fallback to search for the missing glyphs in another
>>     font.  I had other fonts loaded while running the benchmark, so
>>     GRUB had to scan them for the missing characters.
>>
>> [2] These numbers, for full Unicode text with the full unifont, show
>>     the improvement in worst-case performance when using the binary
>>     search versus linear search.
>> ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>>
>> Note that most of the time is now spent actually rendering the bitmaps
>> on screen (instead of retrieving glyphs from the font), which actually
>> takes longer for the Unicode text because many of the glyphs are wider
>> than the English ASCII characters.
>>
>> (BTW, is there any way to run GRUB in a profiler?  I'd like to know
>> where the graphics performance bottlenecks are.)
>>
>> > Can we make unicode font the default now?
>>
>> I think so.  Using the full Unicode font does not seem to have a
>> significant effect on rendering speed now.  I will commit the patch if
>> it looks OK to you.
>>
>
> Now that Vladimir finally commited this, should we make it now the
> default or not?
I think we can make unicode fonts default now. Don't get too
overexcited though: we still lack ligatures. I don't know if composing
accents work and no bidi.But this subset is already enough to support
all European languages, Chinese, Korean and Japanese as long
characters are precomposed
> --
> Felix Zielcke
>
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko




reply via email to

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