On 2013-03-26, at 18:53, tim Rowledge <tim at rowledge.org> wrote:

> On 26-03-2013, at 8:07 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> 
>> Isn't it a bit premature to it this way? This will make these operations slower than before for everyone who does not have the plugin. Which is pretty much everyone.
> 
> Well, what is an alternative? You have to make a change at some point if you want to use anything new.

You could have left the peeker code in place and if the plugin is available, return the form itself rather than a peeker - the interface is the same. But since it is not used in critical code anyway, as you show below, I guess it's okay.

> What is the likelihood that someone is going to be loading leading edge ST code but not using a leading edge VM? I don't imagine it is very high. There is no platform VM code involved, so adding the primitive is no extra cost.

Few people build their own VMs, and not everyone upgrades their VM regularly, not even when a new image is released.

> Performance-wise, there will be a small cost in the cases where a pixelpeeker BitBlt was being created outside the loop and is now effectively inside the loop. However, look at those cases -
> Form>floodFill2:at: - no senders in a plain image
> PNMWriter>nextPutGray: & nextPutRGB: - used as a small part of  writing out images to files
> Pen>print:withFont:- no senders in a plain image
> WarpBlt>warpBitSmoothing:sourceMap: - actually implemented as a bitbltplugin prim anyway

Okay. 

> And *even* more fun comes from the fact that I can't now submit changes to fix the stuff I noticed without having the f%^%^*^&ing AbstractFont stuff sorted out. 


Just rename "*FreeType-addition" to "*FreeType-override" and the methods should magically re-appear in the graphics package.

- Bert -