nanogui: propose low-level line draw?
Subject:
propose low-level line draw?
From:
Kaben Nanlohy ####@####.####
Date:
18 Dec 2000 21:56:28 -0000
Message-Id: <Pine.NEB.4.21.0012181329430.14684-100000@kaben.frye.com>
I've been doing lots of real-time graphing of the results of signal
processing, and I've found that the bottleneck in my applications is the
high-level linedraw routine of nano-X.
GdLine() handles bresenham, and calls GdClipPoint() and psd->DrawPixel()
for each pixel. It's the stack setup and takedown that's eating processor
time.
In the source for GdLine() is the comment:
/*
* For size considerations, there's no low-level bresenham line draw, so
* we've got to draw all non-vertical and non-horizontal lines with
* per-point clipping for the time being.
*/
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.
All of the state in bresenham is carried pixel-to-pixel in the decision
variable "rem" in GdLine(), in the slope variables "xdelta" and "ydelta",
and in the oordinate variables "x1" and "y1". GdLine() could, at least
for rectangular clipping regions, prepare those five state variables
after clipping, and pass them along with "x2" and "y2" (as the other
clipping bounds) and "psd" and "line_color" to a low-level linedraw once
for each clipped line segment.
***
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.
***
Thanks much, merry xmas -- Kaben
