nanogui: CLPS7500FE chip is slowly


Previous by date: 1 Dec 2000 17:25:21 -0000 Re: CLPS7500FE chip is slowly, Greg Haerr
Next by date: 1 Dec 2000 17:25:21 -0000 nasty client/server bug fix, Greg Haerr
Previous in thread: 1 Dec 2000 17:25:21 -0000 Re: CLPS7500FE chip is slowly, Greg Haerr
Next in thread: 1 Dec 2000 17:25:21 -0000 Re: CLPS7500FE chip is slowly, Alan Cox

Subject: Re: CLPS7500FE chip is slowly
From: "Greg Haerr" ####@####.####
Date: 1 Dec 2000 17:25:21 -0000
Message-Id: <05c701c05bbb$ff513d20$15320cd0@gregh>

: Nanogui's rendering code is nowhere near as good

Sigh ;-(  Unfortunately, Alan is right.  The Microwindows framebuffer
routines are written to be simple, and simple in graphics is usually
slower.  In order to be blazingly fast in graphics, every possible
drawing mode, as well as inner loops, need to be separately
coded.  This is one of the reasons X is big.  And I think that's also
one of the reasons that Windows is big.  (Of course, the bloat in
windows is probably only 10% in the GDI screen drivers, everywhere
else it's to support the damned MFC and other 4980 API entry points.)

Having said that, with small screens, it's usually not a big issue
since fewer pixels are being pushed.

The real demonstration is running Microwindows on ELKS 8086 Linux.
Then you'll see how hurtfull it is to try to push 640x480 pixels on 
an 8088...  Asm routines are a must.

Regards,

Greg



Previous by date: 1 Dec 2000 17:25:21 -0000 Re: CLPS7500FE chip is slowly, Greg Haerr
Next by date: 1 Dec 2000 17:25:21 -0000 nasty client/server bug fix, Greg Haerr
Previous in thread: 1 Dec 2000 17:25:21 -0000 Re: CLPS7500FE chip is slowly, Greg Haerr
Next in thread: 1 Dec 2000 17:25:21 -0000 Re: CLPS7500FE chip is slowly, Alan Cox


Powered by ezmlm-browse 0.20.