On the performance of our browsers... THEY TICK!

On Sun, Jan 21, 2018 at 09:46:46AM +0100, Marcel Taeumel wrote:
It is not a legacy of MVC. I put an "OSProcess trace" in PluggableListView>>verifyContents,
and the updates are efficient and happen as you would expect. In Morphic, ugh! we should
fix it as you say.

I have not really looked into it, but I suspect that most of the necessary #changed:
notifications are already in place, at least for things like browsers and debuggers
that are fully supported in MVC. So it may be just a matter of adding #update:
handlers in Morphic "views" so that the existing change notifications are handled
there, rather than relying on stepping.

Many of the #update: handlers seem to be already in place, so perhaps the stepping
is just a safety net that never got removed?

Dave

>
> Best,
> Marcel
>
> P.S.: Also see SystemWindow >> #stepTime and all implementors of #stepTimeIn:. ;-)
> P.P.S.: Only our Inspector needs it since we have no clue what "changed" means for an arbitrary object.
>

A lot of Morphs simply fetch & re-render new info at every tick (or at least, they used to). For some case that is actually proper (think Dave N Smith’s ancient crawling BlobMorph).

Some got a bit smarter and at least compared the new info to the old before rendering new stuff. Of course, sometimes that involves comparing something a bit more complex than a 10 character String, so not all that smart. And sometimes even simply fetching the new info involves proxies transforming into large amounts of data obtained fro a slow server somewhere, or a colossal list being pointlessly rebuilt.

Getting everything up to date and using #changed etc so morphs only update when they plausibly need to would be a nice thing for slower machines like Pis. We’ll need to have something that considers all the browsers to be its dependents so that when a code change is made that would affect a browser other than the active one we can have the change broadcast to everyone properly. And it would be nice for it to be able to be pretty specific about the change so something a bit more efficient than ‘redraw everything’ can be used. The current CodeHolder>>#updateCodePaneIfNeeded and CodeHolder>>#didCodeChangeElsewhere arrangement doesn’t look particularly nice.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: MAW: Make Aggravating Whine

On Sun, Jan 21, 2018 at 10:46:59AM -0800, tim Rowledge wrote:
> A lot of Morphs simply fetch & re-render new info at every tick (or at least, they used to). For some case that is actually proper (think Dave N Smith???s ancient crawling BlobMorph).
>
> Some got a bit smarter and at least compared the new info to the old before rendering new stuff. Of course, sometimes that involves comparing something a bit more complex than a 10 character String, so not all that smart. And sometimes even simply fetching the new info involves proxies transforming into large amounts of data obtained fro a slow server somewhere, or a colossal list being pointlessly rebuilt.
>
> Getting everything up to date and using #changed etc so morphs only update when they plausibly need to would be a nice thing for slower machines like Pis. We???ll need to have something that considers all the browsers to be its dependents so that when a code change is made that would affect a browser other than the active one we can have the change broadcast to everyone properly. And it would be nice for it to be able to be pretty specific about the change so something a bit more efficient than ???redraw everything??? can be used. The current CodeHolder>>#updateCodePaneIfNeeded and CodeHolder>>#didCodeChangeElsewhere arrangement doesn???t look particularly nice.
>

That sounds right. If I comment out the body of CodeHolder>>stepIn: so that
it no longer callse #updateListsAndCodeIn: when stepping, the browsers continue
to work as expected, so the basic MVC style updates are workin in the browsers.
However, if I open a versions browser and use it to revert a method, then
the corresponding code pane in another browser no longer gets updated.

It looks like the stepping updates are there to ensure that open browsers
get updated even though we do not (yet) have the "something that considers
all the browsers to be its dependents" part implemented.

If it is true that the stepping updates are being done primarily to ensure
updates for all browsers within a Morphic world, and if it is also true
that some sort of registry is required, then it might make sense for the
current world to be responsible for keeping the registry, such that change
notifications would be delivered to browsers within the current world, and
not to all browsers in all of the other Morphic projects that may exist
in an image.

But I have a feeling I am overlooking something obvious. Isn't there some
more global notification mechanism already present in SystemOrganizer or
SystemNavigation or some such thing?

Dave
 

> If it is true that the stepping updates are being done primarily to ensure
> updates for all browsers within a Morphic world, and if it is also true
> that some sort of registry is required, then it might make sense for the
> current world to be responsible for keeping the registry, such that change
> notifications would be delivered to browsers within the current world, and
> not to all browsers in all of the other Morphic projects that may exist
> in an image.
It is common for me to have browsers open on the same class across
different projects, so I would appreciate if all browsers were updated.

Actually, I have already be bitten by old code still being displayed as
current in a browser. I do not remember the details though, but it could
involve swapping projects.


Stef

On Sun, Jan 21, 2018 at 09:08:32PM +0100, St??phane Rollandin wrote:
Stef,

Of course you are right, they do all need to be updated. Sorry that was
a bad idea, please disregard.

Dave