🚀 go-pugleaf

In article <672@atari.UUCP> leavens@atari.UUCP (Alex Leavens) writes:
>in article <8703170112.AA00614@ucbvax.Berkeley.EDU>, JANKOWSJ@UNION.BITNET says:
>>              Is there any-hacker in this universe that can assist me in
>>          finding information about working with the G.E.M. functions
>
>        2)  Make _sure_ that your source and destination blocks the
>            same size.
	Although I have yet to try it, According to Abacus, when given differing
sizes of blocks, the system uses the size of the source block.

>
>        3)  Make sure the pixel width of your raster is an even multiple
>            of a word size (ie, 16).
	This is only necesairy when speed is at a premium. The routines can
handle bit-boundaries. This brings up an interesting point of interface theory.
I have noticed that many GEM programs snap windows to 16bit boundaries.
I fully understand the rational for this, but I don't think I agree with it.
Though doing this increases speed, it very much reduces the quality of the user
interface. Snapping takes away the feelinng that what you do is what you get.
	I would rather have the machine do EXACTLY what i want, and decide when
running a program whether I want 16 bit boundaries. This is sort of a time-
interface tradeoff. One of many in a windowing system!
>
>        4)  You probably want to make sure that your source and destination
>            rectangles don't overlap.
	I can see no real reason for this. The routines are "smart" and can
transfer over each other.

>
>Good luck!
Yup!

					Pete Santangeli
					pete@utgpu