gfreeman@csadfa.cs.adfa.oz.au (Graham Freeman) (04/04/91)
We are building a graphics application using X windows, and do not
know what is the best way to handle window exposures in the server.
The window we are drawing in can take several minutes to draw, and
is typically 1000 by 1000 (8-bit) pixels. We want the program to
run on a variety of X terminals/workstations. (We are currently
building the application on a DecStation 5000/200 running DecWindows,
with the server on a SUN or another DECstation; we hope to migrate
to OSF/MOTIF in the near future.)
We would like to create an off-screen pixmap in the server, so that
window expose events could be handled immediately using XCopyPlane,
say, rather than having to redraw the whole window from scratch.
However, resources on the server are often limited, and requesting
memory for the off-screen pixmap cannot be guaranteed to succeed.
Worse than that, attempts to obtain sufficient memory for the pixmap
when it is not available cause the client process to abort.
The alternative is to hold the off-screen pixmap in the client, and
to use XGetImage to retrieve from the server the drawn screen pixmap.
Window exposures would be handled by XPutImage to send the pixmap
over the network to the server for immediate display.
When we have tried this approach, we have seen longer refresh times
because of network traffic and the volume of information being sent,
but otherwise acceptable performance, except for one major obstacle.
If the drawing window is partly obscured by other windows when drawn
(typically because the worker wants to do something productive in
another window while the application is still drawing), the pixmap
retrieved by XGetImage is incomplete, containing the obscuring
window along with the remainder of the desired contents.
What we seem to need, given that we cannot be guaranteed sufficient
memory in the server or even the ability to find out by request if
the server might have sufficient resources, is the ability to
construct the drawn pixmap within the client alone. Is this possible?
How have other people handled this problem? Surely others have
tackled applications where redraw time prohibits the simple-minded
approach of a complete redraw on each expose event, which seems to
be all that X provides for. Is there some way of "manually" building
an XImage structure containing our image on the client side?
Graham Freeman
David Rubie
Computer Science Department
Australian Defence Force Academygjc@mitech.com (04/04/91)
In article <1991Apr4.053315.25887@sserve.cc.adfa.oz.au>, gfreeman@csadfa.cs.adfa.oz.au (Graham Freeman) writes: > We are building a graphics application using X windows, and do not > know what is the best way to handle window exposures in the server. > You described how you can keep a lowlevel BITMAP oriented representation of your drawing. Is that really the only level you have available without a tremendous amount of recomputation? How many draw-lines, and draw-string operations do you do, as compared with BIT oriented things? X-LIB X-Server Application => Draw-Line => ........ ^ => Draw-String => ........ | ================> Bitlevel | | | | \----------------------------/ So currently your idea of Redisplay is entirely at the bit level. And one idea for redisplay you have is to suck the bitlevel back from the server into your application. And of course that doesn't work always. You have two choices. (1) Get rid of the use of XLIB for non-bitlevel operations. Have your own Draw-Line and Draw-String. I know of applications that do this, and it can be very effective. For example, a complex graphical ICON which has a representation in terms of lines, and is generally dynamically SCALED is more efficiently converted into a bitmap ONCE (for each scale level) and then draw using the bitmap representation. Obviously you need to know how to code a good DRAW-LINE, DRAW-CIRCLE, and handle fonts and such. This is well known technology. (You can snarf it from the MIT X-Server). (2) Keep a DISPLAY-LIST data structure by inserting a level of code inside your application, between it and how you currently use the XLIB level. D-LIST X-LIB X-Server Application |******| => Draw-Line => ........ |******| => Draw-String => ........ |******| ================> Bitlevel A smart display list will keep track of, at least, a RECTANGLE that bounds each graphics object. This is helpful in optimizing redisplay on expose events. The two tricky areas are: (1) modeling the behavior of overlapping X-LIB operations. (2) dealing with ERASE concepts. (In a sense, garbage collecting the display list in space and time). This is the most important special case of #1. A typical display list environment might keep a 2-dimensional floating-point coordinate system with scrolling and zooming. Along these lines DIGITAL has something in field test called GObE, part of the Digital Graphical Interface Tools which is in field test. Efficiency and extra layers of complexity is a big issue in these things. The old VAX window system, VWS/UIS had this display list capability, but at least with techniques used and the horsepower available in the UVAX-II, it was not really a win. Generally the idea of a turning a common set of line-circle-string oriented operations into a cached bitmap at a certain scaling is missing from these general purpose display-list environments. (Unless there is some kind of "macro" capability. And in the case fo DGIT/GOBE, you can choose to make something a Widget at a certain point). -gjc
ch@siet02.sietec.de (Chitty) (04/04/91)
We are building a graphics application using X windows, and do not
know what is the best way to handle window exposures in the server.
The window we are drawing in can take several minutes to draw, and
is typically 1000 by 1000 (8-bit) pixels. We want the program to
run on a variety of X terminals/workstations. (We are currently
building the application on a DecStation 5000/200 running DecWindows,
with the server on a SUN or another DECstation; we hope to migrate
to OSF/MOTIF in the near future.)
We would like to create an off-screen pixmap in the server, so that
window expose events could be handled immediately using XCopyPlane,
say, rather than having to redraw the whole window from scratch.
However, resources on the server are often limited, and requesting
memory for the off-screen pixmap cannot be guaranteed to succeed.
Worse than that, attempts to obtain sufficient memory for the pixmap
when it is not available cause the client process to abort.
The alternative is to hold the off-screen pixmap in the client, and
to use XGetImage to retrieve from the server the drawn screen pixmap.
Window exposures would be handled by XPutImage to send the pixmap
over the network to the server for immediate display.
When we have tried this approach, we have seen longer refresh times
because of network traffic and the volume of information being sent,
but otherwise acceptable performance, except for one major obstacle.
If the drawing window is partly obscured by other windows when drawn
(typically because the worker wants to do something productive in
another window while the application is still drawing), the pixmap
retrieved by XGetImage is incomplete, containing the obscuring
window along with the remainder of the desired contents.
What we seem to need, given that we cannot be guaranteed sufficient
memory in the server or even the ability to find out by request if
the server might have sufficient resources, is the ability to
construct the drawn pixmap within the client alone. Is this possible?
How have other people handled this problem? Surely others have
tackled applications where redraw time prohibits the simple-minded
approach of a complete redraw on each expose event, which seems to
be all that X provides for. Is there some way of "manually" building
an XImage structure containing our image on the client side?
Graham Freeman
David Rubie
Computer Science Department
Australian Defence Force Academy
Attempt
=======
Yes its possible to set an XImage structure directly and not
necessarily thro XCreateImage. But I have noticed that when the
the XImage is created in this manner then XGetImage call fails.
This is because it requires pointers to the hook up functions ( I guess so,
as I do not have the source code )
I think its pointless having an off screen pixmap as this will take
up too much of your resources. The fastest way I can think of
is to find out in your expose event, the co-ordinates where the
expose regions lie and then make a union of the region. Now set a clipmask
on this region and draw on this window with a XPutImage.
Inshort draw directly w/o an additional pixmap.
An Algo will possibly go as
/* while expose event generated */
/* make a union of the region */
/* set a clipmask to this new region */
/* Draw with XPutImage */
/* Reset the clipmask */
===================================================================
Name : Chittaranjan Keswani Sietec, West Berlin
Address : ch@siet02.sietec.de (Internet)
..!sietec1!siet02!ch@unido.uucp (UUCP)
===================================================================phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (04/10/91)
gfreeman@csadfa.cs.adfa.oz.au (Graham Freeman) writes: >We would like to create an off-screen pixmap in the server, so that >window expose events could be handled immediately using XCopyPlane, >say, rather than having to redraw the whole window from scratch. >However, resources on the server are often limited, and requesting >memory for the off-screen pixmap cannot be guaranteed to succeed. >Worse than that, attempts to obtain sufficient memory for the pixmap >when it is not available cause the client process to abort. Yes, that is utterly annoying. There needs to be a way to simply find out if the resources are available. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks / \***************************************************************************/
klee@wsl.dec.com (Ken Lee) (04/10/91)
|> Worse than that, attempts to obtain sufficient memory for the pixmap |> when it is not available cause the client process to abort. This is a non-fatal error condition, so your program does not have to abort. You should install an error handler to trap this error condition and use an alternative strategy. -- Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee