X windows dump format

[Adam Jackson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100519/3809ee31/attachment.pgp>