nanogui: propose low-level line draw?
Subject:
Re: propose low-level line draw?
From:
Morten Rolland ####@####.####
Date:
19 Dec 2000 09:07:49 -0000
Message-Id: <3A3F1B08.2344D5EA@screenmedia.no>
Kaben Nanlohy wrote:
>
> How about putting a "gen_linedraw()" into genmem.c, where gen_linedraw()
> draws pixel-by-pixel using psd->drawpixel()? Then set_subdriver() or
> select_fb_subdriver() can fill-in a low-level linedraw with something that
> works in all cases in which psd->drawpixel() works, and where an optimized
> psd->linedraw() routine hasn't yet been written.
>
This is what should ultimately be done for all the drawing functions in
the low level driver that are more complex than get/set pixel (and maybe
hline and some sort of scanline for speeding up unoptimized GdArea/Image).
The benefits would be:
1) The general functions would be regarded as the definition of a
certain low level drawing operation and would help people
understand the low level code and be a guide when writing
optimized versions. They could also be used to check the operation
of an optimized version in a regression test setup.
2) Move all the drawing stuff out of engine/devdraw.c - the way it is
now is not exactly beautiful -- e.g. GrArea calls a low level
driver to paint rectangles at a time (for clipping) when 16 bit
colours is used (our setup), and falling through to a more general
but much more slow version for other colour depths.
All code in engine/devdraw.c that changes pixel values should be
moved into a correspondingly (possibly new) low level operation,
and care should be taken to make it possible to do clipping
efficiently (e.g. big areas and multiple pixles at a time).
3) Make it a requirement that all new drawing primitives be implemented
as general low level drawing functions first so that their operation
can be discussed and tested on all platforms and bit depths.
This will greatly improve the tangled way of introducing new
features into this part of the system.
Note: I haven't looked much at the code in the most recent versions.
> This still requires hoop-jumping for clipping, tho. Unless as a special
> case clipping isn't needed.
Yes... Your situation is much similar to ours when we optimized the GdArea
function for 16 bit colours. We implemented a low level painter that was
sufficiently flexible to paint only parts of the original image, thus
making it possible to walk the clipping rectangles for the area to be
painted and call the low level driver for the visible parts only.
This is easier for GdArea type of functions than linedrawing like you
explain, since it is important in which order you walk the rectangles,
and also not always knowing which rectangle will be next until after
a (possibly hidden) low level linedraw has been performed to update the
state of the "line draw".
For the low level GdArea we used a "hw_gc_t" struct to carry the
information to the low level driver in an easy to extend way, and
the same setup can be extended to hold the state of the line
draw operation and bring updated coordinates back to the devdraw.c
function for use when calculating the size of the next rectangle,
visible or not. The optimized versions of the low level driver
should simply skip along when only updating the state. This needs
more math but finishes hidden segments faster (watch this effect
in any good windowing system by hiding parts of a "line draw active"
window and watch the still visible lines speed up).
Have a look in driver/fblin16.c and engine/devdraw.c (GdArea) for
more info on how we did our optimizations.
Personally I think extending and optimizing nano-X will be
difficult unless a clean separation of the low level drawing and
the upper level clipping smarts is done, and although this is not
a prime concern for us in the short run, I see it as crucial to
make an effort in this area, and I'm prepeared to help.
Regards,
Morten Rolland, Screen Media
