Conference bulova::decw_jan-89_to_nov-90

    
    Are you sure that the PIXMAP was created?  There is a bug in DECterm
    where the failure of the PIXMAP create (which they claim does not
    report the failure correctly) causes he server to log errors when
    DECterm writes to the invalid PIXMAP - the DIO count goes up, BIO
    goes down and logical name translation also shoots up, and the DECterm
    gets *real* slow.
    
    *Or* is there still drawing going on to the other pixmap?  This could
    cause the continuous swapping of the PIXMAP from VAX memory to GPX
    memory.
    

Yes, I guess the pixmap was created, the backingstore using it worked.
On the other hand, yes we had continuous updating of graphics on the
other drawing on the basis of an Xtimerevent, but I took that out
and the syndrome remained the same.
Dominique.

Oops, entered reply too soon. Do you mean one application could have
created a correct pixmap and the second one an invalid one ?
And that I try to draw to an invalid pixmap with the second application
without getting any error from the program ?

Dominique

    
    Yup, that's what the DECterm problem reportedly was, they told
    me that DECwindows didn't give them a valid indication that the PIXMAP
    was not created because of insufficient resources (or perhaps it was
    just too large) and so they were trying to write to a PIXMAP that
    did not exist - and thus the server error log updating (what I found
    was the time was consumed by the extending of a file on DUA0: which
    I discovered was the servers _error.log file.
    
    

    I think that .4 is old information.  At least, the server does not log
    client errors to the server error log anymore.
    
    Also, I have seen drawing to bad pixmap's give a Drawable error.  I
    can't guarantee that running out of memory will give you a pixmap
    error, (Alloc), but you should be able to tell if the server's virtual
    page count is getting huge.
    
    My guess would be that those two huge pixmaps are "paging" in and out
    of the GPX's offscreen memory.  The offscreen memory in a GPX is just
    about the same size as the "onscreen" memory (a little bigger,
    actually, but ...).  You can't draw to a pixmap unless it is in the
    GPX, and the GPX is notoriously slow in moving data from main memory
    to the screen.  Thus we have this problem.
    
    There is not too much that can be done, except in some special cases:
    
    	1.  If your application is using only two colors, you can use only
    	    a 1-plane pixmap (a bitmap) and do a CopyPlane to move it into
    	    the window (this allows you to convert 1 and 0 into fg and bg
            colors).
    
    	2.  If your application is rather localized, you might be able to
    	    use several smaller pixmaps rather than one big one.  Then
    	    only the ones for the currently "active" area of the screen
    	    will be moved in.  Similarly, if there are large pieces of the
    	    screen which always have a simple pattern or texture in them, you
    	    might be able to represent that as a much smaller background
    	    pixmap.
    
    Burns
    
    

    BTW, you mentioned that you did not see the UIS paging behavior
    (stripes painted one after the other).  DECWindows does not work that
    way.  Nothing will be done with a pixmap until it is completely in.
    
    Burns
    

Thanks for the replies so far, but could someone with more DW expertise
extract the source code on 156 and try to run the application twice.
From the menu start "image1" for the first application, start application
two and choose the same option". From the symptoms you would see you
might be able to give us a hint on what is the problem.
If nobody has any further hints I will post an entry in the DW examples
conference too.
To us it is important, because if we use real complicated drawings,
the redraw option for backingstore might be not useful or too slow.
Any solution will be honored with one of the more then hundred Belgian
beers whenever you visit Belgium...

Dominique

Ok, so I ran it.  The only thing new I can see from running it is that if
you ^Y EXIT application one while application 2 is taking its time drawing,
suddenly application 2 speeds up.  The other thing is that the server is
spending most of its time in LEF.

This is all exactly in agreement with the theory I put forth in .5, with the
slight added info that probably the arrowheads or something else similar is being
put into a pixmap also, and I would guess that that is what is thrashing.  (I.e.
you need to throw out the big pixmap to have room for the arrowhead and
vice-versa.)

I still believe that breaking the backing store int several sections would
probably help.  For example, try initially making one pixmap for the
left half of the screen and another for the right half.

Burns (who thinks he has some DW expertise in the server area at least)  

    Thanks for your trouble. It still sounds weird to me.
    I had the first copy of an application drawn the screen with the
    valves, started the second copy and let it draw the same screen
    and it took minutes for each line or valve to get drawn.
    Apparantly you don't have these long waiting times ...
    But I'll follow your advice and break the pixmap into smaller pieces.
    Dominique
    
    

I was not clear enough, I guess.  I did have the long waiting times for
the second applications just as you described UNTIL I stopped the first one.
Then the second one suddenly speeded up.  I can imagine that depending on what
other applications were on the screen, the pixmaps in question might conceivably
be allocated in such a way that deleting the first application might not speed
up the second one, though.

Burns