On Thu, Mar 18, 2010 at 7:31 PM, Alan W. Irwin
<irwin@...> wrote:
> On 2010-03-18 17:55-0400 Hezekiah M. Carty wrote:
>
>> On Thu, Mar 18, 2010 at 5:34 PM, Alan W. Irwin
>> <irwin@...> 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?
>
Using Ubuntu 9.10, Xorg 7.4 on an Intel 965GM with Gnome with the
Compiz composited window manager (3D acceleration, transparent
windows, etc) I get (b) for both uses of display. Using the Gnome
terminal's transparency, I get "true" transparency with other windows,
etc. showing up underneath.
> 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.
>
On my desktop both eog and display show the same checkerboard pattern.
This pattern, I am almost completely certain, is provided by the
application and not something intrinsic to X.
> 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.
>
The obscuring layer is required to keep the previous plot pages from
showing through to the new plot pages. The other option is to
repeatedly open new windows for each page, but I think that it would
be better to allow the user to create multiple windows by just
creating multiple plot streams. New pages within a plot stream would
continue to show up in the same window.
> (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.
>
This is where extra X work is required. I think we need to dig in to
the composite extension to create a plot surface with true
transparency, at least for the xcairo device. At least part of this
has to happen in Xlib, outside of Cairo. I tried changing all of the
RGB24 surfaces to ARGB32 surfaces, but it unfortunately did not enable
transparency in the window.
> (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.
>
The checkerboard background seems to be a semi-standard approach for
viewing transparent images (Gimp uses something similar). I'm not
sure it is a good idea for our interactive devices though, as it makes
it very difficult to see the details of a plot. I would prefer to
keep the white background as the standard for non-transparent windows
as it maintains better readability.
Hez
|