[Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

Dimitris Chloupis kilon.alios at gmail.com
Sat Jan 16 11:29:55 EST 2016

yes Goran introduced me to the Nim language that compiles to C and they
hired the creator of it to work for their company , Goran made a squeak (it
also works with pharo) to nim bridge . But I was not aware of him using
Unreal. Definetely will send him a message . Will keep you posted on my
progress, Unreal is definitely coming to Pharo :)

On Sat, Jan 16, 2016 at 6:24 PM Esteban Lorenzano <estebanlm at gmail.com>

> On 16 Jan 2016, at 17:17, Dimitris Chloupis <kilon.alios at gmail.com> 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 <estebanlm at gmail.com>
> 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 <kilon.alios at gmail.com>
>> 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 <kilon.alios at gmail.com>
>> 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 <stephan at stack.nl>
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20160116/0f69d28f/attachment.html>

More information about the Pharo-users mailing list