Conference bulova::decw_jan-89_to_nov-90

On a color workstation I think you're limited to 1024x768.

That should be, "on a GPX" regardless of whether it is monochrome or
black and white.  A Color FireFox will have different limitations.

You should also have gotten an alloc error of some sort with the create
pixmap.  If you did not, that sounds like QAR time.

Burns

    Hi again,
    	How could you know the limitations of the display memory for
    each workstation ?
    	What are the values for the VS3100?
    	If there're hardware limitations, I can't understand why it
    could be a bug (to submit an QAR..)
    	Are these limitations documented somewhere in XLIB ?
    
    		Thanks for the helps,
    			Dung HOANG

You can't know the limitations of the server and the app needs to be prepared
to handle createpixmap failures. PC's and X terminals are very likely to
generate these errors.
						Bill

My point about the QAR is that if the CreatePixmap does not return an "Alloc"
error, but nonetheless fails, that is a bug.  The fact that it failed for
too big a pixmap is not a bug.

Of course, not infrequently, people set up error handlers to throw away
X errors.  This is not a bug in the server, but in the application!

Burns

Why should it be acceptable to fail for too big a pixmap if there is 
enough memory?  It seems reasonable to allow the user to create any
size pixmap so that pieces of it could be selectively displayed and 
let the display side deal with display hardware limitations.

You wanna write the code? :-)

Seriously, the big reason we have limited it on the GPX and FF hardware is
that the hardware can't draw into virtual memory.  In order to draw into the
pixmap, you have to load it into offscreen memory.  If you pixmap is bigger
than offscreen memory, then for every operation you have to load section
1 into memory and draw, load section 2 into memory and draw, ...  Flinging
bits between offscreen and virtual memory is terribly slow.  You don't want
to do this.

Another alternative is to draw with software.  This is quite good with
1-bit-deep systems, but with 4 and 8 and 24-bit deep systems, it becomes
roughly 4, 8 or 24 times as slow.

Burns

Makes sense, but could you elaborate on what limits offscreen memory?  

My understanding is that a gpx has 2048x2048 with 1024x768 mapped to 
the screen.  With no other pixmaps allocated shouldn't you be able to
create a full depth pixmap that is (2048-1024)x(2048-768) or
1024x1280?  It seems to be limited to 1024x768, though. 

Does it do any memory management to consolidate deleted pixmaps, move 
things around to try to make room, or anything like that?

Bruce

re: -1
>Makes sense, but could you elaborate on what limits offscreen memory?  

>My understanding is that a gpx has 2048x2048 with 1024x768 mapped to 
>the screen.  With no other pixmaps allocated shouldn't you be able to
>create a full depth pixmap that is (2048-1024)x(2048-768) or
>1024x1280?  It seems to be limited to 1024x768, though. 

>Does it do any memory management to consolidate deleted pixmaps, move 
>things around to try to make room, or anything like that?


The gpx offscreen is 1024x2048. The first 1024x864 is the visible screen.
That leaves 1024x1184 free. We use some of that area as a glyph cache for
text. We cache individual glyphs from multiple fonts and the glyphs must be
in gpx memory to be used in drawing. We also use 1024x32 for a cache of
small pixmaps up to 32x32 both of depth 1 and depth 8. depth 1 pixmaps are
stacked in z. We also need an area of offscreen to save the visible screen
when the operator window come up and we need some scratch space to accomdate
operations that take multiple large pixmaps. Like copying one large pixmap
to another. after all that we are left with about 1024x864 for large pixmaps.
Yes we do consolidate deleted pixmaps when we have to.

							Bill

    Re .9 by STAR::BMATTHEWS:

>               We also need an area of offscreen to save the visible screen
> when the operator window come up and ...

    Bill,
    
    Speaking of the operator window, with EFT1 I have seen several times my
    screen corrupted when hittin CTRL-F2 to exit the operator's window.
    Logging out was the only way to fix the problem. I haven't QARed it
    b'cause I wanted to test the behaviour some more.

    Denis.

    Before reading this note, I was trying to determine how much off
    screen memory was available by looping in a program creating pixmaps
    till it blew up.
    
    The following program loops creating a 100 x 100 pixmap, calling
    XFlush, and printing out the accumulated size of offscreen memory.
    I would expect to get some warnings back from the server once I'm
    out of offscreen memory, but I never see any and I haven't established
    by own condition handler.  What I do see is the program aborting
    when the server aborts the connection for this program.  Version
    of VMS is 5.2-42W
    
    How come?
    Mark
/*
    see how much memory I can get by creating pixmaps before I get an error
*/

#include <stdio.h>
#include <decw$include/Xlib.h>

#define screenNumber    DefaultScreen(display)
#define rootWindow      RootWindow(display,screenNumber)
#define depth           DefaultDepth(display,screenNumber)
#define forever         while(1)

main(argc,argv)
   unsigned int argc;
   char *argv[];
{
    Display *display;       /* display pointer */
    Pixmap mypixmap;
    int	total_size = 0;

   if (!(display = XOpenDisplay(NULL))) 
   {
      fprintf(stderr,"Can't open display\n");
      exit(0);
   }

   forever
   {
	mypixmap = XCreatePixmap ( display, rootWindow, 100, 100, depth );
	XFlush ( display );
	total_size += 10000;
	printf ( "pixmap id = %d, total size = %d\n", mypixmap, total_size );
   }
}