rthomson@mesa.dsd.es.com (Rich Thomson) (12/20/90)
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
cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (12/20/90)
Rich Thomson writes (in reply to Martin Brunecky): > 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... It allows you to get or modify a section of the image that extends less than the whole width. The suggested routines are really reading and writing subrows rather than scanlines (XGetSubrow() and XPutSubrow()?). Chris Flatters
cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (12/21/90)
[ ... various stuff relating to XImages ...] Larry Granroth: > I haven't been following this, but what's wrong with XGetImage and > XPutImage? I've been generating spectrograms, etc, very successfully > using 1-pixel-wide images to move a scanline of data at a time to > the drawable. We are talking about getting the data into the *image* in a generic way without the overhead of calling XGetPixel/XPutPixel for every pixel. Chris Flatters
etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (12/29/90)
X{PutGet}ScanLine sounds like one of the best ideas I have heard
in a while concerning images. This would be a VERY good way to
speed up imaging applications without having to sacrifice
generality for different depths.
--
Eric Taylor
Baylor College of Medicine
etaylor@wilkins.bcm.tmc.edu
(713) 798-3776marbru@attc.UUCP (Martin Brunecky) (01/03/91)
In article <3391@gazette.bcm.tmc.edu> etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) writes: >X{PutGet}ScanLine sounds like one of the best ideas I have heard >in a while concerning images. This would be a VERY good way to >speed up imaging applications without having to sacrifice >generality for different depths. And it can be added to the XImage structure without any loss of (upwards) compatibility. Is anybody willing to contribute the code (just re-working the existing one in XImgUtil.c) so that Bob would *consider* adding this to R5 ? Sorry - I have no time to do it right now .... I am way behing even on my patches to Xrm.c -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
sundar@ai.mit.edu (Sundar Narasimhan) (01/04/91)
In article <949@attc.UUCP>, marbru@attc.UUCP (Martin Brunecky) writes: |> In article <3391@gazette.bcm.tmc.edu> etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) writes: |> >X{PutGet}ScanLine sounds like one of the best ideas I have heard |> >in a while concerning images. This would be a VERY good way to |> >speed up imaging applications without having to sacrifice |> >generality for different depths. |> |> And it can be added to the XImage structure without any loss |> of (upwards) compatibility. Is there any reason not to make this independent of the routines needed to deal with XImages? I can see other programs which have nothing to do with Images benefitting from X{PutGet}ScanLine.
marbru@attc.UUCP (Martin Brunecky) (01/04/91)
In article <12607@life.ai.mit.edu> sundar@ai.mit.edu writes: >In article <949@attc.UUCP>, marbru@attc.UUCP (Martin Brunecky) writes: >|> In article <3391@gazette.bcm.tmc.edu> etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) writes: >|> >X{PutGet}ScanLine sounds like one of the best ideas I have heard >|> >in a while concerning images. This would be a VERY good way to >|> >speed up imaging applications without having to sacrifice >|> >generality for different depths. >|> >Is there any reason not to make this independent of the routines >needed to deal with XImages? I can see other programs which have >nothing to do with Images benefitting from X{PutGet}ScanLine. If by "independent of the routines needed to deal with XImages" you mean X{Put|Get}ScanLine that would operate on a *drawable* as oposed to XImage, there is a reason: Such functions would require a protocol extension, UNLESS implemented as a convenience functions internally calling X{Put|Get}ScanLine operating on XImage and X{Put|Get}Image. Implementations using XDrawPoints etc. are also possible - but in most cases much less efficient than the one using the XImage interface. If we had the X{Put|Get}Image, writing such a convenience function would be trivial. In my opinion, going directly to a drawable for each scanline would not be very efficient. In my applications, I would always try to get/put an image strip using X{Get|Put}Image, process individual lines using X{Get|Put}ScanLine ( there are definitely tradeoffs - how many scanlines pers strip, neither 1 nor "ALL" being optimum - dependent on the client and server combination, transfer direction etc.). -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404