Re: transparent icons

[Fred Kiefer]

Stefan Boehringer wrote:
> 
> Willem Rein Oudshoorn wrote:
> > Enrico Sersale <enrico@www.imago.ro> writes:
> >
> > > To do this I need to use NSImage's [compositeToPoint: fromRect: operation:
> > > fraction:], that, in the actual implementation says:
> > > "// FIXME We need another PS command for this" `
> > >
> > > I would know if there are particular problems in writing this or, simply,
> > > this has not be written.
> [...]
> > Well, as the FIXME suggest, invent a DPScommand for it.
> > But for this you should probably ask Adam.
> [...]
> 
> Next/Openstep have the operator
> APPKIT_EXTERN void DPScomposite(DPSContext ctxt, float x, float y, float w, 
> float h, int gstateNum, float dx, float dy, int op);
> 
> However this is probably not what you want. This command seems a bit tedious 
> to implement on account of the various operators (op) which determine how 
> transperancy is handled when combining two images.
> 
> What you need to display dimmed icons is:
> APPKIT_EXTERN void DPSdissolve(DPSContext ctxt, float x, float y, float w, 
> float h, int gstateNum, float dx, float dy, float delta);
> delta indicates the portion that is taken from the image and combined with (1 
> - delta) from the destination rect.

First, Stefan is correct that for what Enrico wants the dissolve methods
(or the DPS command) should be sufficient. The problem with this is that
in the xgps back end none of this is implemented, it just falls back to
a compose call. 
Still we need those two extra DPS calls. To add two more methods on
NSGraphicsContext is a bit of work but not too hard. The real trouble
starts when implementing them in the back end. 
So what we really need is image handling code in the the xgps back end
that is able to perform all the composite operations while taking the
alpha values either from the image itself or using the given factor as
in the dissolve methods. Some time ago I made a private proposal to Adam
to implement this, but later on had to admit, that it is not as easy as
I thought. A very simple and slow implementation would take about one
day and for anything which would try to do things faster we would need
much more time. And also there is the chance that some of the
functionality would come with the next release of Xfree86.
The other side is that this is the first request for this functionality
I see on the GNUstep mailing lists. It looks like nobody is doing any
serious image processing in the GNUstep framework, so perhaps the
priority for this code is rather low.