Morphic slowness (was Re: Does *anyone* use MVC?)

Scott Wallace scott.wallace at squeakland.org
Sat Aug 3 09:15:03 UTC 2002


Ned and Tim,

The reason why menus are being put into the world before their final positioning takes place is that some menus need to get their items *stepped* so that the actual contents of dynamic menu items can be determined and hence the actual width of the resulting menu can be computed.

The attached change set offers the following compromise:  it still puts the menu into the world before final positioning, so that the menu's items can step, but it does so only after giving the menu an assuredly-off-screen position, so that no screen invalidation occurs.  Once the menu items have stepped, the actual positioning of the menu takes place.

This code appears to have the same performance characteristics as the fixes to this method (MenuMorph>>popUpAt:forHand:in:allowKeyboard:) that both of you posted, both of which in essence consisted of reverting the method to the 12/17/2001 version, which had the bug that update 4851 undertook to fix.

Cheers,

  -- Scott



At 11:49 PM -0700 8/2/02, Scott Wallace wrote:
>Tim,
>
>However please look at the preamble to update 4851, which fixed a couple of pernicious problems with morphic pop-up menus.  The change you suggest undoes the fix listed as (2) in that preamble.
>
>To see the bug, try a quick click on open desktop, near the right edge of the screen, both with and without your change.
>
>Now if we could only have the speed gain without the recrudescence of the bug...
>
>Cheers,
>
>  -- Scott
>
>At 1:34 AM -0500 8/3/02, gjjrs0somx001 at sneakemail.com (Tim Olson) wrote:
>>...OK, I think I found the problem.  When we pop up a system menu in response to a mousedown, the menu gets built (with position 0 at 0), then we call:
>>
>>	MenuMorph>>popUpAt:forHand:in:allowKeyboard:
>>
>>This method adds the MenuMorph to the world, starts stepping on it, then after that positions it relative to the cursor.  This causes some damage rectangles to be added at the World origin, and many times this gets coalesced with other real damage rects into a very big damage rectangle.
>>
>>If instead we first position the MenuMorph, then add it to the World, the spurious damage rectangle problems go away, and the menu seems to come up quicker.
>>
>>[see attached fileIn, which positions the menu before adding it to the world]
>>
>>	-- Tim Olson
-------------- next part --------------
Skipped content of type multipart/appledouble


More information about the Squeak-dev mailing list