[Newbies] Morphic is slow

Jeremy Landry hakyoku at gmail.com
Sat Sep 14 05:24:14 UTC 2019


I've looked at morphic performance via Etoys many times and am not certain
if this ever got addressed, but from my understanding, morphic doesn't do
anything to detect what should be drawn and what should not (i.e. covered
up items).  So for instance, if you move a window over a lot of other
windows (or move your mouse, it has to draw this too, afaik), then it's
going to redraw every unseen thing under neath.

You can test this in a 'micro' example by looking at frames per second by
dragging a simple rectangle around the screen over various stacks of other
rectangles and just the blank world.  Instead of treating things that
aren't moving as a 'static image', it tries to redraw every single thing
affected from scratch. I did quite a lot of research into 'how' morphic
works in this way when I was developing some action-game type stuff in
EToys.  What I found is that the less dynamic things are (i.e. static
pictures, for instance where it simply needs to be read from memory) vs.
drawing things from scratch (i.e. a rectangle morphic object), speed is
dramatically increased.  So having 100 windows, each one using drawing
commands instead of reading memory would definitely slow things down, even
for just drawing the mouse, I would think.

Again, just my guess.  There's a lot of 'workarounds' for this, but I think
the biggest one would be for morphic to figure out what is static and what
is moving, take proper bitmapped copy into a buffer to redraw any 'mess'
made by moving something.  I am not smart enough to program this so I can
only say what I think is the problem and what I think could be done to fix
it.


There was a video on this phenomena using Cuis Smalltalk and it exhibits
the same issues, except they used the bouncing atoms example, showing that
atoms in the morph drawing behind things still are drawn when they don't
need to be and as a result, would hurt the rate of the screen updates.

I hope this helps in some way and maybe someone smarter than me (and with
spare time and will power) can tackle this issue.  Video performance can be
much greater even without using tricks like sending everything to OpenGL or
some such if this were looked at and, imo, probably is really more an issue
with extremely old legacy objects and methods tied to screen drawing
regardless of morphic, but that's just speculation on my part. I really
don't know.

If it's of interest, some other things I've found that speed things up is
the number of times the same methods are called by multiple objects. As an
example, it seems like if you have, say, 5 apples and you want to move them
from one desk to another, the quickest way is to put the apples into a
container then move the container full of all the apples at once, but it
appears as if Smalltalk's solution is to move back and forth 5 times
between the two desks, each time carrying a single apple.  Again, this is
just a hunch, and if it were true, I wouldn't know the first thing about
fixing it or how much of a smalltalk image would break as a result.





<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, Sep 13, 2019 at 10:05 PM Nicola Mingotti <nmingotti at gmail.com>
wrote:

>
> 100 windows? This seems an abomination to me;)
>
> Anyhow, this is what i am fancying:
> - Suppose you open each window in its own (green) thread and give it an
> insignificant priority
> - When you click on one window then you increase that thread priority, and
> make it good enough to be interactive.
>
> I don't know if it is feasible, if it is, i fell it will work;)
>
> Happy experimentation
> bye
> nicola
>
>
>
>
>
>
> On 9/13/19 5:14 PM, Thiede, Christoph wrote:
>
> Hi all,
>
>
> I'm sure this is a FAQ, but I still don't know the perfect answer on it.
>
> I often have opened more than 100 windows in a project (no problem to keep
> an overview using WindowAcrobatics), and it can be really slow to operate
> the image when I move my cursor over the world - often only 1 FPS.
>
> I attached a MessageTally report because I hope it reveals some anomalies
> that could be specific to my image.
>
>
> I see that my CTStatusMonitorMorph* costs some percents, but even if I
> disable it, my FPS are often <= 10. Do you have any tips for me?
>
>
> Best,
>
> Christoph
>
> _______________________________________________
> Beginners mailing listBeginners at lists.squeakfoundation.orghttp://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>
> _______________________________________________
> Beginners mailing list
> Beginners at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/beginners/attachments/20190913/4c37238b/attachment.html>


More information about the Beginners mailing list