epstein@trwacs.UUCP (Jeremy Epstein) (03/06/90)
We're looking at building a server with massive amounts of backing store to prevent expose events. We know this can cause performance problems; we're doing it for other reasons. We also know that it will require massive amounts of memory; we can live with that. The concept we're thinking of is to have a virtual window associated with each window on the screen. Whenever you draw into a window, the server would also draw into the virtual window (which would be kept in memory, on disk, or whatever). Then an exposure is simply a matter of the server redisplaying the correct parts of the virtual window. Essentially, to an application it would look as if all windows are always completely mapped. We're looking for a way to do this intelligently, or a better suggestion. The key idea is that no exposure events are allowed. We've come up with three methods to store the contents of the backing store, none of which are particularly acceptable: (1) Store a bit image of the window as the virtual window. Advantage: should be relatively fast to redisplay, since everything has been computed. Disadvantages: very slow to compute what the bits, since you can't take advantage of the graphics hardware (e.g., if the window is obscured); must reimplement all graphics algorithms in software, even if the server has hardwware; hard to match the algorithms exactly (since the software simulation would need to match the hardware exactly). (2) Store the sequence of X protocol requests associated with the window and replay it as needed. Advantage: Minimal work required to store and replay the requests. Disadvantage: Unless you understand exactly what every request does and what it affects on the screen, you may have to replay all events since the beginning of time, which would clearly be slow! (3) Store the sequence of low level primitives (i.e., ddx requests) associated with the window and replay as needed. Advantage: Not too much work; faster than (2) since you've already done the work of calculating how to do it. Disadvantage: Same as #2. Has anyone else attempted anything similar? How have vendors implemented backing store? Is this the reason that the responsibility for redisplay was put into clients in the first place? Thanks for any help! -- Jeremy Epstein epstein@trwacs.uu.net TRW Systems Division 703-876-4202
rick@hanauma.stanford.edu (Richard Ottolini) (03/06/90)
In article <188@trwacs.UUCP> epstein@trwacs.UUCP (Jeremy Epstein) writes: >(2) Store the sequence of X protocol requests associated with the > window and replay it as needed. > Advantage: Minimal work required to store and replay the requests. > Disadvantage: Unless you understand exactly what every request does > and what it affects on the screen, you may have to replay > all events since the beginning of time, which would clearly > be slow! Represent images at a higher level of abstraction than bitmaps or drawing commands, preferably in terms of what things you are drawing. Then you only need to redraw the currently active set of objects. MacDraw is an early and widespread example of this philosophy. The Unidraw toolkit in X Windows InterViews is good starting point.