pjs@aristotle.JPL.NASA.gov (Peter Scott) (08/27/90)
I have an application which fills a drawnbutton with a pixmap read from a file picked by the user so they can preview it. (The bitmaps are from /usr/include/X11/bitmaps and I convert them to pixmaps with XReadBitmapFile). Worked fine on our monochrome displays. I just went to a color workstation that I have occasional access to, and got the error X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 55 (X_CreateGC) Minor opcode of failed request: 0 Resource id in failed request: 0x800025 Serial number of failed request: 57 Current serial number in output stream: 122 After a while of scratching my head, it dawned on me that the problem was in the drawnbutton, and was because the color w/s ihas an 8-bit deep display. I recall reading something about this here lately. Anyway, I tried setting the depth resource to 1 in the argument list in the widget creation call, but that didn't help. How can I write something which works on mono and color displays? More to the point, why can't the drawnbutton figure it out for itself??? -- This is news. This is your | Peter Scott, NASA/JPL/Caltech brain on news. Any questions? | (pjs@aristotle.jpl.nasa.gov)
argv@turnpike.Eng.Sun.COM (Dan Heller) (08/27/90)
In article <1990Aug27.005946.5857@elroy.jpl.nasa.gov> pjs@aristotle.jpl.nasa.gov writes: > (The bitmaps are from /usr/include/X11/bitmaps and I convert them > to pixmaps with XReadBitmapFile). ... > After a while of scratching my head, it dawned on me that the > problem was in the drawnbutton, and was because the color w/s > ihas an 8-bit deep display. I recall reading something about > this here lately. Anyway, I tried setting the depth resource to > 1 in the argument list in the widget creation call, but that didn't > help. How can I write something which works on mono and color > displays? More to the point, why can't the drawnbutton figure > it out for itself??? It *could* figure this out for itself, but I guess they chose to implement it that it doesn't leaving the responsibility to the programmer. the solution is to 1) read the bitmap file. 2) if DefaultDOfScreenepth() is > 1 a) create a _new_ pixmap that's the *same size* as the bitmap b) Use XCopyPlane() to copy the 1-bit deep pixmap onto the multi-depth pixmap. 3) copy appropriate pixmap as resource value. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
larry@sunrise.com (Larry Rogers) (08/27/90)
In article <1990Aug27.005946.5857@elroy.jpl.nasa.gov> pjs@aristotle.jpl.nasa.gov writes: >I have an application which fills a drawnbutton with a pixmap >read from a file picked by the user so they can preview it. >(The bitmaps are from /usr/include/X11/bitmaps and I convert them >to pixmaps with XReadBitmapFile). Worked fine on our monochrome >displays. I just went to a color workstation that I have occasional >access to, and got the error > >X Error of failed request: BadMatch (invalid parameter attributes) > Major opcode of failed request: 55 (X_CreateGC) > Minor opcode of failed request: 0 > Resource id in failed request: 0x800025 > Serial number of failed request: 57 > Current serial number in output stream: 122 > >After a while of scratching my head, it dawned on me that the >problem was in the drawnbutton, and was because the color w/s >ihas an 8-bit deep display. I recall reading something about >this here lately. Anyway, I tried setting the depth resource to >1 in the argument list in the widget creation call, but that didn't >help. How can I write something which works on mono and color >displays? More to the point, why can't the drawnbutton figure >it out for itself??? > You have to generate an image and then generate a pixmap from the image. An easier solution under Motif is to use XmGetPixmap. It automatically generates a pixmap of the correct depth for the display. It's also pretty quick becauuse it caches the pixmaps it creates. >-- >This is news. This is your | Peter Scott, NASA/JPL/Caltech >brain on news. Any questions? | (pjs@aristotle.jpl.nasa.gov) -- == Larry Rogers == Sunrise Software Systems, Inc. == <larry@sunrise.com | uunet!ezx!larry>
argv@turnpike.Eng.Sun.COM (Dan Heller) (08/27/90)
In article larry@sunrise.com (Larry Rogers) writes: > In article pjs@aristotle.jpl.nasa.gov writes: > >displays? More to the point, why can't the drawnbutton figure > >it out for itself??? > You have to generate an image and then generate a pixmap from the > image. An easier solution under Motif is to use XmGetPixmap. It > automatically generates a pixmap of the correct depth for the > display. It's also pretty quick becauuse it caches the pixmaps > it creates. In this particular person's application, he is allowing the user to select (at run time) a bitmap file. He's got to load the file somehow, and the only way to do it is into a pixmap. Then, he would have to extract an image (big operation here; performance hazard warning if this is going to be done frequently), then call XmGetPixmap from the image just to get a pixmap that's the correct depth. Furthermore, this pixmap is _cached_ which means that if he no longer needs it (it doesn't sound likely if the user is browsing), the pixmap is saved anyway. I would recommend using XmGetPixmap() under the following conditions: 1) Bitmaps used are compiled into the code (they are not read dynamically) This means that bitmaps are specified using #include or the short[]'s are precoded (probably based on the same files). 2) These pixmaps are to be used repeatedly throughout the life of the application, not just at UI initialization time. For "this" particular problem, I backup my recommendation that a second pixmap (of correct depth) is used and to use XCopyPlane() to render the bitmap into the pixmap. That is, until osf fixes this and the label widget/gadget to test for the depth themselves and use XCopyPlane() rather than XCopyArea() in the redisplay method (-very- simple fix). -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
pjs@aristotle.JPL.NASA.gov (Peter Scott) (08/28/90)
In article <141351@sun.Eng.Sun.COM>, argv@turnpike.Eng.Sun.COM (Dan Heller) writes: > In article larry@sunrise.com (Larry Rogers) writes: > > You have to generate an image and then generate a pixmap from the > > image. An easier solution under Motif is to use XmGetPixmap. It > > automatically generates a pixmap of the correct depth for the > > display. It's also pretty quick becauuse it caches the pixmaps > > it creates. > > In this particular person's application, he is allowing the user > to select (at run time) a bitmap file. He's got to load the file > somehow, and the only way to do it is into a pixmap. Then, he > would have to extract an image (big operation here; performance > hazard warning if this is going to be done frequently), then call > XmGetPixmap from the image just to get a pixmap that's the correct > depth. Furthermore, this pixmap is _cached_ which means that if > he no longer needs it (it doesn't sound likely if the user is > browsing), the pixmap is saved anyway. But it seems that Larry is right. The Programmer's Reference for XmGetPixmap states "... If an image is not found, the image_name is used as a filename, and a search is made for an X10 or X11 bitmap file. If it is found, the file is read, converted to an image, and cached in the image cache. The image is then used to generate a pixmap, which is cached and returned." I just reprogrammed it this way and it works on both the B/W and color systems. And the code is a lot shorter! Thanks, Larry. -- This is news. This is your | Peter Scott, NASA/JPL/Caltech brain on news. Any questions? | (pjs@aristotle.jpl.nasa.gov)
argv@turnpike.Eng.Sun.COM (Dan Heller) (08/28/90)
In article <1990Aug27.175009.29113@elroy.jpl.nasa.gov> pjs@aristotle.jpl.nasa.gov writes: > In article <141351@sun.Eng.Sun.COM>, argv@turnpike.Eng.Sun.COM (Dan > Heller) writes: > > In article larry@sunrise.com (Larry Rogers) writes: > > > You have to generate an image and then generate a pixmap from the > > > image. An easier solution under Motif is to use XmGetPixmap. It > > In this particular person's application, he is allowing the user > > to select (at run time) a bitmap file. He's got to load the file > > somehow, and the only way to do it is into a pixmap. > XmGetPixmap states "... If an image is not found, the image_name is > used as a filename, and a search is made for an X10 or X11 bitmap file. Yes, this is true -- but the pixmap is still cached. Having an application that browses a directory of bitmaps is going to eat up all your memory quickly if those images are never freed. > I just reprogrammed it this way and it works on both the B/W and > color systems. And the code is a lot shorter! Thanks, Larry. Don't misunderstand my intentions here. I am not discarding XmGetPixmap(). It's a great convenience function. I'm just suggesting that problems may arise if you are not careful -- caches, as we all know, can fill up real fast if used inappropriately. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
nazgul@alphalpha.com (Kee Hinckley) (08/28/90)
> Don't misunderstand my intentions here. I am not discarding XmGetPixmap(). > It's a great convenience function. I'm just suggesting that problems > may arise if you are not careful -- caches, as we all know, can fill > up real fast if used inappropriately. > > Two undoc'd calls of interest. XmInstallImage(image, name) XmUninstallImage(image)
markwk@metheny.unx.sas.com (Mark Kernodle) (08/31/90)
Does anyone know if the bugs have been shaken out of XmGetPixmap()
yet? Specifically, any directory pathnames specfied in XBMLANGPATH are not
searched because the full pathname string generated in
ImageCache.c is incorrectly truncated.wwang@osf.org ("Weidong Wang 621-7272", 617) (08/31/90)
I believe XmGetPixmap has a bug in it. Motif 1.1 does not fix it. Now if you specify your own XBMLANGPATH, neither your bitmap files under the directories specified by XBMLANGPATH, nor those under the default path (e.g. /usr/include/X11/bitmpas) can be found. This bug has been submitted for fix. Weidong Wang