[Newbies] Morphic is slow

Nicola Mingotti nmingotti at gmail.com
Sat Sep 14 18:35:49 UTC 2019

@Cristoph, I am not experienced enough in this language to help you. I 
may be able to discuss this in a few months;)


On 9/14/19 6:35 AM, Thiede, Christoph wrote:
> Well, maybe I should mention I activated the "windows always active" 
> preferences (that I am a big fan of). So @Nicola, when I move my 
> cursor quickly about five windows, this might result in a quite large 
> number of boosts & unboosts ... Apart from that, all morphs are drawn 
> using the central #drawOn: mechanism, so I guess this would be a 
> completely new approach?
> @Jeremy Very interesting, I have always assumed that #drawOn: would be 
> somehow optimized. Still, I cannot reproduce your statements 
> completely, do the following:
> Morph subclass: #CTDebugMorph
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'CT-Experiments'.
> CTDebugMorph compile: 'drawOn: aCanvas
> aCanvas fillRectangle: self bounds color: (Color h: 0 s: 0 v: Random 
> new next).'
> CTDebugMorph openInWorld.
> The color changes very infrequent, even if you move another morph 
> partially above it ...
> How can you compare this to BouncingAtoms? In the atom example, the 
> expensive task might be rather the stepping logic than #drawOn:. I 
> think it would bring you a bucket of problems if only parts of the 
> stepping list were processed?
> However, I think BouncingAtoms does not match my current problem, as 
> SystemWindows usually do a maximum of one step per second.
> > 100 windows? This seems an abomination to me;)
> Well, why throw away a window you might need again sometime? ;-) Also, 
> I can distribute them over several separate spaces, which makes a 
> quite tidy impression.
> Best,
> Christoph
> ------------------------------------------------------------------------
> *Von:* Jeremy Landry <hakyoku at gmail.com>
> *Gesendet:* Samstag, 14. September 2019 07:29:46
> *An:* A friendly place to get answers to even the most basic questions 
> about Squeak.
> *Cc:* Thiede, Christoph
> *Betreff:* Re: [Newbies] Morphic is slow
> Oh and I forgot to mention how to test the apple theory.  If you move 
> a bunch of rectangle morphs individually and at the same time in the 
> same direction as if it's one static image, it will be slower than if 
> you put them all into a single playfield and moved the playfield by 
> itself as a single object.  The catch is, that if you want specific 
> actions to happen to those morphs, you have to conjure up a different 
> way to interact with them than you would if they were 'naked' and 
> individual objects.  I did a personal test where I made 100 squares 
> and moved them individually and, as you would think, the frame rate 
> dropped dramatically.  However, moving 100 squares inside of a 
> playfield and just moving the playfield, there was no noticible change 
> in frame rate.
> <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> 
> On Fri, Sep 13, 2019 at 10:24 PM Jeremy Landry <hakyoku at gmail.com 
> <mailto:hakyoku at gmail.com>> wrote:
>     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>
>     On Fri, Sep 13, 2019 at 10:05 PM Nicola Mingotti
>     <nmingotti at gmail.com <mailto: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 list
>>         Beginners at lists.squeakfoundation.org  <mailto:Beginners at lists.squeakfoundation.org>
>>         http://lists.squeakfoundation.org/mailman/listinfo/beginners
>         _______________________________________________
>         Beginners mailing list
>         Beginners at lists.squeakfoundation.org
>         <mailto:Beginners at lists.squeakfoundation.org>
>         http://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/20190914/2e4fb1b1/attachment-0001.html>

More information about the Beginners mailing list