On Tue, 2010-05-18 at 20:30 -0700, Randy Turner wrote: > Hi All, > > I am developing an application that processes the output of the X > Windows Dump (xwd) application. I'm assembling use-case scenarios for > testing this app and was wondering about how xwd actually works.
In brief: It gets the image contents of windows. There's a bit of semantic subtlety behind that short sentence though. > When I use xwd to dump the contents of a window, and use the -nobrdrs > option, it still includes the window frame and scroll bars from the > window. For instance, if I dump the contents of a Mozilla Firefox > window, and use the -nobdrs option, I still get all the window > decoration (scroll bars, etc.). All I want from this xwd execution is > the contents of the web page. Borders, in this sense, are an X11 misfeature. Applications can set a non-zero border width in the protocol; if they do so, the X server automatically draws a border around the window, filled with whatever the border fill style is (a solid pixel, or a tile pixmap). This turns out to not be especially useful, so the vast majority of applications simply don't use protocol borders. If you ask xwd to not include (protocol) borders, it will get the image contents of the window region excluding the border region. But since firefox (like any other sane app) has a 0 border region, you won't see any difference. > Also, if the content of the web page exceeds the viewable size of the > browser window, I would like xwd to include the ENTIRE contents of the > web page, and not just the viewable section. Is this content > available in the x windows display buffer? Or is the remainder of the > web page (non viewable) under control of the Firefox and firefox > displays the next page of content when I scroll the window? xwd only gets window contents. X has several notions of drawable surfaces (drawables, for short). Windows are drawables that can potentially be seen on screen, potentially have events delivered on them, and potentially be occluded by other drawables and thus have their contents lost asynchronously. Pixmaps do not have events, do not literally exist on screen (unless bound to a window by the implementation, but pretend you don't know that), and have their contents preserved. Since X includes no intrinsic notion of how to update screen contents synchronously with the redraw hardware, drawing directly to a Window tends to look awful, because you see the drawing as it happens and that races with the screen retrace. To avoid this, apps draw to Pixmaps and then copy from Pixmap to Window, to minimize the number of flickery draws they do. X doesn't remember any history of how bits got into a Window from a Pixmap, so even if the app logically drew a much larger scene in the Pixmap than is displayed in the Window, there's no straightforward way to go from one to the other from xwd's perspective; the originating Pixmap might have even been destroyed. So the Window content is all there is. - ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel