nanogui: propose low-level line draw?
Subject:
Re: propose low-level line draw?
From:
"Greg Haerr" ####@####.####
Date:
18 Dec 2000 22:12:05 -0000
Message-Id: <001901c06940$b5023ca0$6817dbd0@censoft.com>
: GdLine() handles bresenham, and calls GdClipPoint() and psd->DrawPixel()
: for each pixel. It's the stack setup and takedown that's eating processor
: time.
Make sure you #define NDEBUG in the fblinX.c driver for final
production code, it will run without any of the assert()'s. What
bpp are you running?
: Does "for the time being" mean that someone has ideas for a faster
: linedraw that either replaces per-point clipping with something more
: efficient, or that makes use of low-level bresenham in the driver?
:
: I've been giving thought to such a low-level driver routine, and it seems
: to me that the center of the problem is starting bresenham at the start of
: a clipping region instead of the start of the line, while still drawing
: all points of the line at the same positions as are drawn by the current
: GdLine() function.
Likely, your problem is that the bresenham drawing is too slow,
even when drawing to an unobscured window. If this is the case,
then when GdClipArea returns VISIBLE, we should go directly to
a driver-level routine that draws w/o clipping. This will remove
almost all the setup/takedown time that you're seeing hurt performance.
It's unlikely that recoding the upper level routine as you suggest below
will help much, since usually you'll have one clip rectangle - your
window border.
: Someone with experience in optimizing graphics engines has probably
: thought of all of this before, and with respect to nano-X. Since I don't
: have that kind of experience, I'd like to know what other people have
: thought along these lines. In particular would this set-up per line
: segment waste more time than would be saved, are these ideas counter to
: the design of the drivers, etc.
I have been working on just getting Microwindows basic draw capabilities
running, rather than getting it optimized. The plan is to add either a
direct
low-level screen driver entry point or an upper-level non-clipped routine
for speed when needed. The drawback to adding another screen driver
entry point is that then everybody needs to write the routine in order to
bring up Microwindows on a new platform. I've purposely kept as
many routines out as possible - because I want Microwindows to
be easy to port and easy to understand...
Regards,
Greg
