As a sidenote Willem Rein Oudshoorn pointed out in private mail that [compositeToPoint:fromRect:operation:fraction:] is not equivalent to either of the DPS operators DPScomposite or DPSdissolve. This method is new to MacOSX. Is it just a wrapper for a sequential call of the above operators or does it do anything new?
Fred probably means pixelwise blending by the "simple and slow implementation" (do you?). Maybe such a trivial implementation may be enough for dissolving such tiny images as icons.
Since Ghostscript interprets Level II postscript these operators should be implemented there. Would it be an option for borrowing some code from them? (Hm..., maybe the old licensing issue... :-(
Best wishes,
Stefan
PS: Somewhere deep back in my memory, I remember that compositing (and dissolving as well I guess) was something odd in that scaling, rotation and flipping status of a destination view was *not* respected by the operator. This was (again I guess) for efficiency reasons to allow a pixel by pixel transfer from image to framebuffer without having to do scaling/antialiasing and so on. If you wanted such a thing you had to scale/flip/rotate the image first and then do the compositing. Maybe this has changed in MacOSX...
Fred Kiefer wrote:
> Stefan Boehringer wrote:
> >
> > Willem Rein Oudshoorn wrote:
> > > Enrico Sersale <enrico@www.imago.ro> writes:
> [...]
> 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.