nanogui: propose low-level line draw?


Previous by date: 18 Dec 2000 23:22:49 -0000 Re: Thread-safety, wrapping globals in structs, RTEMS, Greg Haerr
Next by date: 18 Dec 2000 23:22:49 -0000 Re: GUILib for C, Nick Papadonis
Previous in thread: 18 Dec 2000 23:22:49 -0000 Re: propose low-level line draw?, Greg Haerr
Next in thread: 18 Dec 2000 23:22:49 -0000 Re: propose low-level line draw?, Morten Rolland

Subject: Re: propose low-level line draw?
From: Kaben Nanlohy ####@####.####
Date: 18 Dec 2000 23:22:49 -0000
Message-Id: <Pine.NEB.4.21.0012181450090.14954-100000@kaben.frye.com>

On Mon, 18 Dec 2000, Greg Haerr wrote:
> 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...


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 still requires hoop-jumping for clipping, tho.  Unless as a special
case clipping isn't needed.


> 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?


4bpp.


> 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.


I'm double-buffering graphs at about eight frames per second, using a
linear4_blit() that has been messily optimized for double-word copies
except at boundaries of the rectangle.

I blit from a portion of the offscreen pixmap to the display window.  As
long as my pixmap has more height than the range of my graphs, clipped
linedraws to the pixmap are not required.

For my purposes, at least, calling an unclipped psd->linedraw() from
GdLine() would be wonderful.

***

As soon as I have something that works, I'll post it to the list.

Thanks -- Kaben Nanlohy


Previous by date: 18 Dec 2000 23:22:49 -0000 Re: Thread-safety, wrapping globals in structs, RTEMS, Greg Haerr
Next by date: 18 Dec 2000 23:22:49 -0000 Re: GUILib for C, Nick Papadonis
Previous in thread: 18 Dec 2000 23:22:49 -0000 Re: propose low-level line draw?, Greg Haerr
Next in thread: 18 Dec 2000 23:22:49 -0000 Re: propose low-level line draw?, Morten Rolland


Powered by ezmlm-browse 0.20.