[9fans] graphics

[9fans] graphics

[andrey mirtchovski]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1794 bytes --]

hi,

i spent the weekend trying to learn more about the plan9 graphics model and
trying to write a simple program (started off with russ cox' click.c and
worked on top of it) and i must say i am quite impressed with the ease with
which programs are created, relative size, simplicity and speed...

included is a simple program that emulates one of the x-screensavers by
drawing random squares in the window it is started in... one can use it
mostly for speed-evaluation and/or to tell me if there is any problem with
terminals running in less-than-24 bit mode...


several questions popped up while i was implementing it:

	the 'eresized()' routine seems not to be called if the program is not
	waiting on any event. e.g. in one of my earlier implementations i lacked
	a call to ecanread/emouse/emenuhit in the main loop and as a side effect
	eresized was not called when the window was moved... it only started
	working after i added (any) of the abovementioned function calls.

	it is possible to force the machine to reboot if one mistakingly forgets
	to free the allocimagemix pointer after the recangle is drawn... this seems
	to be a big problem, because i've always assumed a runaway process that
	takes up the entire memory would just be terminated instead of causing
	the machine to reboot... or maybe plan9 does things in a different way?
	:)


well.. comments/flames are welcome :)


cheers: andrey


PS: obligatory screenshot of plan9 in 'working condition' is available from

	http://homepage.usask.ca/aam396/scrsht.gif

you can see my irc client running in the bottom left corner of the screen,
the language spoken is bulgarian (transliterated)...

the entire page is not operational though, i'm just using it for this
screenshot...
	

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1931 bytes --]

/* draw random rectangles in the current window
* sort of like the xscreensaver we all know
* -- andrey
*/

/* based on russ cox' click.c */


#include <u.h>
#include <libc.h>
#include <draw.h>
#include <thread.h>
#include <event.h>

int minx, miny, maxx, maxy;

void
eresized(int new)
{
	Rectangle r;
	if(new && getwindow(display, Refnone) < 0)
		fprint(2,"can't reattach to window");
	r = screen->r;
	minx = r.min.x;
	miny = r.min.y;
	maxx = r.max.x;
	maxy = r.max.y;
	draw(screen, screen->r, display->white, nil, ZP);
}

void
main(int argc, char **argv)
{
	Mouse m;
	Image *img;
	Rectangle r;
	int i;
	int slp = 10;

	char *items[] = { "slower", "faster", "exit", nil };


	Menu menu;

	/* setup menus */
	menu.item = items;
	menu.gen = nil;

	srand(0);

	initdraw(0,0,"whoopty doo");
	eresized(0);
	einit(Emouse);


	for(;;){
		if(ecanmouse())	{
			m = emouse();
			if(m.buttons & 4) {
				switch(emenuhit(3, &m, &menu)) {
					case 0: 	slp += 10; break;
					case 1: 	if(slp) 
									slp -= 10;
								else 
									slp = 0; 
								break;
					case 2: 	exits("user abort");
					default: 	fprint(2, "impossible button\n");
				}
			}
		}
		
		/* draw a rectangle somewhere in the window */
		/* make sure rectangle does not overflow window */
		r.min.x = minx + nrand(maxx - minx);
		r.min.y = miny + nrand(maxy - miny);
		r.max.x = r.min.x + nrand(maxx - r.min.x);
		r.max.y = r.min.y + nrand(maxy - r.min.y);

		/* get a random color and random alpha for drawing */
		/*** probably not the best way of doing it ***/
		img = allocimagemix(display,nrand(256)<<24 | nrand(256) << 16 | nrand(256) <<8 | (256 - nrand(256)),nrand(256)<<24 | nrand(256) << 16 | nrand(256) <<8 | (256 - nrand(256)));

	 	draw(screen, r, img, nil, ZP);
		flushimage(display, 1);
		freeimage(img);
		/* slow down the drawing somehow */
		sleep(slp);
	}
}

Re: [9fans] graphics

[ron minnich]

On Mon, Aug 6, 2012 at 10:54 AM, Charles Forsyth
<charles.forsyth@gmail.com> wrote:
> Isn't that the same as vga, then?

OK you win :-)

ron

Re: [9fans] graphics

[Charles Forsyth]

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

Isn't that the same as vga, then?

On 6 August 2012 13:42, ron minnich <rminnich@gmail.com> wrote:

> This is not vga ... it gets messy.

[-- Attachment #2: Type: text/html, Size: 385 bytes --]

[9fans] graphics

[ron minnich]

This just hit phoronix:
http://www.phoronix.com/scan.php?page=news_item&px=MTE1NDc

I'm extracting a driver from linux for use in coreboot, using the
semantic patch tool. The goal is to let coreboot draw a splash screen
in the first 200 milliseconds or so after power on. I've got a lot of
bits working, as I explained in my question to the list. Graphics
drivers are, I am finding, a very hard thing to extract, esp. the
intel drivers, as the GPUs are very complex, and the hardware more so:
every link needs to be trained. This is not vga ... it gets messy.

This is not the same as a shim to let you run source. It's rewriting
source with semantic patches, and it's much more powerful.

It has occurred to me more than once that one could use this same
technique to programatically create native hardware
drivers for plan 9 and avoid vesa.

You might even be able to get coccinnelle running on plan 9 with
cinap's excellent linuxemu tool so you can do the patch.

ron

Re: [9fans] graphics

[Russ Cox]

	the 'eresized()' routine seems not to be called if the program is not
	waiting on any event. e.g. in one of my earlier implementations i lacked
	a call to ecanread/emouse/emenuhit in the main loop and as a side effect
	eresized was not called when the window was moved... it only started
	working after i added (any) of the abovementioned function calls.

Resize messages are sent over /dev/mouse.
Emouse and friends call eresized when they 
get one.  So if they aren't being called, you'll
ignore resize events.

	it is possible to force the machine to reboot if one mistakingly forgets
	to free the allocimagemix pointer after the recangle is drawn... this seems
	to be a big problem, because i've always assumed a runaway process that
	takes up the entire memory would just be terminated instead of causing
	the machine to reboot... or maybe plan9 does things in a different way?

It shouldn't have rebooted.  That's a bug.
The reason it rebooted is that you ran the
kernel out of image memory, and probably
some allocation somewhere failed and isn't
checked properly.

One of my projects for the coming year is
a reimplementation of most of the draw
stuff, to clean up this sort of thing.  A cursory
look through /sys/src/9/port/devdraw.c
doesn't produce anything promising.

Russ