Creation form from PNG file very slow on Pharo 4 and 5

2016-01-16 13:50 GMT+01:00 Dimitris Chloupis <[hidden email]>:

Seems that creating forms and morph from pngs is super slow

opened bug report

https://pharo.fogbugz.com/f/cases/17403/Creating-Forms-from-PNGs-is-very-slow

your are loading 0-59 images in one turn. this takes ~ 1000 ms. Thats not bad.

How about loading them only on demand? This may cut down the start up time:

attache a small change for get and put the images into a dictionary and only load new

"xx seconds-image" when it is used for the  first time.

- > [ChronosManager open] timeToRun
 "0:00:00:00.626"

sorry but thats plain horrible performance wise and those images are needed as soon as the gui is opened. So there can be no lazy loading for them. The total size for all the 60 images is 530kbs . What would happen if I did some serious animations of 10s of mbs , I will have to go to buy a coffee to get my GUI opened :D

On Sat, Jan 16, 2016 at 3:41 PM Nicolai Hess <[hidden email]> wrote:

2016-01-16 13:50 GMT+01:00 Dimitris Chloupis <[hidden email]>:

Seems that creating forms and morph from pngs is super slow

opened bug report

https://pharo.fogbugz.com/f/cases/17403/Creating-Forms-from-PNGs-is-very-slow

your are loading 0-59 images in one turn. this takes ~ 1000 ms. Thats not bad.

How about loading them only on demand? This may cut down the start up time:

attache a small change for get and put the images into a dictionary and only load new

"xx seconds-image" when it is used for the  first time.

- > [ChronosManager open] timeToRun
 "0:00:00:00.626"

disk, 1TB. why it matters ? from my profile its clear that its not the primitive that is the problem but how Pharo processes pngs.

I happen to work with a lot of big data both in 3d graphics, a blender file can easily reach 250 mb and it opens under a second and audio files , plus instrument that uses alot of audio files as samples of several gbs giving again instanenous loading. I am not talking here 60 files, I am talking thousands of files.

I report a sever limitation and I have been told

a) I have not done enough to isolate the problem when I post clear profiling reports and the code that is responsible for it

b) why I make a fuss about it since there are work arounds

c) that its a hardware limitation when the hardware is able to perform light years ahead of what pharo is currently doing

Sorry but this kind of attitude is really bad, when someone reports a bug I find it a lot better to tell him that you don't care or not reply at all and ignore him than just find excuses for the bug or limitation.

I see it every single time I complain about a problem there is a few people who are logical about this like Ben , Esteban etc and then some other that in complete denial zone and easily offended by the truth.

On Sat, Jan 16, 2016 at 4:07 PM Stephan Eggermont <[hidden email]> wrote:

On 16-01-16 14:48, Dimitris Chloupis wrote:
> sorry but thats plain horrible performance wise and those images are
> needed as soon as the gui is opened. So there can be no lazy loading for
> them. The total size for all the 60 images is 530kbs . What would happen
> if I did some serious animations of 10s of mbs , I will have to go to
> buy a coffee to get my GUI opened :D

Is that on a disk or an SSD? You won't be able to get much more than 60
files opened/s on a disk.

Stephan

Hi Kilon, 

I’m sorry to feel you frustrated. 

Is clear than morphic (and the world) as it is now is not well suited to the kind of development you want to do, and clearly documentation is not good enough (even if we have moved forward recently, in part with your collaboration)… 

Anyway, yes, using the world as is and morphic are not very suitable to hard consuming graphics, but there are works that have been happening that improves all that: 

Using not the world, but SDL2 (through OS-Window) will reduce the cpu consumption drastically… in fact, what happens now (as far as I can guess… since I don’t know your stuff) is not that instancing a png is slow, but the rendering (you are redrawing every time and that is not optimised in morphic, who takes area as damaged every time and redraws it… using athens, who is vectorial and then consuming). 

So, with SDL2 you will improve (and you will have separated windows).

Also, I think you do 3d stuff so in your case I would explore wooden… I remember Ronnie showed me an animated scene (I think it was the water example) with more then 200 fps without much effort. 

Finally… I know about people doing animations with Pharo (and morphic) than have a lot better performance than you had… so there is clearly a problem there. If you give me your sources I can give them a look and try to figure out what is happening. 

