Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!orca.dsd.es.com!mesa!rthomson
From: rthomson@mesa.dsd.es.com (Rich Thomson)
Newsgroups: comp.windows.x
Subject: X{Put,Get}Scanline (was Re: XImages)
Message-ID: <1990Dec19.225710.4008@dsd.es.com>
Date: 19 Dec 90 22:57:10 GMT
References: <935@attc.UUCP> <9012172158.AA07950@expire.lcs.mit.edu> <938@attc.UUCP>
Sender: news@dsd.es.com
Reply-To: rthomson@dsd.es.com (Rich Thomson)
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
Lines: 26

In article <938@attc.UUCP>
	marbru@auto-trol.UUCP (Martin Brunecky) writes:
>My main problem with XImage is that it does not have a SCANLINE interface.
>XGetPixel/XPutPixel has way too overhead for scanline access, so we must
>try to bypass it.
>If the XImage structure also provided:
>
>     XPutScanline ( XImage *image, int x, int y, Pixel *pixels, int length )
>     XGetScanline ( ....
>
>I (and probably everyone else) would forget about trying to understand the
>XImage pecularities, and just use those.

You are correct in that everybody would probably chuck the pixel
interface for a scanline interface, but why do you need to specify
x for a scanline?  I can understand y and length...

This kind of interface would be quite similar to the kind of interface
supported by the Utah Raster Toolkit (getrow/putrow).

							-- Rich
-- 
  ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon
	    Disclaimer: I speak for myself, except as noted.
UUCP: ...!uunet!dsd.es.com!rthomson		Rich Thomson
ARPA: rthomson@dsd.es.com			Software Engineer