[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;)
bye
n.
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