nanogui: Thread: How to improve the efficiency of the NanoX draw?

Many people said that the efficiency of the NanoX is not high enough. 
They said the functions which draw lines and polygon can be optimized. 
But I don't know how to improve it. Can somebody tell me how, and show 
me some source code.

On Mon, Jan 21, 2008 at 10:44:43PM +0800, Lazy Fox wrote:
> Many people said that the efficiency of the NanoX is not high enough.
> They said the functions which draw lines and polygon can be optimized.
> But I don't know how to improve it. Can somebody tell me how, and show
> me some source code.

adding driver-level linedraw, clipping, and blit code has sped up my
25MHz target significantly.  there were also some speedups made for text
draw which were merged into the tree a few years back.

I've put a tarball of the our branch at
http://frye.com/~aaron/microwin-frye-nanosteve.1.tar.bz2 .

I have been working on merging with CVS and porting our local hacks
(including fast linedraw) to other framebuffer devices.  I'm almost
there except stipples and dashlists are still broken.

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  ####@####.####

Aaron J. Grier wrote:
> On Mon, Jan 21, 2008 at 10:44:43PM +0800, Lazy Fox wrote:
>   
>> Many people said that the efficiency of the NanoX is not high enough.
>> They said the functions which draw lines and polygon can be optimized.
>> But I don't know how to improve it. Can somebody tell me how, and show
>> me some source code.
>>     
>
> adding driver-level linedraw, clipping, and blit code has sped up my
> 25MHz target significantly.  there were also some speedups made for text
> draw which were merged into the tree a few years back.
>
> I've put a tarball of the our branch at
> http://frye.com/~aaron/microwin-frye-nanosteve.1.tar.bz2 .
>
> I have been working on merging with CVS and porting our local hacks
> (including fast linedraw) to other framebuffer devices.  I'm almost
> there except stipples and dashlists are still broken.
>
>   
Thanks for your sharing. I've downloaded your tarball, and will study 
the source code  that  you  changed.

I heard someboye said that the function "src/nanox/srvclip2.c: 
GsSetClipWindow()" can be speed up, do you
know about this?

-- 

On Thu, Jan 24, 2008 at 11:15:27PM +0800, Lazy Fox wrote:
> I heard someboye said that the function "src/nanox/srvclip2.c:
> GsSetClipWindow()" can be speed up, do you know about this?

in my limited experience (pre-0.89 days) the dynamic clipper was much
slower than the static clipper, I suspected due to malloc/free.  here at
Frye we got the static clipping code working again and continue to use
it.

are on a platform that supports profiling?

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  ####@####.####

: in my limited experience (pre-0.89 days) the dynamic clipper was much
: slower than the static clipper, I suspected due to malloc/free. 

The dynamic clipping code as added (borrowed from X11's
clipping routines) afterwards to support fancier clipping operations
than just screen clipping, including boolean operations between
multiple clip regions.  Its slower because its implementation requires
keeping y/x sorted lists of clip rectangles which are used by the
boolean operations implementations.  The static clipping was
written originally to handle screen clipping only.


: here at
: Frye we got the static clipping code working again and continue to use
: it.

Was this just fixing up some DYNAMICREGIONS defines, or 
was there more to this?  I didn't realize that there was much value
in the old clipping, but now would like to make sure this still works.


Regards,

Greg

On Thu, Jan 24, 2008 at 01:55:21PM -0700, Greg Haerr wrote:

> > here at Frye we got the static clipping code working again and
> > continue to use it.
> 
> Was this just fixing up some DYNAMICREGIONS defines, or was there more
> to this?  I didn't realize that there was much value in the old
> clipping, but now would like to make sure this still works.

I think that's all we had to do, along with doing some #if
DYNAMICREGIONS / #else / #endif calls to the clip code.  the static
clipper always seems to need at least one window mapped: our workaround
has been to create a new root-sized window after doing a GrOpen().  it
works well enough I haven't bothered to track it down further.

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  ####@####.####

1. I've downloaded you source code microwin-frye-nanosteve.1.tar.bz2,
and readed it, I found you make a lot of change from v0.89.
Can you describle the concept of your work simply? So I can
understand your code easily. Where should I start it?
2. You said "except stipples and dashlists are still broken",
I want to know do you still working on it? And do you have a
schedule to release it? Is the following address still available
in the future?
http://frye.com/~aaron/microwin-frye-nanosteve.1.tar.bz2

Aaron J. Grier wrote:
> On Mon, Jan 21, 2008 at 10:44:43PM +0800, Lazy Fox wrote:
>   
>> Many people said that the efficiency of the NanoX is not high enough.
>> They said the functions which draw lines and polygon can be optimized.
>> But I don't know how to improve it. Can somebody tell me how, and show
>> me some source code.
>>     
>
> adding driver-level linedraw, clipping, and blit code has sped up my
> 25MHz target significantly.  there were also some speedups made for text
> draw which were merged into the tree a few years back.
>
> I've put a tarball of the our branch at
> http://frye.com/~aaron/microwin-frye-nanosteve.1.tar.bz2 .
>
> I have been working on merging with CVS and porting our local hacks
> (including fast linedraw) to other framebuffer devices.  I'm almost
> there except stipples and dashlists are still broken.
>
>   

-- 
┏━━━━━━━━━━━━━━━━━━━━━━━━┓
┃菩提本无树，明镜亦非台。本来无一物，何处惹尘埃。┃
┗━━━━━━━━━━━━━━━━━━━━━━━━┛