nanogui: Thread: Confused by hack

: Index: engine/devdraw.c
: ===================================================================
: RCS file: /sw/CVSROOT/freepad/microwin/src/engine/devdraw.c,v
: retrieving revision 1.1.1.1
: diff -u -4 -r1.1.1.1 devdraw.c
: --- engine/devdraw.c    1999/12/20 09:19:14     1.1.1.1
: +++ engine/devdraw.c    2000/01/04 12:27:24
: @@ -1296,9 +1296,9 @@
:                 /*
:                  * For size considerations, there's no low-level area
:                  * draw, so we've got to draw everything with per-point
:                  * clipping for the time being
: -               if(pixtype != PF_PIXELVAL)
: +               if(pixtype != PF_PIXELVAL && pixtype != PF_TRUECOLOR565)
:                         break;
:                 psd->DrawArea(psd, x, y, width, height, pixels);
:                 GdFixCursor();
:                 return;

: The first patch to devdraw.c is a hack; it made it possible to use
: PF_TRUECOLOR565 on the client side, which should work when the server
: usese the same format natively.  This test should really look quite
: different and be dependent on the SCREEN_PIXTYPE macro instead (nanox
: server compile time option), but I have not tested this.

Morten - I'm a little confused by this "hack", since it's totally inside a
comment.
The screen driver doesn't currently implement a DrawArea method, so it's
completely commented out.  So what do you mean by "made it possible
to use PF_TRUECOLOR565 on the client side"?

Greg

Greg Haerr wrote:
> 
> Morten - I'm a little confused by this "hack", since it's totally inside a
> comment.

Hmm, OK - If you say so! :-)  It is totaly bogous - not used and probably
not working if it where... I interpreted the code to be "don't paint
unless native PF_PIXELVAL is specified by the client, which in retrospect
seems so stupid that I should have realised the mistake was on my part!

Throw it away.  I start to realize how unmaintainable, strange and
suspect open source code gets written...:-/

- Morten

 I interpreted the code to be "don't paint
: unless native PF_PIXELVAL is specified by the client, which in retrospect
: seems so stupid that I should have realised the mistake was on my part!

The proper interpretation is "don't call the low level driver
routine directly unless the pixel format is in the hw pixel format"
Otherwise the code drops through to the conversion routines below...

Regards,

Greg