Re: New bitmap code - testers required

[Pete French]

> * 4 x malloc  (shouldn't that be objc_malloc, but I don't know)
> * 4 x free 
> * and copies all the data.

Ah, gotcha - yes, thats very true. Malloc can be an expensive library
call as well (whats obj_malloc by the way - not come across that one).
As for the unnecessary copies -  also true, though I think it makes the
code clearer> I could have more special case code to catch that I guess.

> be some thing to watch out for.  Remember that this code
> might also be used a lot for small images.  (like 6x6 pixels for
> the diple in the scrollbar's divider panes and there might be more).

Indeed. Subjectively they dont seeem any slower, but you are right that it is
something to be aware of. At that level its the mallocs which are going to
be the significant overhead I suspect. I'll probably shrink that down
into a single malloc for the whole lot which shoud take out a lot
of that overhead. I am assuming alloca is badly frowned upon these
days for fast temporary storage blocks ?

> With regards to the flag for determining the behaviour.  It might
> be best to add an defaults value indicating what kind of scaling
> ought to be used.

I thought about that, but within an application you want to be able to control
the behaviour of individual images, rather than having it set globally for
the whole app. I might want to geenerate a dircetory of thumbnails and
then view an image when clicked on - for the latter I want the good
waulity rendering, for the former the poing-pick will suffice. Also for
my application I am happy to crudely render the maps on screen, but I also
have code that uses the drawings to form overlay drapes to be passed back into
OpenGL, and for that I need the smooth rendering.

Mind you, I was never entirely happy with the DPS results in that instance :-)

> You are right.  But I was confused by all the width and height
> floating around.  I thought you scaled to the destination rectangle 
> on the screen instead of the transformed source rectangle. Sorry.

*grin* I dont blame you - it took me ages to get my head round what was going
on in there which is how the first version ended up with the clipping offset
bugs in it). I am sort-of confident that its getting things in the right
place at the moment... but would be ahppy to be proved wrong as each bug
fixed makes it more robust.

O.K, so I need to look at size propagation through NSImage and also doing some
optimisation of the amount of unnecessary code copies I do. Something
to occupy my weekend when the othet half is on-call I guess :-)

-bat.