[9fans] optimizing graphics

[9fans] optimizing graphics

[mirtchov]

I'm shopping for optimization suggestions for the following:

another xscr port:

	http://pages.cpsc.ucalgary.ca/~mirtchov/p9/xscr/eruption.gif

performs relatively slow on plan9 (huge discrepancy between plan9 and
X).  the application involves drawing a large amount of pixels on the
screen and is currently doing a loop very similar to this:

	foreach y in Dy(screen->r) {
		foreach x in Dx(screen->r) {
			"draw() a 1x1 rectangle at (x,y), taking the
			colour from a previously alloc-ed image"
		}
	}

i have tried double-buffering (drawing to an offline image, then after
the loop is done draw-ing the image itself) and have contemplated
drawing to an array of pixels, then displaying it with 'loadimage()'.
another possibility is writing the pixel directly to the screen
image...

this particular one is implemented in X as a XPutPixel() to an offline
image, which then gets displayed with XPutImage() after the loop is
done.

you can find the code on the page abore (xscr.tar.gz), but run it
through a C beautifier before you look at it (jwz likes emacs)

comments and suggestions welcome -- this is more of a learning issue,
than an implementation one.

andrey

Re: [9fans] optimizing graphics

[andrey mirtchovski]

i did try writing the pixels as CMAP8 (uchar) values to an array, and then
doing the old:

	loadimage(img,...)
	draw(...,img,...);

trick. it's much faster now for small sizes, with bigger ones it taps out
the connection and becomes slow again (but slightly faster than before).

i guess the next step would be one of:

	- modify the image directly
	- add a function to draw() that displays an array of pixels (a-la
	  XDrawPixels()).
	- don't do CMAP8 but create the image with the channel of the screen
	- do nothing

the first one is complex, the second is unnecessary, the third one i'm not
sure will work and the fourth is the default.

what's really puzzling (perhaps not) is that the new hack i did today,
polyominoes:

	http://pages.cpsc.ucalgary.ca/~mirtchov/p9/xscr/polyominoes.gif

is much, much, Much faster than eruption, even though it displays many more
pixels on the screen (but it does larger rectangles, instead of just pixel
by pixel)...

for those who care, you can get the latest ones from:

	http://pages.cpsc.ucalgary.ca/~mirtchov/p9/xscr/xscr.tar.gz

andrey

ps: we need a code convertor to beautify the nasty code those xscreensavers
come with. if you don't have anything like that already (seems to me this
topic was discussed in 9fans) i may port the gnu indent.

Re: [9fans] optimizing graphics

[Geoff Collyer]

presotto ported cb, but I don't see it in the distribution.
dave, could you put it on sources?

Re: [9fans] optimizing graphics

[jmk]

On Fri Sep  5 18:46:29 EDT 2003, mirtchov@cpsc.ucalgary.ca wrote:
> ...
> ps: we need a code convertor to beautify the nasty code those xscreensavers
> come with. if you don't have anything like that already (seems to me this
> topic was discussed in 9fans) i may port the gnu indent.
> ...

Something I looked at recently in the XFree86 distribution had this
at the beginning of a number of files:

