From: Felix Zielcke <fzielcke@z-51.de>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] Faster text rendering by optimizing font glyph lookup
Date: Sun, 26 Jul 2009 11:13:01 +0200 [thread overview]
Message-ID: <1248599581.25072.7.camel@fz.local> (raw)
In-Reply-To: <1248470279.3510.80.camel@fz.local>
Am Freitag, den 24.07.2009, 23:17 +0200 schrieb Felix Zielcke:
> Am Donnerstag, den 11.06.2009, 23:31 +0200 schrieb Vladimir 'phcoder'
> Serbinenko:
> > On Thu, Jun 11, 2009 at 12:28 PM, Felix Zielcke<fzielcke@z-51.de> 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 <rmh@aybabtu.com> 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
>
> So if there still won't come up objections against this, then I'll do
> the change, then at least an Ubuntu bug report can be closed.
>
Ah just read now the comment in grub-mkconfig_lib.in, which complains
about loading speed not rendering.
In qemu there's a very small delay in loading unicode.pf2
ascii.pf2 loads instantly.
But I think that's acceptable or not?
--
Felix Zielcke
Proud Debian Maintainer
next prev parent reply other threads:[~2009-07-26 9:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-08 21:49 [PATCH] Faster text rendering by optimizing font glyph lookup Colin D Bennett
2009-02-09 14:11 ` Robert Millan
2009-02-09 16:24 ` Colin D Bennett
2009-06-11 10:28 ` Felix Zielcke
2009-06-11 21:31 ` Vladimir 'phcoder' Serbinenko
2009-07-24 21:17 ` Felix Zielcke
2009-07-25 16:04 ` Robert Millan
2009-07-25 16:22 ` Felix Zielcke
2009-07-26 8:38 ` Michal Suchanek
2009-07-26 8:56 ` Felix Zielcke
2009-07-26 9:13 ` Felix Zielcke [this message]
2009-04-10 23:39 ` phcoder
2009-04-13 13:57 ` Robert Millan
2009-04-13 14:17 ` Felix Zielcke
2009-05-31 9:41 ` Vladimir 'phcoder' Serbinenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1248599581.25072.7.camel@fz.local \
--to=fzielcke@z-51.de \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.