Conference bulova::decw_jan-89_to_nov-90

Your solution is right and save-under won't help the programming 
because you can't depend on it.  If it works then fine, it was fast.  
If not you'll get the slowness you indicate unless you use the pixmap 
approach.  When it does work you've just done an extra pixmap for 
insurance against when it doesn't work!

More:

Unfortunately, this kind of application is really between the rock and the hard
place.  Using a pixmap for backing store eats up gobs of resources on the
server.  However, it is the only practical way to get reasonable performance
with images on a server which does not do backing store.  Note also that the
server can give an alloc error when you try to get a pixmap, meaning that it
has run out of pixmap storage.  And if you do a pixmap on a server that DOES
do backing store, you probably are allocating a lot of resources that you don't
have to.

In general there are 3 levels of hierarchy in storage:

1.  Backing store/save under (automatic if supported by server)
2.  Pixmap
3.  Client

One thing they might want to consider is the ability to do both of the last 2.
If the server claims to support backing store, they might choose to do their
backups on the client side.  When/if the server decides to throw out the backing
store and force them to redraw, it will be slow, but it should not happen that
often.

If the server claims NOT to support backing store, then allocate a pixmap to do
it.

I would like to discourage application writers from tailoring their code to
known behavior of a particular server.  For example, say the customer is doing
a turnkey system that is always using VMS workstations, and they decide that
since the VMS server does not do backing store, they will always do a pixmap
approach.  Then what if VMS comes out with backing store in a future version?
Bang...wasted resources.  The big pixmap could conceivably even make the server
more likely to throw away backing store (since it has fewer resources to spend
on it).

Similarly, suppose they have an Ultrix turnkey system and so decide not to make
it possible to have pixmap backing store.  Then they decide to offer it on a
FireFox (I know, it is being retired...this is just an example).  Boom...no
backing store.

The point is to try to be flexible and choose the best solution based on the
characteristics you see at run time.

Burns

    
    One other alternative is to write a server extension.  The extension
    could be general (i.e. guaranteed backing store) or more specific like
    a image extension that caches the image on the server and repaints from
    the cache.
    
    

    
    >One other alternative is to write a server extension.
    
    IMHO
    
    Fred,  I hope the 'server extension' doesn't get out of hand.
    Should we just throw any problem to an "extension"?
    I would like to see what the server looks like a few years
    down the road.
    
    Shouldn't we be looking at a 'separate server' concept for some
    of these requirements...instead of just lumping everthing together
    in one place?
    
    Kris.... 

    
    I didn't invent the response.  In fact, to 95% of all my requests
    (or complaints depending on your point of view) the answer has always
    been that an extension could be written.
    
    Do I agree that rampant extensionism can get out of hand?  Yes.
    But again it has been encouraged as the end-all solution.
    
    Does an extension seem to be a good answer to this specific problem?
    Yes.  The only place where backing store can be done efficiently is
    at the server.  If the extension was some type of image cache -- again
    the server is a good place since the bandwidth of transfering the
    image (and sometimes aligning the scanlines and inverting bit order)
    over the wire is a large part of the cost of a X11 image.
    
    Also, the application can be written to function in a slower mode
    when the extension does not exist -- so portability is not lost.
    
    
    

I'd be more partial to an extension which reported info about backing store
rather than mucked its behavior.  For example, if it answered the question
"Is this window currently being backed up?," or stuff like that.

Burns

    Here's a simple sweet extension:
    
    If this extension is *present* then the following attributes are TRUE.
    
    	1) The server is capable of backing store
    	2) When the hint for backing store is ALWAYS, window creation
    	   will cause backing store to be created.  If backing store
    	   cannot be created, window creation will fail.
    	3) Once a window is created with backing store, backing store
    	   will *never* be withdrawn for any reason.
    
    What this does is to allow guaranteed backing store.  By simply testing
    for this extension an application can decide how to manage it's
    window damage control.
    
    Note that the amount of work required to do this is minimal.  The
    extension logic is nothing.  The requirements have to do with how the
    server handles the allocation of backing store.  "Most" servers
    probably already work this way with the exception of (2).  The
    addition of the logic to cause (2) to happen should be almost nothing.
    
    _Fred
    

I wholeheartedly agree with .7 except I think it really should be a 
part of every server.  Since we beat this to a bloddy pulp in the X 
conference without convincing J Gettys of its importance, could 
someone put it out on the usenet and see if we can get some 
support from the X community at large?

X really lacks the architecture to properly handle image applications 
and I think it should be "fixed" more than "extended."

Bruce