pat@deimos.greco-prog.fr (Lutmann Patrice) (09/13/90)
Hi! The problem: I'd like to do some rudimentary screen dumps and if possible, very quickly. I can do that using XGetImage or XGetSubImage. The manual says that XGetImage allocates both the XImage structure and the space for the image itself, but XGetSubImage just updates the XImage structure passed as argument. In some cases, I want to update an existing XImage, so, XGetSubImage seems to be a good way... :-( but... it's *SLOWER* than XGetImage (which creates a new one). I do some screen dumps (image size: 300x300): with XGetImage, it takes about 0.1 s. with XGetSubImage, it takes more than 5 s. Could someone tell my why? Is there a better method? I'm working on a DS3100 (color), 16 Mb, and X11R4 of course. Pat. ============================================================================== Pat@deimos.Greco-Prog.Fr [] Computer Science ..!Uunet!Mcsun!Inria!Geocub!Deimos!Pat [] C.I.C.B.X ==============================================================================
mouse@LARRY.MCRCIM.MCGILL.EDU (09/16/90)
> The problem: I'd like to do some rudimentary screen dumps and if > possible, very quickly. I can do that using XGetImage or > XGetSubImage. The manual says that XGetImage allocates both the > XImage structure and the space for the image itself, but XGetSubImage > just updates the XImage structure passed as argument. In some cases, > I want to update an existing XImage, so, XGetSubImage seems to be a > good way... :-( but... it's *SLOWER* than XGetImage (which creates a > new one). > I do some screen dumps (image size: 300x300): > with XGetImage, it takes about 0.1 s. > with XGetSubImage, it takes more than 5 s. One possibility is that the existing XImage you're updating with XGetSubImage does not use the server's "natural" bit order and byte order, forcing XGetSubImage to do conversions instead of just dumping the data in as received from the wire. XGetImage, which can create the XImage with whatever bit and byte order it finds convenient, doesn't have to handle each pixel; it can just copy the data from the wire to the image's data area directly. It seems doubtful to me that this is the problem, because you likely created the image with a previous XGetImage. It may be that your library's XGetSubImage is stupid and handles the pixels individually even when it doesn't have to. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
keith@EXPO.LCS.MIT.EDU (Keith Packard) (09/16/90)
Somehow I missed the original message. > > I do some screen dumps (image size: 300x300): > > with XGetImage, it takes about 0.1 s. > > with XGetSubImage, it takes more than 5 s. > > One possibility is that the existing XImage you're updating with > XGetSubImage does not use the server's "natural" bit order and byte > order > > It seems doubtful to me that this is the problem, because you likely > created the image with a previous XGetImage. The cause of the speed penalty in this case, if der Mouse is correct is that the Xlib routines for copying data around inside images is *painfully* slow; it is not optimized like the server side bitblt routines. Take a look inside the routine _XSetImage (which XGetSubImage uses) - a doubly nested loop enclosing XGetPixel and XPutPixel. If you were writing code, you'd be hard pressed to find a slower way to do this job. XGetImage doesn't need to copy the image again, so it runs much faster. If you really want to use the functionality of XGetSubImage, I'd suggest finding a way to do it inside the server, and then fetching the entire image back in one step. If you're really adventurous, you might look at the MIT-SHM extension provided with R4 which gives you shared pixmaps between client and server (as long as they're on the same machine). That way you could use the server CopyArea functions instead of GetImage for the entire job. Keith Packard MIT X Consortium
inoue@sunburst.crd.ge.com (Takesi Inoue) (03/05/91)
I have a question. What I want to do is to start emacs processes as subprocesses of one X application. How can I let emacs be iconified and deiconified from the parent process? I also want to tell emacs to be raised when it is covered by other windows. How can the parent application tell a window manager to do so? I can manipulate windows from inside using XIconifyWindow or smt like that. In order to do that from outside in cases above, I think the parent process should know at least the window ID of child processes' top windows so that the parent asks its window manager to change child process window state. How can I get that? In my case, a parent process has more than one emacs process started with the same command line and what the parent knows about its children is only their process IDs. Parent cannot identify each of its children via process name, window name, or icon name. Can I get other processes' toplevel window IDs via ICCCM? Thanks in advance. Takeshi Inoue GE CR&D inoue@crd.ge.com