harper@applga.aa.cad.slb.com (Brett E. Harper) (03/05/91)
hello,
I am working on a project that requires the maintenence of an off screen copy
of the window contents (better watch out calling it backing-store (tm)! :))
The method that I am currently using is to draw into the off-screen pixmap,
and then do XCopyArea's from the pixmap to the window for the affected area.
This can sometimes lead to poor performance if the affected area is large
compared to the actual primitive drawn (i.e. a diagonal line).
What I would like to do is to make use of the X servers ability to maintain
the backing store for me via the window attributes:
wattr.backing_store = Always;
wattr.backing_planes = 255;
wattr_flags = CWBackingStore | CWBackingPlanes;
XChangeWindowAttributes (display, window, wattr_flags, &wattr);
This works very well in my opinion, I only need to draw to the window, and
the maintenence of all damaged (exposed) regions is done by X (quickly too).
The only problem is that sometimes the server simply stops maintaining the
contents of my window (i.e. it STOPS doing backing store for me!)
When this happens the server starts sending me expose events for the
previously obscured regions (as the X manual says it will do) but I don't
want these, I want X to keep doing the backing store for me.
I am running on a HP9000s400 under HP-UX 7.03 using the Vue environment.
What I have noticed is that after time the size of the server (X) gets to
be around 1100K big, then Pixmap allocations begin failing, and it seems that
this is also around the time when the server stops doing backing store.
The sure fire way to make backing store perform correctly is to kill the X
server and begin again (which makes the size of the server go down).
What exactly is the correlation between the size of the X server and the
allocation of pixmaps and X server supported backing store working ????
Thanks,
Any help/comments/observations/accusations/etc welcome.
Brett Harper
Schlumberger CAD/CAM
harper@aaaca1.SINet.SLB.COMklee@wsl.dec.com (Ken Lee) (03/07/91)
In article <1991Mar4.171959.5134@applga.aa.cad.slb.com>, harper@applga.aa.cad.slb.com (Brett E. Harper) writes: |> The only problem is that sometimes the server simply stops maintaining the |> contents of my window (i.e. it STOPS doing backing store for me!) |> When this happens the server starts sending me expose events for the |> previously obscured regions (as the X manual says it will do) but I don't |> want these, I want X to keep doing the backing store for me. |> |> I am running on a HP9000s400 under HP-UX 7.03 using the Vue environment. |> What I have noticed is that after time the size of the server (X) gets to |> be around 1100K big, then Pixmap allocations begin failing, and it seems that |> this is also around the time when the server stops doing backing store. |> The sure fire way to make backing store perform correctly is to kill the X |> server and begin again (which makes the size of the server go down). The X protocol allows servers to stop doing backing store whenever they want. Most will stop if memory becomes limited. Sounds like you have a memory leak in you server (do you mean 1100K or 11000K?), which would cause memory problems. -- Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
harry@hpcvlx.cv.hp.com (Harry Phinney) (03/12/91)
Brett E. Harper writes: > What exactly is the correlation between the size of the X server and the > allocation of pixmaps and X server supported backing store working ???? If the server cannot malloc() the space for the backing store memory then it will refuse to honor the backing store request. The malloc() will fail when either the kernel's per-process data space limit is reached, or when the system's swap space is full. The fact that your server grows may be an indication of a memory leak in the server, but I suspect it instead reflects the nature of the clients running to it. Of course, I'm biased :-) Harry Phinney harry@hp-pcd.cv.hp.com