Hi, Alan, On Mar 15, 2010, at 17:49 , Alan W. Irwin wrote:
> On 2010-03-15 15:49-0700 David MacMahon wrote: > >> Using a very recent ImageMagick (6.6.0), "display" gives me the >> checkerboard background without the "-immutable" option and a >> black background with that option when looking at an image with a >> transparent background. This might be an X server limitation or >> window manager limitation, but it shows that this feature is not >> universally available. > > Please be explicit about exactly what you did because our devices > other than > the three different svg ones are producing bad transparent background > results that depend very much on details. Thanks for pressing me on this one. It looks like I found a quirk with the display program. I was using an image I had created with GIMP that I knew had a transparent background. This image happens to be rather large (in pixels). It seems that the window created by "display -immutable foo.png" will have a non-opaque background if foo.png is non-opaque and the window's size fits in the root X window (i.e. needs no panner). Because my test file was large in pixels, it showed up in the display window with a black background and a little panner window for navigating around. When I followed the steps you gave to create test_transparent.png, then "display -immutable" did indeed show it using a transparent window background (neat, except that I see my very cluttered desktop underneath! :-)). If I run "display -immutable -resize 1440x900! test_transparent.png" it still comes up with transparency (my root window is 1440x900 as shown by "xwininfo -root"). If I change either (or both) resize dimension to exceed the root window size, then I'm back to the solid black background. > Therefore, I assume this is not an ImageMagick issue. See what happens when you assume! :-) >> I agree that this *can be* a really cool-looking effect, but IMHO >> it can also be a really annoying/confusing looking effect >> (depending on what's underneath/behind). I think it would be nice >> to provide the user the ability to choose how transparent >> backgrounds are rendered (i.e. either "see-through" to windows >> underneath/behind or use a predefined opaque background, e.g. >> checkerboard). > > This would not be a good idea for file devices. There, you want > the user > running the file viewing application (say with something like the > "display > -immutable" option) to control how transparent backgrounds are > rendered. Yes, obviously(?) for file devices we want real transparency. > In the separate case of interactive devices we should probably just > follow > what is done by the underlying external stack of libraries (such as > the > pango/cairo stack of libraries for -dev xcairo and the Qt4 stack of > libraries for -dev qtwidget). I'm no expert on the PLplot devices, but my understanding is that the xcairo device is a cairo "widget" or "surface" drawn in a "regular" X window that has its own background. If that's the case, then perhaps we would need to create the window with either a transparent or checkerboard background before drawing in it with cairo? > Of course, if that external stack of libraries > does offer the option of rendering transparent backgrounds as > checkerboard > (which I believe from my reading is a de facto standard started by > Adobe > photoshop) or as actually transparent for interactive devices, then > it makes > sense to give PLplot users interactive control over that choice via > a driver > option. IMHO, the choice of transparent or non-transparent window backgrounds transcends the particular interactive device chosen. PLplot already has generic "-nopixmap" and "-db" options for X-based drivers. A similar PLplot option (i.e not a driver option) to choose between opaque and non-opaque *window* backgrounds seems appropriate (again, IMHO). Given that transparent window backgrounds are more resource intensive (does it even work without an "accelerated" graphics driver?), I think the default should be an opaque (of some sort) window background even when the plot background is non-opaque. > Anyhow, our current list of devices that treat transparent background > properly is limited to just svg, svgcairo, and svgqt as far as I > can tell. I > hope we can soon expand that list both to the xcairo and qtwidget > interactive devices as well as many other file devices. I certainly agree that it would be good to expand the list of devices that treat transparent background properly. For file outputs, there seems to be little ambiguity, but defining "proper treatment" for interactive devices seems not so clear (pun partially intended! :-)). Dave ------------------------------------------------------------------------------ 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
