[olpc-software] AbiWord, HIG

Jim Gettys jg at laptop.org
Wed Mar 15 16:35:07 UTC 2006


On Wed, 2006-03-15 at 10:24 -0500, Alan Cox wrote:
> On Wed, Mar 15, 2006 at 07:09:31AM -0800, Alan Kay wrote:
> > Right now it has a HW bitbltter with alpha, so quite a bit can be done.
> 
> Its also a UMEM architecture (ie video shares with main memory). On the plus
> side it makes direct CPU hacking on the video space cheap too. On the minus
> side it burns memory bandwidth. The system uses RLE compression of scanlines
> to reduce this so you want to try and generate a UI that doesn't contain
> subtle horizontal shading or over abuse alpha in that direction.

Display refresh bandwidth won't be a problem, Alan, due to our magic
DCON chip.  I'll explain more publicy once I know the patent disclosures
are filed (we're filing a bunch in defense of what we've done).
Probably within a week.  We're talking with Eben Moglen about what
policies to licensing of them we should take (just so you know we're on
the side of light ;-).

> 
> > I haven't heard the recent thoughts about Cairo, but it certainly was (and 
> > probably is) part of the proposed system.
> 
> How FP heavy is the current cairo given the FP performance of the old
> generation geode (GX not NX) is absolutely awful. Gnome for example is near
> unusable on a Geode GX because of the performance of the image scalers.
> 

Cairo is *not* FP intensive; it mostly uses FP just in external
interfaces, and does 32 or 64 bit integer arithmetic for its internal
rendering algorithms.  It is in use on the iPAQ (ARM with no FPU).

I gather scheduling FP code is important for FP performance.  I'm trying
to get the right GCC folks hooked up with the right AMD folks so a
better code scheduler can be made to appear.  Apparently, you can only
issue FP instructions every other cycle, so mixing integer and FP
instructions is an important scheduling issue for performance.
				- Jim

-- 
Jim Gettys
One Laptop Per Child





More information about the olpc-software mailing list