Huidae Cho wrote:
> > > I've added transparency feature to display drivers (XDRIVER and PNG) and d.rast
> > > and d.vect now have transparency= (%) option. You can find a screenshot
> > > attached in which two rasters and one vector are overlaid.
> >
> > It is great!
>
> It might look that way from the users' perspective.
>
> From the perspective of someone who is in the middle of trying to fix
> the display area (i.e. me), it's a disaster.
Could you be more specific about that if it was really
ill-considered? 
There are three issues here:
1. I've just started a major clean-up of the display architecture, and
this is entirely the wrong time to be adding significant new
functionality.
2. The ultimate goal of the clean-up will include elimination of
monitors altogether. XDRIVER will only survive for so long as there
remain tasks which can't be performed without it. That's likely to
take a while, but not forever.
3. Even if that functionality was to be added, I can probably think of
around a half-dozen better ways of implementing it. Getting around the
limitations of X by plotting individual pixels isn't a sane solution
(I've only just got rid of the old FreeType rendering code, which did
something similar).
Are we going to have translucency after your work in XDRIVER
monitors not only in tcl/tk gui?
XDRIVER is currently being cleaned up in preparation for being killed
off altogether. The future of the display architecture is for
libraster (and thus d.* programs) to generate graphic files for use by
the GUI.
The current display architecture arose from trying to port a system
designed for graphics terminals (e.g. Tektronix 4105) to X11 with the
minimum of work, and is now well past its "use-by" date; actually it
was probably past its use-by date twenty years ago.
> I'll be removing those changes shortly. If you want translucency, wait
> for Michael to add it to gis.m.
Does this have something to do with g.pnmcomp to which you've added opacity=?
Yes.
Actually, I have no idea how g.pnmcomp works, so it would be great if you add
more detail explanation and examples to description.html.
g.pnmcomp isn't meant for end users. It's an internal tool for use by
a Tcl/Tk GUI.
In essence, g.pnmcomp generates a PPM image by overlaying a series of
PPM/PGM pairs (PPM = RGB image, PGM = alpha channel).
The intention is that d.* programs will emit PPM/PGM pairs (by way of
the PNG-driver code being integrated into libraster). The GUI will
manage a set of layers; each layer consists of the data necessary to
generate a PPM/PGM pair.
Whenever the layer "stack" changes (by adding, removing, hiding,
showing or re-ordering layers), the GUI will render any layers for
which it doesn't already have the PPM/PGM pair, then re-run g.pnmcomp
to generate the final image (just redoing the composition is a lot
faster than redrawing everything).
A C/C++ GUI would either have g.pnmcomp's functionality (image
composition) built-in, or would use the system's graphics API to
perform composition (for translucent layers, you would need OpenGL or
the Render extension, or something else which supports translucent
rendering).
Tk doesn't support transparent (masked) true-colour images (it does
support transparent GIFs, but that's limited to 256 colours), and an
image composition routine in Tcl would be unacceptably slow, hence
the existence of g.pnmcomp.
--
Glynn Clements <glynn@gclements.plus.com>