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