On Sep 27, 2004, at 5:02 AM, John Pierce wrote:

>> I wish I could provide a suggestion or possible fix, but does anyone
>> have any ideas?
>
> Ok, so I think I am on to something here.  I actually am discovering
> that the BitBlt machinery gets really angry when an instance of Color
> coming from GOODS has, as its cachedBitPattern instVar, a
> KKObjectProxy rather than the unproxied bitmap it was expecting.

Yes, any time you end up passing a proxy into a prim you're gonna have 
trouble.

I can't think of a great way of dealing with this in the general case.  
In this case, you could override Color class>>goodsFieldDescriptors to 
not include a descriptor for the cachedBitPattern (so that it won't get 
written to or read from GOODS).  Slightly more general would be to add 
a field type something like KKAutoloadReferenceField that would always 
bring the full object in right away, rather than using a proxy, and 
mark cachedBitPattern as having this field type - this would probably 
require adding an #allowProxy flag to KKRequestObject that would be set 
to false by KKAutoloadReferenceField>>referenceAt:, and then checked by 
KKDatabase>>objectForKey:.

Another really specific solution would be to add Color as a new 
immediate value type.  We did this for Character when we were having 
very similar problems a while back.  Since object references in GOODS 
are 6 bytes, we have plenty of tag bits to play with...

Avi