/*
 * Reformatted with GNU indent (2.2.8), using the following options:
 *
 *    -bad -bap -c41 -cd0 -ncdb -ci6 -cli0 -cp0 -ncs -d0 -di3 -i3 -ip3 -l78
 *    -lp -npcs -psl -sob -ss -br -ce -sc -hnl
 *

Re: [9fans] optimizing graphics

[mirtchov]

>  *    -bad -bap -c41 -cd0 -ncdb -ci6 -cli0 -cp0 -ncs -d0 -di3 -i3 -ip3 -l78
>  *    -lp -npcs -psl -sob -ss -br -ce -sc -hnl
>  *

my plan was to strip everything but the options for Plan 9-style code
and then make those the default :)

something like the above was the 'recommended' way of submitting
assignments for an Operating Systems course I TA'd last semester at
the UofCalgary..  can't help but feel sorry for those learning C on
EMACS.

Re: [9fans] optimizing graphics

[boyd, rounin]

> ps: we need a code convertor to beautify the nasty code those xscreensavers
> come with.

nope, you write it right the first time.

Re: [9fans] optimizing graphics

[boyd, rounin]

> /*
>  * Reformatted with GNU indent (2.2.8), using the following options:
>  *
>  *    -bad -bap -c41 -cd0 -ncdb -ci6 -cli0 -cp0 -ncs -d0 -di3 -i3 -ip3 -l78
>  *    -lp -npcs -psl -sob -ss -br -ce -sc -hnl
>  *

'rain coming down heavily at lords'

Re: [9fans] optimizing graphics

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 151 bytes --]

I don't remember doing it.  It really is hell to get old.  I'll see if
I can find a version somewhere.  I converted rc by applying a sam script to it.

[-- Attachment #2: Type: message/rfc822, Size: 1811 bytes --]

From: Geoff Collyer <geoff@collyer.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] optimizing graphics
Date: Fri, 5 Sep 2003 16:01:33 -0700
Message-ID: <668c415394bcff6b8a6ea2868dc2a576@collyer.net>

presotto ported cb, but I don't see it in the distribution.
dave, could you put it on sources?

Re: [9fans] optimizing graphics

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 20 bytes --]

It's on sources now.

[-- Attachment #2: Type: message/rfc822, Size: 4009 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 151 bytes --]

I don't remember doing it.  It really is hell to get old.  I'll see if
I can find a version somewhere.  I converted rc by applying a sam script to it.

[-- Attachment #2.1.2: Type: message/rfc822, Size: 1811 bytes --]

From: Geoff Collyer <geoff@collyer.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] optimizing graphics
Date: Fri, 5 Sep 2003 16:01:33 -0700
Message-ID: <668c415394bcff6b8a6ea2868dc2a576@collyer.net>

presotto ported cb, but I don't see it in the distribution.
dave, could you put it on sources?

Re: [9fans] optimizing graphics

[mirtchov]

> It's on sources now.

i ran all the xscreensaver code through it. some of the
improvements are questionable at best :)

example:
			tmpx = xmid + ((       radius1	          /* * * * *            */
			- radius2        )		 /* This algo simulates	*/
			    * cos((      theta 		/* the rotation of a    */
			* M_PI           ) 		/* circular disk inside */
			    / 180           )) 		/* a hollow circular 	*/
			    + (              d 		/* rim. A point on the  */
			* cos((((  radius1 		/* disk dist d from the	*/
			* theta          )		/* centre, traces the 	*/
			    - delta          )		/* path given by this   */
			    / radius2        )  		/* equation.	        */
			    *             M_PI		/* A deviation (error)  */
			/ 180            )            /* of delta needs to be */
			    );           /* given, which greatly */
			/* adds to the beauty   */
			tmpy = ymid + (				/* of the figure.       */
			( radius1 - radius2	/*			*/
			) * sin			/* Imperfection adds to */
			(			/* beauty, symbolically */
			( theta * M_PI     	/* ...			*/
			) / 180		/* Algo deduced by      */
			)			/* Rohit Singh, Jan'00  */
			    ) +                  /* based on a toy he    */
			( d * sin           /* used to play with    */
			(                  /* when he was a kid.  */
			(                 /*            * * * * */

but it's not cb's fault, i'm sure!

there's a bug in cb.c while parsing comments within structure
definitions.  for example the following is parsed incorrectly:

--------snip----------
static double plane_orig[][2][3] = {
	/* X goes into screen, Y goes right, Z goes down(up?) */
	/* {Normal}, {Point} */
	{ {1.0, 0, 0}, {0.01, 0, 0} },
--------/snip---------

rezulting in non-compileable code:

--------snip----------
static double plane_orig[][2][3] = {
	{Normal}
, {
	Point}
*/
{
	{
		1.0, 0, 0},
		{0.01, 0, 0	}
	},
--------/snip---------

here's a diff that fixes this particular problem (and creates a couple
of warnings), it works for me, but i'm not really completely 100%
surely positive that it's the right solution:

--------snip----------
plan9-2% diff cb.c /sys/src/cmd/cb/cb.c
960c960
< 	return(lastplace);
---
> 	return(beg);
plan9-2%
--------/snip---------


CB also doesn't recognize C++-style '//' comments, or at least it
renders them incorrectly if they contain any tokens suck as '}' or
')', try cb on this for example:

	// this is a comment with a smiley at the end :)


andrey

Re: [9fans] optimizing graphics

[Russ Cox]

this is why it wasn't on sources.
it's hardly ever useful.

Re: [9fans] optimizing graphics

[mirtchov]

> this is why it wasn't on sources.
> it's hardly ever useful.

back to gnu ident then?

i want to convert ported code to the plan 9 style not only for
aesthetic reasons, but because it's much easier to read -- case in
point is trying to grasp the png library that comes with ghostscript
in order to fix the bug in png(1)...

andrey

Re: [9fans] optimizing graphics

[Geoff Collyer]

I have found cb useful, but it probably depends upon the particular
bad style used in the original code.  You want to invoke it as
`cb -sj' for best results.

Re: [9fans] optimizing graphics

[okamoto]

> can't help but feel sorry for those learning C on
> EMACS.

I may be worse, because I have to coach 40 freshmens Windows this autumn.
I don't want to do it, then, I'm planning to do it by CDROM LINUX (Knoppix).
If we could have such of Plan 9, I'll use it of course.  I think to teach something
in blackbox does not make sense in University. ☺

Kenji