[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(mgp-users 00126) Re: embarassingly slow tfont handling...
- To: mgp-users@mew.org
- Subject: (mgp-users 00126) Re: embarassingly slow tfont handling...
- From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
- Date: Sun, 21 Mar 1999 00:08:28 +0900
- In-reply-to: <> from "Jun-ichiro itojun Hagino" at Mar 20, 99 02:28:49 am
- Posted: Sat, 20 Mar 1999 13:52:48 +0100 (MET)
- Reply-to: mgp-users@mew.org
> >i think we have a small performance problem here... it is most
> >evident when i run mgp with truetype fonts and a not-solid background
> >(e.g. an image):
> > rendering the slides is very slow!
>
> This is because we do anti-aliasing with freetype, and it is not
> trivial to draw anti-aliased text on non-solid background.
> (you will need to compute the mixed color, basically)
Ok,
i am not sure what is the problem, but running a profiled version of
mgp shows that a lot of time is spent in talking to the X server,
possibly doing XGetPixel()/XPutPixel.
A little bit of investigation shows that a non-solid background
causes the first part of tfont.c::tfc_image() to be run, which
calls:
* malloc() (possibly causing some huge memory fragmentation although
no apparent leak),
* a large number of XGetPixel()
* XQueryColors()
somehow these calls seem to trash the behaviour of the X server (at
least on my machine with 2.2.x and XFree3.2
I actually wonder why there appears to be no way write a rectangular
region into an XImage and instead one has to resort to calls to
XPutPixel...
In any case a quick and extremely dirty workaround seems to be the
addition, near the beginning of tfont.c::tfc_image(), of
back = 0 ;
which basically fools the rendering code into believing that there is
a solid black background.
This way at least rendering times are stable over time...
luigi