Speaking of all those hacks in HandMorph...

Hi, there!

I am just looking into all those scary hacks in HandMorph regarding drawing routings...

Why? I stumbled upon GrafPort (BitBlt) #image:at:... methods and noticed that thei ignore Form >> #offset, which is important for AnimatedImageMorph (and animated GIFs).

I fixed that. Then, dragging things with the hand got messed up.

Let me summarize it one question:

Why does HandMorph not behave like other morphs considering, #fullBounds, #changed, #position:, #fullDrawOn:, #hasDropShadow, #drawDropShadowOn:, #drawSubmorphsOn:... ? Is it or was it a performance thing?

The goal is to avoid code like that:

aCanvas paintImage: aForm at: aForm offset.

Because only BitBlt should read #offset.

Best,
Marcel

On 03.03.2015, at 12:18, Marcel Taeumel <[hidden email]> wrote: I'm not sure that is the right way to fix it. Rather, AnimatedImageMorph should not ignore the offset.

> Then, dragging things with the hand got messed up.
>
> Let me summarize it one question:
>
> Why does HandMorph not behave like other morphs considering, #fullBounds,
> #changed, #position:, #fullDrawOn:, #hasDropShadow, #drawDropShadowOn:,
> #drawSubmorphsOn:... ? Is it or was it a performance thing?

Likely performance, yes, and also the hands are not considered part of the world (they are not submorphs of the world).

> The goal is to avoid code like that:
>
> aCanvas paintImage: aForm at: aForm offset.

Why?

> Because only BitBlt should read #offset.

BitBlt ignores the offset. The offset is pretty much only used for cursors.

- Bert -

Ah, I thought that BitBlt should handle #offset because BitBlt >> #copyForm:to:rule:colorMap: does it, too.

At the moment, it is inconsistent. However, I made AnimatedImageMorph use that offset for now.

Best,
Marcel

ActiveHand owner == ActiveWorld.

I think, hand morphs should be regular submorphs of the world. :-)

Best,
Marcel