Date: Wed, 28 Jan 2004 19:33:23 -0800 From: "Aaron J. Grier" Subject: Re: [nanogui] Re: 2D hardware accelerated graphics I figured you guys would both be interested in this... On Wed, Jan 28, 2004 at 05:53:16PM -0700, Greg Haerr wrote: > > as for line draws, back in pre-0.89 days a co-worker implemented a > > smarter line-clipping routine which even on dumb framebuffers sped > > things up a few orders of magnitude. unfortunately the > > modifications are non-trivial since they involve moving the line > > draw routine into the device driver, and thus are not terribly easy > > to feed back into the mainline. > > It would be interesting to see this code, just to see how it was > handled. Admittedly, the current design tries to keep most of the > drawing functions completely portable, thus assuring it works [slowly > sometimes] on all systems, and allowing device drivers to be simple. > However, we could move to allowing low-level drivers to take control > if implemented, otherwise running the Gd layer "emulation" code. This > would have the side effect of possibly allowing the graphics output to > be different when using different drivers... I kept that in mind while writing my additions... if the device-level driver is NULL then it should use the generic routines, but obviously it isn't heavily tested. I just got it compiling again tonight. I can't really give it a good testing since we're in the middle of a release cycle, but I've attached my diff versus CVS as of 2004-01-09. undoubtedly it it's currently broken, but when I get this release out the door I'll have more time to tie up the loose ends. maybe I can get the demos running over the next couple days... Jordan writes: > Well, a line is a line is a line right? when Kaben started with the line draw code it was 1000 times slower than it is now, so not all lines are created equal. (: > So if you had, say, a rendering driver model with the above hooks and > tossed in your obligatory software emulation then you would be golden. > Isolating the code has the added bonus of letting us play with the > individual hooks without breaking the core code, even going with > (gasp) assembly where appropriate. or hand-tweaked C as the patch demonstrates... I tried to keep the majority of it in the driver level, but some of the global alignment stuff needs to be "portablized". -- Aaron J. Grier | Frye Electronics, Tigard, OR | aaron@frye.com attachment; filename="frye-vs-CVS-2004-01-09.diff.bz2"