So well… I think is not that is not possible, but that you are traveling paths that are new for us, then not documented (or even tested), or really optimised. 

Something that we are willing to improve, as always :)

cheers!

Esteban

On 16 Jan 2016, at 15:47, Dimitris Chloupis <[hidden email]> wrote:

in any case, ignore my bug reports, I am done with this, I waste my time and your time . Its clear pharo is not really suited for my needs, life goes on.

On Sat, Jan 16, 2016 at 4:40 PM Dimitris Chloupis <[hidden email]> wrote:

disk, 1TB. why it matters ? from my profile its clear that its not the primitive that is the problem but how Pharo processes pngs.

I happen to work with a lot of big data both in 3d graphics, a blender file can easily reach 250 mb and it opens under a second and audio files , plus instrument that uses alot of audio files as samples of several gbs giving again instanenous loading. I am not talking here 60 files, I am talking thousands of files.

I report a sever limitation and I have been told

a) I have not done enough to isolate the problem when I post clear profiling reports and the code that is responsible for it

b) why I make a fuss about it since there are work arounds

c) that its a hardware limitation when the hardware is able to perform light years ahead of what pharo is currently doing

Sorry but this kind of attitude is really bad, when someone reports a bug I find it a lot better to tell him that you don't care or not reply at all and ignore him than just find excuses for the bug or limitation.

I see it every single time I complain about a problem there is a few people who are logical about this like Ben , Esteban etc and then some other that in complete denial zone and easily offended by the truth.

On Sat, Jan 16, 2016 at 4:07 PM Stephan Eggermont <[hidden email]> wrote:

On 16-01-16 14:48, Dimitris Chloupis wrote:
> sorry but thats plain horrible performance wise and those images are
> needed as soon as the gui is opened. So there can be no lazy loading for
> them. The total size for all the 60 images is 530kbs . What would happen
> if I did some serious animations of 10s of mbs , I will have to go to
> buy a coffee to get my GUI opened :D

Is that on a disk or an SSD? You won't be able to get much more than 60
files opened/s on a disk.

Stephan

On 16 Jan 2016, at 17:17, Dimitris Chloupis <[hidden email]> wrote:

Thanks Estaban as I said I am not giving up on Pharo.

I am actually very interested making pharo work with Unreal to give Pharo access to the most powerful graphics engine out there. Yeap moving to SDL could help a lot, I am 100% behind this idea.

Definetly will keep using Pharo but I will try to integrate with powerful existing technology , so maybe I can bring something new to Pharo too , its not a suprise that Morphic is not up to my demands, these things take a lot of coders and resources that pharo does not have. Like you I believe in leveraging existing technologies from inside Pharo like SDL.

If I am able to build Unreal Engine with a minimal Pharo API as a DLL and use your FFI to control it, I think I will have the best of both world. I will have to experiment and see :)

btw… I think joining unreal with pharo can give us a lot of power :) 

Also this something already done by Goran at 3dicc (http://www.3dicc.com) … I think his work is closed but Goran has always been very helpful and offered guidelines, etc. (I wanted to do the Unreal-Pharo bridge myself but well… no time so I stopped) :D

I think if you are serious in your attempt I can put both of you in contact...

cheers,

Esteban

On Sat, Jan 16, 2016 at 5:49 PM Esteban Lorenzano <[hidden email]> wrote:

Hi Kilon, 

I’m sorry to feel you frustrated. 

Is clear than morphic (and the world) as it is now is not well suited to the kind of development you want to do, and clearly documentation is not good enough (even if we have moved forward recently, in part with your collaboration)… 

Anyway, yes, using the world as is and morphic are not very suitable to hard consuming graphics, but there are works that have been happening that improves all that: 

Using not the world, but SDL2 (through OS-Window) will reduce the cpu consumption drastically… in fact, what happens now (as far as I can guess… since I don’t know your stuff) is not that instancing a png is slow, but the rendering (you are redrawing every time and that is not optimised in morphic, who takes area as damaged every time and redraws it… using athens, who is vectorial and then consuming). 

So, with SDL2 you will improve (and you will have separated windows).

Also, I think you do 3d stuff so in your case I would explore wooden… I remember Ronnie showed me an animated scene (I think it was the water example) with more then 200 fps without much effort. 

Finally… I know about people doing animations with Pharo (and morphic) than have a lot better performance than you had… so there is clearly a problem there. If you give me your sources I can give them a look and try to figure out what is happening. 

So well… I think is not that is not possible, but that you are traveling paths that are new for us, then not documented (or even tested), or really optimised. 

Something that we are willing to improve, as always :)

cheers!

Esteban

On 16 Jan 2016, at 15:47, Dimitris Chloupis <[hidden email]> wrote:

in any case, ignore my bug reports, I am done with this, I waste my time and your time . Its clear pharo is not really suited for my needs, life goes on.

On Sat, Jan 16, 2016 at 4:40 PM Dimitris Chloupis <[hidden email]> wrote:

disk, 1TB. why it matters ? from my profile its clear that its not the primitive that is the problem but how Pharo processes pngs.

I happen to work with a lot of big data both in 3d graphics, a blender file can easily reach 250 mb and it opens under a second and audio files , plus instrument that uses alot of audio files as samples of several gbs giving again instanenous loading. I am not talking here 60 files, I am talking thousands of files.

I report a sever limitation and I have been told

a) I have not done enough to isolate the problem when I post clear profiling reports and the code that is responsible for it

b) why I make a fuss about it since there are work arounds

c) that its a hardware limitation when the hardware is able to perform light years ahead of what pharo is currently doing

Sorry but this kind of attitude is really bad, when someone reports a bug I find it a lot better to tell him that you don't care or not reply at all and ignore him than just find excuses for the bug or limitation.

I see it every single time I complain about a problem there is a few people who are logical about this like Ben , Esteban etc and then some other that in complete denial zone and easily offended by the truth.

On Sat, Jan 16, 2016 at 4:07 PM Stephan Eggermont <[hidden email]> wrote:

On 16-01-16 14:48, Dimitris Chloupis wrote:
> sorry but thats plain horrible performance wise and those images are
> needed as soon as the gui is opened. So there can be no lazy loading for
> them. The total size for all the 60 images is 530kbs . What would happen
> if I did some serious animations of 10s of mbs , I will have to go to
> buy a coffee to get my GUI opened :D

Is that on a disk or an SSD? You won't be able to get much more than 60
files opened/s on a disk.

Stephan

2016-01-16 15:40 GMT+01:00 Dimitris Chloupis <[hidden email]>:

disk, 1TB. why it matters ? from my profile its clear that its not the primitive that is the problem but how Pharo processes pngs.

I happen to work with a lot of big data both in 3d graphics, a blender file can easily reach 250 mb and it opens under a second and audio files , plus instrument that uses alot of audio files as samples of several gbs giving again instanenous loading. I am not talking here 60 files, I am talking thousands of files.

I report a sever limitation and I have been told

a) I have not done enough to isolate the problem when I post clear profiling reports and the code that is responsible for it

The bug report was indeed bad.

 

b) why I make a fuss about it since there are work arounds

I did not see the "why make a fuss about". And the work arounds are actually helpful, no?

 

c) that its a hardware limitation when the hardware is able to perform light years ahead of what pharo is currently doing

Sorry but this kind of attitude is really bad, when someone reports a bug I find it a lot better to tell him that you don't care or not reply at all and ignore him than just find excuses for the bug or limitation.

You reported a problem with morphics image loading and some people immediately step in to help you analyse your code. More pepole helped by

giving some tipps and possible workaounds.

What is wrong with this. I don't see a bad attitude.

 

I see it every single time I complain about a problem there is a few people who are logical about this like Ben , Esteban etc and then some other that in complete denial zone and easily offended by the truth.

On Sat, Jan 16, 2016 at 4:07 PM Stephan Eggermont <[hidden email]> wrote:

On 16-01-16 14:48, Dimitris Chloupis wrote:
> sorry but thats plain horrible performance wise and those images are
> needed as soon as the gui is opened. So there can be no lazy loading for
> them. The total size for all the 60 images is 530kbs . What would happen
> if I did some serious animations of 10s of mbs , I will have to go to
> buy a coffee to get my GUI opened :D

Is that on a disk or an SSD? You won't be able to get much more than 60
files opened/s on a disk.

Stephan