Smalltalk › Squeak › Squeak - Beginners

Morphic is slow

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Christoph Thiede

Morphic is slow

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

morphic slow - messageTally.txt (27K) Download Attachment

Carpe Squeak!

Nicola Mingotti

Re: Morphic is slow

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Jeremy L.

Re: Morphic is slow

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.

Virus-free. www.avast.com

On Fri, Sep 13, 2019 at 10:05 PM Nicola Mingotti <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Jeremy L.

Re: 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.

Virus-free. www.avast.com

On Fri, Sep 13, 2019 at 10:24 PM Jeremy Landry <[hidden email]> 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.

Virus-free. www.avast.com
On Fri, Sep 13, 2019 at 10:05 PM Nicola Mingotti <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Christoph Thiede

Re: Morphic is slow

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 <[hidden email]>
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

Virus-free. www.avast.com

On Fri, Sep 13, 2019 at 10:24 PM Jeremy Landry <[hidden email]> 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.

Virus-free. www.avast.com
On Fri, Sep 13, 2019 at 10:05 PM Nicola Mingotti <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Carpe Squeak!

Nicola Mingotti

Re: Morphic is slow

@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 [hidden email]
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.

Virus-free. www.avast.com
On Fri, Sep 13, 2019 at 10:24 PM Jeremy Landry <[hidden email]> 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.

Virus-free. www.avast.com
On Fri, Sep 13, 2019 at 10:05 PM Nicola Mingotti <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners