Re: New bitmap code - testers required

[Pete French]

> (1) Performance,  this is a minor concern.  The code
>     can be optimized and improved.

Indeed, adding a flag so that large bitmaps get reduced by
simple point picking rather than colour averaging for starters.
The downside to that is, of course,m that the kmages which will
most benifit speed-wise from this are those that will look the
worst when reduced. Given that theres nothing in the OpenStep spec to
support this that I've seen though, then I am wndering about the best
place to hold such a flag - suggestions ? The 'Interpolate' value in
the image dictionary only appears to apply to magnification, plus
tgere is no way for the external API user to insert values into that
dictionary.

>
> (2) I am not sure the approach is right.  From a glance
>     at the source code it seems that you ALWAY scale
>     the image in _bitmap_combine_alpha
>     And I do not think that this is correct.   The scaling
>     should be determined by the different transformation

It *is* determined by the transformation matrix - thats doen before
_bitmap_combine__alpha is actually called. You can do a PSscale(0.5,1.5)
before displaying the image and it honours it. You can do a PStranslate()
and the origin willmove. In fact thats how it works with drawInRect which
simply adapts the transofrmation matrix such that a straigh "draw" method will
fill the rect given - these methods are in the general NSImageRep code and
are not bitmap specific. Try it out...

>     path can be set for the XGGState and I think that
>     the normal behaviour should be to clip to the 
>     XGGState `window size'.

I am not I quite understand what you are getting at here - it does clip
to the window size (the second update last might makes it get the correct
portion of the bitmap too for such clips, there was a bug in the first versio
I admit). If you run it side by side against an OpenStep application it
renders the bitmaps exactly the same, scaled, tranlated, clipped to the
view bounds etc... I havent looked into non rectangular clipping
as yer though, as I dont know anything about how that is achieved in X.
Can you giuve me an exmaple of where you think it might go wrng and I'll
try it and look into fixing it. The aim is to get it behaving exactly as
a real OS system would after all...

> Also, I have never looked at colorspaces, but I feel a little
> uncomfortable of how colorspaces are handled.  I will have
> to read the documentation of understanding what is going on,
> but changing the current colorspace in the NSDrawBitMap
> code might upset other DPS code who just sees the colorspace
> changed while it did not expect this.  

Surrounding it with a gsave/grestore would solve that I guess. Certainly
the behaviour of DPSimage is suppsoed to be to use the current colourspace,
but I am not sure what the correct behaviour of OpenStep should be when
a tiff object is drawn. Its simple enough to test though - I can try it
out under OpenStep 4.2 when I get home, or possibly on OS X at
lunchtime - assuming our Mac based web designer ever goes for a lunch
break :-) When I know what a real system does I'll modified the code to
behave in the same way.

> But all in all, it is very nice to have scaled images.

Theres a lot of other bits and pieces that need looking at too though. My
interest in this is to port some code I have - so I check the behaviour
of  the two siide by side, and the scaling has not solved a problem I
was having with dissolveToPoint which still does not seem to scale. But
it has solved some problems for my code, and hopefully other people.

cheers,

-bat.