Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!ucsd!ucbvax!bloom-beacon!LIGHTNING.MCRCIM.MCGILL.EDU!mouse
From: mouse@LIGHTNING.MCRCIM.MCGILL.EDU
Newsgroups: comp.windows.x
Subject: Re:  XFillRectangle with Tile Vs Manual tiling
Message-ID: <9011071055.AA00699@lightning.McRCIM.McGill.EDU>
Date: 7 Nov 90 10:55:15 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 89

> I have a question regarding tiling rectangular areas of a drawable.

> In the course of writing a widget I have been considering the
> question of tiling a rectangular area of a drawable.  I have tried
> the obvious way of doing this, i.e., setting the tile attribute of a
> gc, the ts_x_origin, ts_y_origin, and the fill style to FillTiled,
> and the not-so-obvious way, i.e., doing it yourself.

> In both cases I was using a Pixmap to tile a drawable.  I found (much
> to my surprise) that the not-so-obvious way was MUCH faster (one my
> Sparcstation 1) with an area about twelve times the area of the tile.
> This seems bizzare to me, after all the obvious way requires one trip
> to the server, while the not-so-obvious way requires many trips.

> Has anyone else noticed such behaviour, or have I most likely
> overlooked something?

I see a similar difference, and find it rather astonishing.

> I've written two raw Xlib programs to demonstrate the problem.

[excerpted -dM]

	Xgcvalues.tile = XCreatePixmapFromBitmapData(mydisplay,mywindow,
	X                pixbits,120,120,foreground,background,
	X		DefaultDepth(mydisplay,myscreen));
...
	Xfor (i=0;i<1200;i++) {
	X	/* set the TS origins here because in general what I want to
	X           do requires this (scrolling over a pixmap) */
	X	gcvalues.ts_x_origin = i;
	X	gcvalues.ts_y_origin = i;
	X	XChangeGC(mydisplay,tilegc,
	X		GCTileStipXOrigin|GCTileStipYOrigin,&gcvalues);
	X	XFillRectangle(mydisplay,mywindow,tilegc,
	X		0,0,360,480);
	X	XFlush(mydisplay);
	X}

[versus]

	Xthepixmap = gcvalues.tile = XCreatePixmapFromBitmapData(mydisplay,mywindow,
	X                pixbits,120,120,foreground,background,
	X		DefaultDepth(mydisplay,myscreen));
...
	X/* first tile the window twelve hundred times */
	Xprintf("Tile the window twelve hundred times using XCopyArea/Plane\n");
	Xfor (i=0;i<1200;i++) {
	X  for (tmpsx=MD(-i,120); tmpsx<360; tmpsx+=120)
	X    for (tmpsy=MD(-i,120);tmpsy<480;tmpsy+=120) {
	X        if (DefaultDepth(mydisplay,myscreen) == 1)
	X            XCopyArea(mydisplay, thepixmap, mywindow, 
	X		copygc, 0, 0, 120, 120, tmpsx, tmpsy);
	X        else
	X            XCopyPlane(mydisplay, thepixmap, mywindow, 
	X		copygc, 0, 0, 120, 120, tmpsx, tmpsy);
	X    }
	X  XFlush(mydisplay);
	X}

I see a similar speed difference.  My environment is the MIT sample
server on a Sun-3/60 with a "hi-res" (1600x1280) display.  You don't
say whether your SS1 is color or not, but I would guess not, because
you're missing the last argument to XCopyPlane.  (You also don't say
whose server you're using, but I suspect it doesn't make much
difference.)

Also note that the semantics of FillTiled are such that you should
always be using XCopyArea in the second program, to be fair.  However,
on a one-bit display, you are, and the speed difference is still
present.  In the interests of fairness, I also tried copying the
XChangeGC call into the outer loop in the second program.  It made no
visible difference.

Out of curiousity, I did delete the if and try it on a color machine, a
color SPARCstation 1+.  The speed difference is essentially gone.
However, the XFillRectangle code doesn't even work!  (It looks as
though something is getting confused with negative values somewhere.  I
shall be submitting a bug report....)  Aside from that, the
XFillRectangle code is aesthetically much nicer; the fills proceed in a
visually more even fashion.

I'd say the FillTiled code in the server needs work.  It really should
never be slower than doing many individual copies....

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu