nanogui: Microwindows cleanups .... some ideas
Subject:
Re: Microwindows cleanups .... some ideas
From:
"Aaron J. Grier" ####@####.####
Date:
20 Apr 2005 00:42:45 +0100
Message-Id: <20050419234215.GZ1714@mordor.unix.fryenet>
On Tue, Apr 19, 2005 at 07:39:51PM +0200, Jachym Holecek wrote:
> Perhaps a more interesting project would be to make NanoX build in
> separate objdirs?
preferably with a non-recursive make. it's been on my wishlist for
years now, but since things work well enough(tm) it hasn't been a high
priority.
the last version of microwin I was merged up with was 0.89, and I've got
the following sitting on my private fork awaiting time to cleanup and
submit. (I've got plans to merge with 0.90 sometime this year, but
whitespace issues between 0.89 and 0.90 coupled with some fairly large
changes make it non-trivial.)
* driver-level linedraw and new clipping code
the overhead of calling out to putpixel was a performance killer vs
direct pointer arithmetic on video memory. the existing clipping
algorithm was (is still?) very inefficient, so my predecessor
implemented cohen-sutherland clipping algorithm to clip lines to
rectangles. the speedup we saw was a few orders of magnitude for our
8bpp hardware. unfortunately for this to be useful to everybody I'd
need to flesh out and test some the other fb drivers too...
* video malloc (vidmalloc/vidfree)
in order to make best use of blit hardware, source and destination areas
should both be in video memory, so pixmaps should be allocated out of
video memory. hence vidmalloc/vidfree.
* static clipping regions
dynamic clipping regions are insanely slow on our platform; I haven't
done an in-depth investigation why, but I suspect malloc() overhead
hurts things. since our interface is not terribly complicated, static
clipping works great and runs fast.
* dashlists
there had been patches for this floating around for a while; I don't
recall if they made it back in the trunk. the implementation cheats,
and doesn't actually calculate hypotenuses, since that'd be
prohibitively computationally expensive, but at least it's something.
(unfortunately multiple line width support got broken somewhere along
the way...)
* text draw speedups
I think the start of this made it back into 0.90, but I'm not sure.
there's still some improvements that could be made to take better
advantage of bitblit hardware, or at least driver-specific GdBitmap
optimizations.
* miscellaneous stuff
constification of pointers to fonts, so the fonts can stay in read-only
flash instead of being copied to RAM unnecessarily.
...
if anybody's interested I can throw them a tarball.
--
Aaron J. Grier | Frye Electronics, Tigard, OR | ####@####.####
