Geesh, Tim. Stop scaring people away from doing good stuff! All of this can
be dealt with - if the boundary conditions are checked appropriately even
from within the image (which is one of the reasons why I pointed those out -
if they're implemented in the way I described the prims will just fail which
is correct, given the circumstances).

Incidentally, handling any of these cases isn't really that hard - all it
requires is figuring out which colors go where and if you stay in 32bpp you
won't have to worry about endianness (as one pixel = one word of input).

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Tim Rowledge
> Sent: Monday, April 07, 2003 8:06 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Form manipulation from a Plugin
> 
> 
> Oh, and don't forget to think _now_ about endianness problems. If you
> leave it till later you will probably melt your synapses. If what you
> are doing has anything whatsoever to do with images being shared or
> exported to or imported from an OS, there is a good chance 
> you will have
> to cope with endianness.
> 
> I didn't see it explicitly mentioned in Andreas' message but remember
> that if you fail the prim because of the form being 
> hibernated you just
> need to make the method unhibernate and retry. It's obvious but only
> after you've wasted time discovering it again :-) If you find 
> a surface
> reference then you probably have more problems than just endianness to
> consider; platform pixel formats are all over the map. Bigendian,
> littleendian, what Andreas & I ended up calling middleendian, 
> and worse.
> 
> Good luck....
> 
> tim
> -- 
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> No single raindrop believes it is to blame for the flood
>