Conference bulova::decw_jan-89_to_nov-90

3125.0. "XCreatePixmap Anomaly" by WRKSYS::GOLDBERG (Marshall R. Goldberg, Workstations) Tue Jul 24 1990 11:30

    Folks,
    
    This is presented for your noting pleasure. Before we submit a QAR
    on this anomaly, we will try it with VMS 5.4. They have already
    figured out a workaround, so it is not critical.
    
    Marshall
    
    
    
    
From:	WSINT::DECUAC::"decvax!logicraft!phaneuf" "19-Jul-1990 1510" 19-JUL-1990 15:18:29.68
To:	decwrl!BILBO.dec.com!"decvax!decuac!wsint.enet!goldberg" 
CC:	
Subj:	Fatal DECwindows Bug From Logicraft 


	We have a DECwindows bug which needs you attention.  We can not create
more the 80,000(hex) pixmaps before the DECwindows server gets a tin ear and
stops listening to our X calls.  We free the pixmaps shortly after creating 
them since they are used by the LCSD to update the VGA display.  Without having
this problem fixed, a customer could only run an application like flight
simulator for 5 hours before it would crash.  We are not sure if this is a
DEC bug or a problem in MIT X.11/R3.  Would you please forward the code sample
below to the proper channels in DECwindows engineering.  This examples
reproduces the problem after about 3 hours on a PVAX 1.  We have tried it on
PVAX 0/GPX and PVAX 1/SPX with the same results.

							Mark
-------------------------------- cut ------------------------------------------
/*
 * This program demonstrates a bug in the XCreatPixmap routine.  There is a
 * limited number of times which you can create pixmap even though you free
 * the pixmap following the create.  What we see is that the first pixmap
 * created is assigned an i.d. of 500000h.  When you reach 580001h (you have
 * created and destroyed 80,000h pixmaps), your next request will fail.  It
 * appears like XCreatePixmap is not recycling the id's.  A create/free GC
 * or create/destroy image recycle their id's correctly.
 */

#include <stdio.h>
#include "decw$include:X.h"
#include "decw$include:Xlib.h"

/* Error handlers */

ErrorHandler(dp, err) 
Display *dp;
XErrorEvent *err;

{ char msg[80];

  XGetErrorText(dp, err->error_code, msg, 80);
  fprintf(stderr, "XWindows Error: %s\n", msg);
  exit(0);
}

main()

{ Display	*dp;
  GC		gc;
  XGCValues	gcval;
  Window	win_id;
  XEvent	event;
  Pixmap	pixmap;
  int		cnt = 0, exposed = 0, count = 0;
  char		buf[256];

  if ((dp = XOpenDisplay(0)) == NULL) {
    fprintf(stderr, "Failed to open display\n");
    exit(0);
  }

  win_id = XCreateSimpleWindow(dp, RootWindow(dp,0), 0, 0, 100, 100, 3,
			       WhitePixel(dp,0), BlackPixel(dp,0));
  XSelectInput(dp, win_id, ExposureMask);
  XSetErrorHandler(ErrorHandler);
  XMapWindow(dp, win_id);

  while(1) {
    cnt = XPending(dp);
    while(cnt-- > 0) {
      XNextEvent(dp, &event);
      if (event.type == Expose) {
        printf("Exposed - Starting Graphics\n");
	exposed = 1;
      }
    }
    if (exposed) {

#ifdef BITMAP
      if (!(pixmap = XCreateBitmapFromData(dp, win_id, buf, 16, 16))) {
#else
      if (!(pixmap = XCreatePixmap(dp, win_id, 16, 16, 8))) {
#endif

        fprintf(stderr, "Can't create bit map from data!\n");
        exit(0);
      }
      printf("%8u: Pixmap = %Xh\n", count++, pixmap);
      XFreePixmap(dp, pixmap);
    }	
  }
  XCloseDisplay(dp);
}

================== RFC 822 Headers ==================
Received: by decuac.DEC.COM (5.61/Ultrix-fma)
	id AA27300; Thu, 19 Jul 90 15:14:20 -0400
Date: Thu, 19 Jul 90 14:17:51 EDT

This is not surprising.  There is a limited number of resource IDs,
and there also may be some memory fragmentation happening.  This
has been discussed elsewhere in the notes file, and the conclusion was
that the application must be more sparing with its resources.

In this case, the application should save the pixmap and re-use it the
next time through the loop.   Only if it is too small should it be
freed and a new one created.  This means that XCreateBitmapFromData
will have to be broken out.  Note that this routine also (unnecessarily) 
creates and destroys a GC, which also consumes a resource ID.

Attached is an extract from the MIT version of XLib's XCreateBitmapFromData
routine so you can see what's happening.

I do not believe that this is QAR material, since there isn't really a bug
and anyway it is unlikely to change.  It should not be hard to make
the application a little more sparing with its resources.

-steve-

/* $XConsortium: XCrBFData.c,v 1.8 89/12/11 19:08:53 rws Exp $ */
/* Copyright    Massachusetts Institute of Technology    1987	*/

#include "Xlib.h"

/*
 * XCreateBitmapFromData: Routine to make a pixmap of depth 1 from user 
 *	                  supplied data.
 *	D is any drawable on the same screen that the pixmap will be used in.
 *	Data is a pointer to the bit data, and 
 *	width & height give the size in bits of the pixmap.
 *
 * The following format is assumed for data:
 *
 *    format=XYPixmap
 *    bit_order=LSBFirst
 *    byte_order=LSBFirst
 *    padding=8
 *    bitmap_unit=8
 *    xoffset=0
 *    no extra bytes per line
 */  

Pixmap XCreateBitmapFromData(display, d, data, width, height)
     Display *display;
     Drawable d;
     char *data;
     unsigned int width, height;
{
    XImage ximage;
    GC gc;
    Pixmap pix;

    pix = XCreatePixmap(display, d, width, height, 1);
    if (! (gc = XCreateGC(display, pix, (unsigned long) 0, (XGCValues *) 0)))
	return (Pixmap) None;
    ximage.height = height;
    ximage.width = width;
    ximage.depth = 1;
    ximage.xoffset = 0;
    ximage.format = ZPixmap;
    ximage.data = (char *)data;
    ximage.byte_order = LSBFirst;
    ximage.bitmap_unit = 8;
    ximage.bitmap_bit_order = LSBFirst;
    ximage.bitmap_pad = 8;
    ximage.bytes_per_line = (width+7)/8;

    XPutImage(display, pix, gc, &ximage, 0, 0, 0, 0, width, height);
    XFreeGC(display, gc);
    return(pix);
}