Jim,

It's the hand that issues the invalidations. I don't know why and how but if
you inspect the damageRecorder of 'World primaryHand' you'll see that there
are for some reason invalidations generated when the mouse is over the menu
title.

  - A.

> -----Original Message-----
> From: Jim Benson [mailto:jb at speed.net]
> Sent: Wednesday, March 22, 2000 6:00 PM
> To: squeak at cs.uiuc.edu
> Cc: recipient list not shown
> Subject: Re: Screen damage logic
> 
> 
> Bob,
> 
> Ya know, I was actually testing with a subclass, but didn't 
> think I could
> write an email that explained that part very easily. The pies 
> on my face :-)
> Sorry if it inconvenienced anyone.
> 
> > This is part of the World redrawing a damaged area, but why 
> does it think
> the damage extends to the XXRM? One of the things the World 
> does is to try a
> top-down strategy that asks a morph what needs to be redrawn 
> below it (see
> implementors of #areasRemainingToFill:). This can allow the 
> World to avoid
> redrawing morphs further back once it is known that some 
> morph(s) in front
> completely obscure it. Simple, rectangluar, opaque morphs can 
> answer that
> they completely fill their bounds. Translucent or 
> non-rectangular morphs
> should answer the portion of their bounds in which a morph 
> behind may be
> visible. The simple answer in these cases is everything. In 
> the example you
> presented, the fact that menus (at least on my system) have 
> rounded corners
> causes them to answer the question as: "You better draw 
> everything under me,
> just to be safe".
> 
> Thanks for the explanation, I've only glanced at this part 
> during my Morphic
> travels. I wouldn't have even thought about the irregular 
> regions bit :-)
> Let me see if I understand your reply. In the case where 
> everything is a
> rectanglular and opaque, the underlying Morphs are not drawn. 
> In the case
> where we're using an object with a non-rectilinear shape, in 
> this case the
> rounded menu morph, the underlying Morphs are told that they 
> may need some
> drawing action to keep things looking nice.
> 
> I'm still confused as to why this degenerates into calling 
> the #drawOn: code
> endlessly. For example, with the round corners on, bring up 
> the menu over
> the XXRM, wander the mouse away from the menu (beeping 
> stops), then rest the
> mouse over the 'world' title. The beeps go nuts. I wouldn't 
> think that you
> need to do this drawing much more than once ( well maybe several times
> depending on how you defined your occlusion region ), yet off it goes.
> Something tells me that it's not quite right.
> 
> I'm concerned about this because the World menu is one of the 
> focal points
> of interaction in a Morphic world, and having the menus feel 
> slow detracts
> quite a bit from the overall experience. Plus rounded corners 
> is the default
> menu look for Morphic in a clean image.
> 
> Jim
>