Re: changes to configure.ac (HEAD)

Hi Dom,

Dominic Lachowicz wrote:
>
> What's your motivation behind this? Since on those embedded targets,
> we're using GTK+ as a frontend (which requires pango), why shouldn't
> AbiWord use Pango as well?

I would like to separate the two classes and have one or the other, but
not both; it makes no sense to have the all non-Pango drawing code in
AbiWord when it is not getting used, and vice versa, and this is a step
in that direction.

At present, I do not want to ditch the old class completely though. When
playing with AbiWord 2.5 on the Nokia 770 it was quite clear that the
drawing performance is not ideal; Pango performance is a known issue on
embedded devices, although in this case some of it might be due to the
Pango graphics class itself (hopefully, we can in time optimize the code
to make it snappier). Also, not all embedded devices have the necessary
fonts && input infrastructure to make proper use of the Pango
capabilities (e.g., the 770 was only intended to support European
languages), so it makes sense at the present time to be able to fall
back on the old class only, where appropriate.

For the 770 the Pango class was already disabled, but it was still
getting compiled in; the changes I made mean that when disabled, it is
also not compiled in. Being able to control the behaviour via the
configure line is important for automated build systems such as
OpenEmbedded.org. (One of the reasons for this change is so that I can
easily build different versions of AbiWord directly from CVS using
OpenEmbedded for performance testing.)

I am contemplating what is the best approach in this whole area for the
future (on Unix). I think for the desktop we will want to move to Cairo,
which could solve number of our problems. Unfortunately at the moment
Cairo performance on embedded systems is abysmal, so pretty much any
embedded device out there that uses gtk runs gtk2.6; not sure how
quickly, or if, this is going to change (lot of noise was made at
GUADEC, but not much seems to be happening AFAIK).

In the course of time, I envisage something like this:

* make GR_UnixPangoGraphics into a standalone class; eliminate
GR_UnixGraphics from the default build, but make it possible to compile
it in instead of GR_UnixPangoGraphics if required, with embedded in
mind. I would like to do this still in the 2.5 cycle (this requires no
new code, just to move things from the one class to the other).

* create a Cairo-based graphics class and make it the default. Most of
the text-processing stuff in the Pango class will not need to be changed
for this. I would like us to do this at the start of the 2.7 cycle,
whenever it might be.

* see if the old Pango graphics class could be optimised adequately for
embedded devices, if so ditch the old no-Pango class completely; if not,
will contemplate the options when it comes to it (I am hopeful; I think
if the class was to be intended for embedded only, we might have a
better chance at optimising the code). I hoping this could be done in
parallel, or slightly behind implementing the cairo class.

Tomas
Received on Sat Sep 2 19:18:29 2006