On 2010-03-18 17:55-0400 Hezekiah M. Carty wrote: > On Thu, Mar 18, 2010 at 5:34 PM, Alan W. Irwin > <ir...@beluga.phys.uvic.ca> wrote: >> On 2010-03-18 16:26-0400 Hezekiah M. Carty wrote: >> >>> >>> [...] From what I have read so >>> far, having nicely window-manager independent transparent backgrounds >>> for the xcairo (and xwin and possiblt qtwidget) devices would require >>> pulling in more X dependencies and would only work with window >>> managers which support such niceties. >> >> I read some stuff like that as well on the web, but I think it must be quite >> dated information. To show this, note that the ImageMagick "display" >> application is a GUI that ultimately interacts with the X server on Linux. >> >> Now that -dev pngcairo is working properly, you can test whether your X >> server renders transparent backgrounds by running >> >> examples/c/x02c -dev pngcairo -bg 0000ff_0.3 -fam -o test.png >> >> followed by >> >> display -immutable test.png.2 >> >> In my case I have access to two different X servers for two very different >> boxes. I use the Debian Lenny X server/kernel 2.6.26 for my newish Intel >> box with g33 chipset/gma 3100 and the Debian Testing X server/kernel 2.6.32 >> with my old shuttle box (the X-terminal) with embedded SiS hardware with >> reverse-engineered 2D X driver. In both cases, I get transparent results >> with "display -immutable". David had similar success with display >> -immutable, although in his case display might be interacting with something >> different than X (glitz?), but at minimum his result showed that transparent >> backgrounds can be properly rendered on Mac OS X. >> >> [out of order] >> Should I back-out the xcairo device change [to insert an obscuring layer >> between pages]? >> >> Yes, please. Of course, you first have to figure out a way to not stack >> xcairo pages on top of previous pages. I was thinking along the lines that >> when a page was started the widget/GUI associated with the previous page >> should be properly terminated and a whole new widget/GUI initialized for the >> new page. But maybe you would not have to go to that extreme... >> > > I think we may be talking about two different kinds of transparency > here, or I am using a differently configured version of imagemagick > (6.5.1.0-1.1ubuntu3). Do you mean transparent backgrounds as in (a)"I > can watch a movie in the window under my translucent plot!" or (b)"I > see a checkerboard pattern through my plot, but not the windows > underneath it"?
For my two X servers display -immutable test.png.2 gives me (a), i.e., a semi-transparent view where I can see the desktop underneath the image. If I drop the immutable option, then display gives me (b), i.e., a checkerboard background. Do you get (a) or (b) for "display --immutable test.png.2" with your X server? If (b), what X server is that? > In the case of (a), which some applications support > (for example, recent versions of the Gnome terminal support this), the > xcairo device would have to pull in some extra outside support from X > libraries. If that is correct, then all we have to do is follow how display (or more likely its plug-in for displaying PNG's) and Gnome terminal are linked. This may not actually be an issue since our build system uses the CMake "find_package(X11)" command to find the X libraries, and this issue may have already been addressed by CMake. > For (b), no special X support is required, we would just > have to change the xcairo device to draw some sort of checkboard > pattern at the start of each plot page, like Gnome's eog or > imagemagick's display does when displaying an image with a transparent > background. I guess that answers my question above about what display -immutable does for your X server. Here (for two different X servers), eog always produces a checkerboard pattern, but display only does that without the -immutable option (or if the example is too large). For a png that fits on the page, "display -immutable" produces (a) here. Ideally, I think we want to implement both (a) and (b) results under control of the PLplot user. So I think the development steps should be in the following order. (1) Remove the obscuring layer and unstack the pages so the previous pages don't interfere with the current page's transparent background results. This change just makes sense regardless of the next steps. (2) See if (a) can be made to work. I notice in cairo.c there are still references to RGB24 rather than ARGB32 so that may be a trivial fix. On the other hand if one of us does the remaining ARGB32 conversions we might end up with a checkerboard by default (depending on how X is initialized) if that checkerboard is being supplied by X (see next comment). I can try the ARGB32 conversion myself here with my two different X servers once (1) is completed by somebody more knowledgeable about cairo.c than I am. (3) Implement (b) (probably as the default with (a) optional) if necessary. However, since the checkerboard seems to be the same for both convert (without -immutable) and eog, I wonder if that checkerboard is actually supplied by X depending on how it is initialized? But we are unlikely to know that until we do step (2) which is why I put that step higher on this list. Actually, I hope that X does supply the checkerboard (if initialized appropriately) because otherwise there would be some effort required to create a checkerboard that is identical to the one rendered by display and eog. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
