DAVISM@kcgl1.eng.ohio-state.edu (Michael T. Davis) (11/27/90)
Is it possible to emulate the functionality of a pixmap with an un-
mapped window? If so, could someone point me in the direction of some sample
code? I ask this since I am forced to use the DECwindows server running on a
DEC VS3100 with GPX chip set which is apparently limited to pixmaps no higher/
wider than the screen; windows created under this configuration do not seem to
have this limitation.
Thanks,
Mike
davism@kcgl1.eng.ohio-state.edu | These Thoughts, They Be Mine
davis-m@eng.ohio-state.edu |dce@smsc.sony.com (David Elliott) (11/27/90)
In article <6233@quanta.eng.ohio-state.edu> DAVISM@kcgl1.eng.ohio-state.edu (Michael T. Davis) writes: > Is it possible to emulate the functionality of a pixmap with an un- >mapped window? As I believe that one answer here involves using an XImage, I have a related question. An XImage is not a drawable, but it sure would be nice to be able to use Xlib-like drawing routines on an XImage. For example, it would be nice to be able to draw lines, arcs, polygons, filled polygons, and so forth, and to do other operations on XImages. Does such a library exist? (Then again, maybe I missed something obvious...)
mouse@LARRY.MCRCIM.MCGILL.EDU (11/29/90)
> Is it possible to emulate the functionality of a pixmap with an > unmapped window? Yes - if you can somehow make certain the server will maintain backing-store for it. Unfortunately, X does not guarantee this (though some servers might, it is not required). > If so, could someone point me in the direction of some sample code? > I ask this since I am forced to use the DECwindows server running on > a DEC VS3100 with GPX chip set which is apparently limited to pixmaps > no higher/wider than the screen; windows created under this > configuration do not seem to have this limitation. Yeesh. I'm sure that's perfectly legal, but it still seems broken to me. (Sort of like providing only three different cursor shapes, with no capability for any other: legal but definitely not good.) I'd just call it a broken server, submit a bug report to the vendor, and write it off as a useful X machine until/unless a fix is forthcoming. (Assuming that there isn't some reasonable excuse, like a tiny memory limit, responsible for the failure. For example, if I can create a large number of pixmaps as big as the screen, but not even one that's only slightly bigger, I'd call it broken.) What error do you get when you try to create a big pixmap? (If it's anything but BadAlloc, I think it probably is a protocol violation. The only errors that are listed for the CreatePixmap request are IDChoice (which indicates an Xlib bug or perhaps memory corruption), Drawable, Value, and Alloc.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
mikey@eukanuba.wpd.sgi.com (Mike Yang) (12/05/90)
In article <1990Nov27.155853.10911@smsc.sony.com>, dce@smsc.sony.com (David Elliott) writes: |> An XImage is not a drawable, but it sure would be nice to be able to |> use Xlib-like drawing routines on an XImage. For example, it would |> be nice to be able to draw lines, arcs, polygons, filled polygons, |> and so forth, and to do other operations on XImages. Does such a |> library exist? (Then again, maybe I missed something obvious...) What you're describing is a pixmap. XImage is for client-side data, whereas pixmaps and windows have their contents known by the server. Since XImage is for the client, it doesn't make sense to provide server operations on its contents. ----------------------------------------------------------------------- Mike Yang Silicon Graphics, Inc. mikey@sgi.com 415/335-1786
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley ) (12/05/90)
In article <1990Dec5.005912.13695@relay.wpd.sgi.com> mikey@sgi.com writes: >In article <1990Nov27.155853.10911@smsc.sony.com>, dce@smsc.sony.com (David Elliott) writes: >|> An XImage is not a drawable, but it sure would be nice to be able to >|> use Xlib-like drawing routines on an XImage. For example, it would >|> be nice to be able to draw lines, arcs, polygons, filled polygons, >|> and so forth, and to do other operations on XImages. Does such a >|> library exist? (Then again, maybe I missed something obvious...) > >What you're describing is a pixmap. XImage is for client-side data, >whereas pixmaps and windows have their contents known by the server. >Since XImage is for the client, it doesn't make sense to provide >server operations on its contents. That doesn't discount the need or desire to perform these kinds of operations on client-side images. Why must everyone re-invent the wheel for these drawing primitives? And, since we're already programming Xlib, why not have have a compatible, equivalent library of routines that act upon an image? -- Kaleb Keithley Jet Propulsion Labs kaleb@thyme.jpl.nasa.gov Good girls get to go to heaven, but bad girls get to go everywhere!
etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (12/06/90)
In article <1990Dec5.005912.13695@relay.wpd.sgi.com>, mikey@eukanuba.wpd.sgi.com (Mike Yang) writes: |> In article <1990Nov27.155853.10911@smsc.sony.com>, dce@smsc.sony.com (David Elliott) writes: |> |> An XImage is not a drawable, but it sure would be nice to be able to |> |> use Xlib-like drawing routines on an XImage. For example, it would |> |> be nice to be able to draw lines, arcs, polygons, filled polygons, |> |> and so forth, and to do other operations on XImages. Does such a |> |> library exist? (Then again, maybe I missed something obvious...) |> |> What you're describing is a pixmap. XImage is for client-side data, |> whereas pixmaps and windows have their contents known by the server. |> Since XImage is for the client, it doesn't make sense to provide |> server operations on its contents. |> |> ----------------------------------------------------------------------- |> Mike Yang Silicon Graphics, Inc. |> mikey@sgi.com 415/335-1786 NO. Pixmaps, just don't get the job done all of the time. First of all, "Pixmaps should be considered a precious resource". Second of all, SGI's don't handle pixmaps above a certain size correctly (I last used their X about 6 months ago). Thirdly, sometimes you need immediate access to the data you just output. It would be horrible if I had to use XGetImage after every drawing operation to get at the bits. Of course it makes sense to provide the functionality for XImages. It doesn't have to be in libX11.a though (and shouldn't) . Some little utility library would be nice (HINT, HINT,HINT). -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bcm.tmc.edu (713) 798-3776
mouse@LIGHTNING.MCRCIM.MCGILL.EDU (12/06/90)
>>> An XImage is not a drawable, but it sure would be nice to be able >>> to use Xlib-like drawing routines on an XImage. >> What you're describing is a pixmap. > NO. Pixmaps, just don't get the job done all of the time. I agree with the people who want Xlib-style drawing on the client side. Anyone for a free library that's API-compatible with Sun -lpixrect? (Why -lpixrect? Because it's the only implementation of such a thing I've seen.) This is something I've been meaning to hack together, off and on. While you wouldn't use it on a Sun, of course (the Sun one is probably faster), it would be very nice to be able to use pixrect-style code on other machines.... > Of course it makes sense to provide the functionality for XImages. > Some little utility library would be nice (HINT, HINT,HINT). Yup. Any volunteers? If and when I find the time, I'll have a stab at something of the sort. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu