nanogui: Microwindows cleanups .... some ideas
Subject:
Re: [nanogui] Re: Microwindows cleanups .... some ideas
From:
alain volmat ####@####.####
Date:
20 Apr 2005 01:05:30 +0100
Message-Id: <20050420000501.75101.qmail@web41724.mail.yahoo.com>
Hi Aaron,
> > 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.
I am currently concentrating on cleaning up those
compilation related stuffs so I think I can make a
patch for that then. This shouldn't be a bit issue I
think so it won't take too much time.
As far as the improvements you mentioned in your
emails,
> * driver-level linedraw and new clipping code
> * video malloc (vidmalloc/vidfree)
> * static clipping regions
> * dashlists
> * text draw speedups
> * miscellaneous stuff
I think I could give it a try on my iPAQ if you are
willing to share the code with us.
Alain
> 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
> | ####@####.####
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> ####@####.####
> For additional commands, e-mail:
> ####@####.####
>
>
__________________________________
Do you Yahoo!?
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide
