scott@graft.Berkeley.EDU (Scott Silvey) (07/10/90)
If I want to draw billions of points on an in-memory image (not displayed), which of these two calls would be faster? Thanks, Scott
jimf@SABER.COM (07/10/90)
|If I want to draw billions of points on an in-memory image (not displayed), | which of these two calls would be faster? XPutImage by orders of magnitude. XDrawPoints has a lot more overhead and can only handle about 16,000 points per call (used to be 32,000 but that changed in R3 -- both of these figures are for the sample server). I used to use XDrawPoints for sending images to a pixmap but its performance was so abysmal that I gave up. jim frost saber software jimf@saber.com
elliott@hpfcdq.HP.COM (Ian Elliott) (07/11/90)
> If I want to draw billions of points on an in-memory image (not displayed), > which of these two calls would be faster? I would suggest using neither. Use XDrawPoints, which will give you better network/IPC bandwidth/performance. If you don't want to or can't do that, I'd suggest XDrawPoint simply because there is less protocol data and the primitive is normally quite fast (or should be). Ian Elliott
jimf@SABER.COM (07/13/90)
|I would suggest using neither. Use XDrawPoints, which will give you |better network/IPC bandwidth/performance. If you don't want to or can't |do that, I'd suggest XDrawPoint simply because there is less protocol |data and the primitive is normally quite fast (or should be). Not for "billions" of points; when I was sending across about a million points (roughly) I found that it took many seconds (more than 30 if I remember right, although this was R2) on a Sun 386i versus under one for XPutImage. If you need point granularity you can send two images across -- one which is a mask of points to plot and the other containing the point data and draw the data through the points. This is still faster than XDrawPoints for large numbers of points even though you're sending more data over the wire. This technique requires quite a bit of server memory though. jim frost saber software jimf@saber.com
jorice@maths.tcd.ie (Jonathan Rice) (07/16/90)
>> If I want to draw billions of points on an in-memory image (not displayed), >> which of these two calls would be faster? In <890047@hpfcdq.HP.COM> elliott@hpfcdq.HP.COM (Ian Elliott) writes: >I would suggest using neither. Use XDrawPoints, which will give you >better network/IPC bandwidth/performance. If you don't want to or can't >do that, I'd suggest XDrawPoint simply because there is less protocol >data and the primitive is normally quite fast (or should be). As I see it, this discussion should start with asking "What sort of picture do you want to draw?" and "In what way does your algorithm produce the points that it wants to plot?" I can't see that one can give an absolute answer to the original question - you have to see which method suits the program. To give an example, say that what you want to completely fill an image with points of a random colour - noise, essentially. The easiest way to do this is to fill an XImage with random values in scanline order on the client side and then whack it into a Pixmap or window on the server with XPutImage. It would be a very bad idea to use XDrawPoints in this case because each call plots in a single colour. If you are proceeding along scanlines drawing the image, you'd have to change the plotting colour for almost every pixel, for the case I've described, so you'd have to issue a separate plotting command for each pixel. That's a lot of protocol. And if you use XDrawPoints() more efficiently, by trying to draw all like-coloured points in the image on each call, then you'll probably run into problems in my example keeping track of just which pixels you have plotted and which you haven't. For this example, some sort of scanline-order plotting with rapid colour changing is the obvious solution. This just isn't suited to the same-colour, coordinate-based operation of XDrawPoints(). To give a counter-example, the best case for XDrawPoints() would be, say, in drawing star maps, where you might only have a dozen different colours of stars and you want to draw all the whites, then all the reds, etc. It'd be inefficient to use XPutImage() in this case, because most of the XImage you'd be transferring to the server would be empty. All this seems sensible to me, anyway, but no, I haven't done any tests. -- Jonathan o----------------------o----------------------------o--------------------------o | Jonathan Rice | Email: jorice@cs.tcd.ie | He was a common fly | |----------------------| Tel: 353.1.772941 x2156 (w)| With a taste for fashion | |Computer Science Dept.| 353.1.6245415 (h)| They were thrown together| | Trinity College | Fax: 353.1.772204 | In a heat of passion | | Dublin 2, | woof /\___/ | - "Human Fly", | | Ireland. | /| |\ | The Horseflies | o----------------------o----------------------------o--------------------------o
scott@graft.Berkeley.EDU (Scott Silvey) (07/17/90)
Ok, I've learned something here. I didn't realize that XGetImage actually made a local copy of the pixmap. That is very good to know. I thought XGet/PutPixel() did and X operation each time, but I just wasn't thinking. So here is a summary of the responses at this point: If you have more than 30000 points to draw, XGet/PutImage() along with XGet/PutPixel() is much better becuase you muck around with the actual data locally and you blast the finished image over to the server when you are done. XDrawPoints() does an X operation each time which is slower if you have to do several of these (bunches of 30000 points). However, it is faster if you only need to do one batch or if your pixmap is huge. Am I correct in my understanding of these issues that people have presented? Does having a huge image cause XGet/PutImage() to slow down significantly so that XDrawPoints() becomes an attractive alternative? Scott
jimf@SABER.COM (07/17/90)
|If you have more than 30000 points to draw, XGet/PutImage() along with | XGet/PutPixel() is much better becuase you muck around with the | actual data locally and you blast the finished image over to the | server when you are done. A better rule-of-thumb might be that if you have more points than you can send in a single XDrawPoints command (circa 16000 for the stock R4 server I believe -- it was double that for R3 if I remember right), consider some other way. It doesn't take too many points to cause the per-point overhead to exceed what an image would use, so even this isn't too accurate. |Does having a huge image cause XGet/PutImage() to slow down | significantly so that XDrawPoints() becomes an attractive | alternative? Not unless it's a very *small* image in which case it doesn't really matter which way you go. jim
bob@quisp.Philips.Com (Robert A. Cohen) (03/21/91)
I am using XCreateImage() to create several images of 2-D data. These
images are displayed in a loop using XPutImage(). This method
works well for small arrays, but it becomes too slow for larger
images. I've been able to obtain faster display rates
using pixrect operations on SUNs, but I would prefer to
use only X routines. Is there a faster way to display sequences
than using XPutImage() in a loop?
Thanks,
R. Cohen
bob@philabs.philips.comrandy@erik.UUCP (Randy Brown) (03/22/91)
From: uunet!quisp.philips.com!bob (Robert A. Cohen)
Message-Id: <118960@philabs.Philips.Com>
Is there a faster way to display sequences
than using XPutImage() in a loop?
If you have enough room in the server to create pixmaps
(off-screen drawables), you can then copy them to the
screen with XCopyArea, which is usually much faster than
XPutImage. If your server supports the shared memory
extension MIT-SHM (use xdpyinfo to find out) you can
allocate pixmaps in client memory and share them with
the server, allowing both client and server to draw
quickly into the pixmap, with rapid display via a
call to XCopyArea and no actual transmission of the
image through the client-server connection.
There is also a double-buffering and amimation extension
that I don't know anything about--I offer this only as
an exercise for the ambitious reader. One advantage is
that timing is done in the server, which is presumably
no less precise than timing in the client, and doesn't
get changed by variations in the connection delay.
Sequences each image of which require only a few of many
available colors can be displayed by overlaying them in
various planes of a single window and changing colormaps
to display specific planes, with "don`t care" values for
the other planes. Changing colormaps is fast on most
servers.doug@genmri.UUCP (Doug Becker) (03/22/91)
Is there a faster way to display sequences
than using XPutImage() in a loop?
That depends on your environment, your application, and on the tradeoffs
you're willing to make. Here are two alternatives:
1. Use pixmaps and XCopyArea. (That is, create your image, XPutImage it
into a pixmap, and XCopyArea the pixmap into your window.) In my
environment, this method can be 5-7 times faster than XPutImage. The
disadvantage of this approach is that it is costly in terms of server
resources (mainly memory). This can be a significant drawback,
especially if your image is deep, your pixmaps are large, or server
memory is limited.
2. Use MIT-SHM (the shared memory extension -- XShmPutImage). In my
environment (and depending on the size of the image), this is only
marginally slower than pixmaps, and consumes fewer resources (a shared
memory segment and ID). The major disadvantages to this method are
that it only works locally (i.e., when the server and the client are
running on the same machine), and that MIT-SHM is a nonstandard,
experimental extension, which means that you cannot rely on every
server supporting it.
A third alternative is XIE (the X Image Extension). I've no experience
with that, so I'll leave it to an XIE expert to comment.
--
Doug Becker
doug@nmri.ge.com
crdgw1!sane!doug