Subject: Re: SPXg support, last call
To: None <port-vax@NetBSD.org>
From: Blaz Antonic <blaz.antonic@siol.net>
List: port-vax
Date: 11/22/2005 00:23:27
Hello,

Talking to myself again but I just can't help it :-) Yep, another status
update:

Contrary to what I said yesterday there is actually also third option
re: text rendering issue. I managed to figure out how to get hardware to
render bitmaps of chosen foreground and background color ("bitmaps" as
in font glyphs for example). The method is less elegant than plane
expansion which I used on LCG (plane expansion is essentially the same
thing, except that it only uses 1 bit per pixel in source sprite whereas
this copy-opaque-rectangle operation on SPXish framebuffer uses 1 byte
per pixel in source sprite) but hey, it's working and it's noticeably
faster on SPXg than software rendering (~1 second for entire screen
using 8x15 font, in contrast to software rendering which takes ~5
seconds for entire screen using same typeface). This means that 256 *
height * width * 2 bytes of off-screen framebuffer memory is used to
store font glyphs in both normal and underlined form (so we don't have
to underline them afterwards, saving quite some CPU cycles).

The really cool part is that in theory same method should work on SPX
and LCSPX, meaning that both should work faster than they did with my
previous driver (the lcspx.c some of you got from me). Benefits of using
hardware rendering increase proportionally with font glyph size - the
bigger the typeface one uses the bigger the difference between HW and SW
rendering is. Good news for semi-blind folks like myself I suppose :-)

I just need to iron out few problems and then I'll publish the code.

Blaz Antonic
-- 
Hi! I'm a signature virus!
Copy me into your signature to help me spread!