Re: [Pharo-users] Morphic is super slow

[Dimitris Chloupis]

Hello Ben :)

First thanks for investing 1 hour of your precious time to look through my
code. I really appreciate it . If there is one thing I love about pharo is
the super amazing community.

Yes definetly my fault as always :D

I did not know about this profiling, I used it for the creating of my
Morphs but it did not occur to me to google like you did and go with
profiling all processes.

A huge thank you to latsaben and the rest of you guys. I downgraded down to
Pharo 4 and again I agree 5 is the unstable version anyway but I loved
using the new tools and could not wait till April for the Pharo 5 release
:)

The problem is battling without documentation is very hard and I have spent
at least 10 hours trying to understand how taskbar works and I still fail.

Your code solves my problem , apart from 1. Loading those pngs is
sloow, one would expect that accesing the files themselves to get the
binary data is what is slow for pharo but no, thats is fast enough. What is
slow , because I profiled this is converting the binary data to  form is
consuming a ton of time. The result is that to load a GUI with only 1 mb of
pngs takes 1 second.

Also with your solution I lose the ability to update my taskbar icon, by
the way the non optimised code I was using is a direct copy from
SystemWindow class, which means that class should be optimised too.

Another problem is the scaling of images, really bad with morphic though
Athens must be better.

Auto completion problems are well knows, sometimes autocompletion does not
show all methods, sometimes autocompletion shows every character you type
so for example ChronosManager open will show
ChronosManager o
ChronosManager op
ChronosManager ope
ChronosMAnager open

Sometimes it shows methods that do not even belong to the class forcing me
to use Spotter to find the correct method. Its a a mess.

I am not abandoning pharo, I love it even with its flaws. But I try to
outsource as much as I can my workflow from pharo to external libraries and
apps that are way more mature and efficient for what I am trying to do.

I always inteded to make Blender work with Pharo, I accomplished that now I
want to make Unreal engine to work with pharo, so I can make a triangle of
love, Blender for asset creation, Unreal for real time rendering of 2d and
3d graphics , Pharo as the brain of the logic and advanced scripting of the
other 2. This is was my dream and goal all along. So I will be moving my
GUI to Unreal that will allow me much more advanced and performance
orientated features that mix 2d with 3d but I will keeping my main logic in
pharo.


On Sat, Jan 16, 2016 at 6:35 AM Ben Coman  wrote:

> On Sat, Jan 16, 2016 at 7:28 AM, Dimitris Chloupis
>  wrote:
> > taskbarTask (self valueOfProperty: #noTaskbarTask ifAbsent: [ false ])
> > ifTrue: [ ^ nil ]. ^ nil "TaskbarTask morph: self state: self
> taskbarState
> > icon: self taskbarIcon label: self taskbarLabel"
> >
> > The uncommented part was the one that was slowing me down, its a copy
> from
> > SystemWindow, on a new image of Pharo consumption drops to 15% but still
> > have issues with Nautilus etc.
> >
> > latsabben at Slack also recommended caching which helped also
> >
> > taskbarTask "myTask := nil." myTask ifNil: [ myTask := TaskbarTask morph:
> > self state: self taskbarState icon: self taskbarIcon label: self
> > taskbarLabel ]. myTask label: self taskbarLabel. ^myTask
> >
> > Anyway I decided to port my project to C++ and Unreal Engine because I
> have
> > many issues with Pharo speed wise
>
> See my other post, in about an hour I moved your App from 55% cpu
> usage on my machine to 7%, only 1% above our 6% idle.   We *do* need
> to address that minimum idle, but its at the VM level since in-Image
> profiling shows 90% time in ProcessorScheduler class>>idleProcess.  So
> to me the Image seems not too bad performance wise
>
> > and stability wise with Pharo 5.
>
> Well, you are talking about bleeding edge alpha software.
>
> > Plus many IDE features I miss like proper auto completion etc.
>
> You've probably mentioned this somewhere previously, but in another
> thread could you leave us with a summary of what is missing from auto
> completion.
>
> > To be fair I tried to make custom gui with python and it was even slower
> in
> > the past.
> >
> > So its clear I need a high performance language + API, because I will be
> > building a very heavy GUI (many more animations)  and I would like also
> some
> > fast 3d functionality too.
>
> good luck with it.
> cheers -ben
>
>
> >
> > On Sat, Jan 16, 2016 at 1:07 AM Sven Van Caekenberghe 
> wrote:
> >>
> >>
> >> > On 15 Jan 2016, at 23:30, Dimitris Chloupis 
> >> > wrote:
> >> >
> >> > taskbar was the problem, damn pharo gui is a huge pain in the hat.
> >>
> >> How so ?
> >>
> >> > On Fri, Jan 15, 2016 at 11:32 PM Dimitris Chloupis
> >> >  wrote:
> >> > ITs not the step, I 

Re: [Pharo-users] Morphic is super slow

[stepharo]

Yes nautilus is full of wrong changed messages and others.

Stef


Le 16/1/16 00:11, Nicolai Hess a écrit :



2016-01-16 0:06 GMT+01:00 Sven Van Caekenberghe >:



> On 15 Jan 2016, at 23:30, Dimitris Chloupis
> wrote:
>
> taskbar was the problem, damn pharo gui is a huge pain in the hat.

How so ?


I would like to now that too.

Btw, this is interesting too:

WorldState debugShowDamage:true.

And look all the flashing in a nautilus and or playground window.


> On Fri, Jan 15, 2016 at 11:32 PM Dimitris Chloupis
> wrote:
> ITs not the step, I removed the step as I said in my first post.
Still 30% cpu consumption
>
> The images are PNGs and RGBA , 8bit
>
>
> On Fri, Jan 15, 2016 at 10:54 PM Hilaire > wrote:
> It depends on what you are doing in a step, but 1s step should
not hurt.
> May be the problem is somewhere else.
> With DrGeo, I noted Athens is faster to BitBlt with bitmap
operations
> (in my case, only scaling and displaying a From in a DrGeo canvas).
> Also, do your bitmaps come with 32 bits depth?
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Re: [Pharo-users] Morphic is super slow

[stepharo]

taskbar was the problem,

what was it?

damn pharo gui is a huge pain in the hat.

And we improved it a lot already.
But this is not by accident that Alain spent a couple of years working 
on Bloc


On Fri, Jan 15, 2016 at 11:32 PM Dimitris Chloupis 
> wrote:


ITs not the step, I removed the step as I said in my first post.
Still 30% cpu consumption

The images are PNGs and RGBA , 8bit


On Fri, Jan 15, 2016 at 10:54 PM Hilaire > wrote:

It depends on what you are doing in a step, but 1s step should
not hurt.
May be the problem is somewhere else.
With DrGeo, I noted Athens is faster to BitBlt with bitmap
operations
(in my case, only scaling and displaying a From in a DrGeo
canvas).
Also, do your bitmaps come with 32 bits depth?

--
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Morphic is super slow

[Dimitris Chloupis]

ok found how to update the taskbar button , I add this to my step

World submorphs do: [ :each| (each isKindOf: TaskbarMorph) ifTrue: [each
updateTaskButtons]]

pharo at 6-9% consumption of course depending on the size of the pharo
window. Not bad at all :)

Thank you all for your help, problem solved

On Sat, Jan 16, 2016 at 10:12 AM Dimitris Chloupis 
wrote:

> Yeap I cannot wait for Bloc :)
>
> a big thanks to Alain, Bloc already looks amazing from the little I tried.
> I am sure the loading of PNGs will be optimised at some point too in the
> future. Everything is a matter of time.
>
> Stef see my previous posts to see what was the issue but that summary is
> that I copied a method from SystemWindow which apparently was not optimized
> and was creation a new morph each cycle for a taskbar button.
>
> On Sat, Jan 16, 2016 at 10:08 AM stepharo  wrote:
>
>>
>> taskbar was the problem,
>>
>> what was it?
>>
>> damn pharo gui is a huge pain in the hat.
>>
>> And we improved it a lot already.
>> But this is not by accident that Alain spent a couple of years working on
>> Bloc
>>
>>
>> On Fri, Jan 15, 2016 at 11:32 PM Dimitris Chloupis 
>> wrote:
>>
>>> ITs not the step, I removed the step as I said in my first post. Still
>>> 30% cpu consumption
>>>
>>> The images are PNGs and RGBA , 8bit
>>>
>>>
>>> On Fri, Jan 15, 2016 at 10:54 PM Hilaire  wrote:
>>>
 It depends on what you are doing in a step, but 1s step should not hurt.
 May be the problem is somewhere else.
 With DrGeo, I noted Athens is faster to BitBlt with bitmap operations
 (in my case, only scaling and displaying a From in a DrGeo canvas).
 Also, do your bitmaps come with 32 bits depth?

 --
 Dr. Geo
 http://drgeo.eu




>>

Re: [Pharo-users] Morphic is super slow

[Dimitris Chloupis]

Take your time, no rush, Pharo 4 is fine for me. It even has Spotter that I
use a lot. More than enough for my needs. I was using Pharo 5 to report
back issues and problems but I just cant work with it anymore.

So I will sit here and wait here, using a stable version that I know works
very well for me without complaining about anything that brakes using a
version I should not be using for production code anyway.

On Sat, Jan 16, 2016 at 1:04 PM Esteban Lorenzano 
wrote:

> yes, there is a problem in the cleanup of freetype fonts.
> that’s not a vm bug, but it started to happen very often after migrating.
>
> Is in my high priority TODO list, right after a couple of FFI tweaks :S
>
> Esteban
>
> On 16 Jan 2016, at 11:54, Dimitris Chloupis  wrote:
>
>
> ok if I open a nautilus window and then I save the image , it does not
> create this error
>
> o_O
>
> crazy stuff
>
> :D
>
> On Sat, Jan 16, 2016 at 12:51 PM Dimitris Chloupis 
> wrote:
>
> 
>>
>> yes even with stable VM is a mess, new problem
>>
>> I got pharo with this
>>
>> wget -O- get.pharo.org/alpha+vm | bash
>>
>> downloads fines, loads my libraries fine with my startup script as soon
>> as i try to save the image the above happens
>>
>>
>>
>>
>> On Sat, Jan 16, 2016 at 12:43 PM Dimitris Chloupis 
>> wrote:
>>
>>> Esteban I also get doSemantics: errors , I have been getting way way
>>> back before Spur while trying to use shortcuts. It was messing also with
>>> the rendering of the method list in Nautilus when there were too many
>>> methods, it turned to a red box of death. So I am not convinced my problem
>>> are just VM related but you can correct me if I am wrong.
>>>
>>> On Sat, Jan 16, 2016 at 12:41 PM Esteban Lorenzano 
>>> wrote:
>>>
 On 16 Jan 2016, at 11:27, Dimitris Chloupis 
 wrote:

 yes thanks Esteban I am back to Pharo 4 and I am fine :)


 you do not need to go back to Pharo 4… just downloading stable VM is
 enough :)
 (and I need people helping me to find the bugs on Pharo 5, spur, FFI,
 etc. *before* release :P)

 cheers,
 Esteban


 will stick with it, till the release of Pharo 5.

 On Sat, Jan 16, 2016 at 12:25 PM Esteban Lorenzano 
 wrote:

> On 16 Jan 2016, at 01:01, Dimitris Chloupis 
> wrote:
>
> 
>
> and by the way menus on latest pharo 5 are broken
>
>
> not the menus
> there is a problem with WideString and string primitives in latest
> spur vm.
> in the mean time you can download stable instead latest and you will
> be ok.
>
> Esteban
>
>
>
> On Sat, Jan 16, 2016 at 1:29 AM Nicolai Hess 
> wrote:
>
>> 2016-01-16 0:11 GMT+01:00 Nicolai Hess :
>>
>>>
>>>
>>> 2016-01-16 0:06 GMT+01:00 Sven Van Caekenberghe :
>>>

 > On 15 Jan 2016, at 23:30, Dimitris Chloupis <
 kilon.al...@gmail.com> wrote:
 >
 > taskbar was the problem, damn pharo gui is a huge pain in the hat.

 How so ?

>>>
>>> I would like to now that too.
>>>
>>> Btw, this is interesting too:
>>>
>>> WorldState debugShowDamage:true.
>>>
>>> And look all the flashing in a nautilus and or playground window.
>>>
>>
>> Hm, I think this was my fault. The fix for
>> 17201
>> 
>> Marking Diffs broken in Pharo5
>> wasn't good.
>>
>>
>>
>>
>>>
>>>

 > On Fri, Jan 15, 2016 at 11:32 PM Dimitris Chloupis <
 kilon.al...@gmail.com> wrote:
 > ITs not the step, I removed the step as I said in my first post.
 Still 30% cpu consumption
 >
 > The images are PNGs and RGBA , 8bit
 >
 >
 > On Fri, Jan 15, 2016 at 10:54 PM Hilaire 
 wrote:
 > It depends on what you are doing in a step, but 1s step should
 not hurt.
 > May be the problem is somewhere else.
 > With DrGeo, I noted Athens is faster to BitBlt with bitmap
 operations
 > (in my case, only scaling and displaying a From in a DrGeo
 canvas).
 > Also, do your bitmaps come with 32 bits depth?
 >
 > --
 > Dr. Geo
 > http://drgeo.eu
 >
 >
 >



>>> ​
>
>

Re: [Pharo-users] Morphic is super slow

[Ben Coman]

On Sat, Jan 16, 2016 at 4:03 PM, Dimitris Chloupis
 wrote:
> Hello Ben :)
>
> First thanks for investing 1 hour of your precious time to look through my
> code. I really appreciate it . If there is one thing I love about pharo is
> the super amazing community.
>
> Yes definetly my fault as always :D
>
> I did not know about this profiling, I used it for the creating of my Morphs
> but it did not occur to me to google like you did and go with profiling all
> processes.
>
> A huge thank you to latsaben and the rest of you guys. I downgraded down to
> Pharo 4 and again I agree 5 is the unstable version anyway but I loved using
> the new tools and could not wait till April for the Pharo 5 release :)
>
> The problem is battling without documentation is very hard and I have spent
> at least 10 hours trying to understand how taskbar works and I still fail.
>
> Your code solves my problem , apart from 1. Loading those pngs is sloow,
> one would expect that accesing the files themselves to get the binary data
> is what is slow for pharo but no, thats is fast enough. What is slow ,
> because I profiled this is converting the binary data to  form is consuming
> a ton of time. The result is that to load a GUI with only 1 mb of pngs takes
> 1 second.

What is the practical effect of this that is most concerning?
1. The time taken loading it the first time after installing from
Catalog Browser ?
2. The time taken to start it *each* time from World > Chronos
Manager, if you open/close it a lot?
3. Distributing Chronos Manager as a packaged application?
each time you want to open it

Not sure if the following will suit your needs, but in the definition
of ChrGUIMorph try moving 'secondsTimerFormCollection' from
instanceVariableNames: to classVariableNames:

then test by opening/closing the app a few times.  After taking a
while opening the first time, subsequent openings seem to be faster.

>
> Also with your solution I lose the ability to update my taskbar icon, by the
> way the non optimised code I was using is a direct copy from SystemWindow
> class, which means that class should be optimised too.

So consider that solution just a problem-isolation step on the way ;).
I had another look because I was intrigued that even though you used
LRUCache for the /icons/ variable, the ifAbsent: block in
#logotinyIcon was being executed anyway.  I thought that must be cache
size too small and items bumped out, so as a test I replace LRUCache
with Dictionary, but the the ifAbsent: block was *still* getting
executed (note, this is at steady-state, not startup).  So I thought
/icons/ must be getting reset. Investigating by putting the following
at the top of #initializeIcons...

   Transcript crShow: thisContext printString ,
   ' <-- ', thisContext sender printString,
   ' <-- ', thisContext sender sender printString.

So now this executes every time I open the World menu.  And after
ChronosManager is opened, the Transcript scroll rapidly. So everywhere
you do something like this...
   icon: ChrStopwatchSettingsPNG new logotinyIcon
where logotinyIcon returns an object, the object created by #new is
thrown away.  Worse, #new invokes #initialize and hence
#initializeIcons wipes out your cache every cycle.

Try making /icons/ a class variable and moving methods like
logotinyIcon to the class side, so instead you do...
 icon: ChrStopwatchSettingsPNG logotinyIcon

Also move #initializeIcons to class side and add a class side
#initialize method to call it.  Note that will only be executed when
the class is first loaded, so you will probably need to execute it
manually in your image.

One thing I'm interested in the choice of LRUCache over Dictionary for
the cache?  Did you find Dictionary was taking too much space?

I didn't try implementing the above yet, but I guessing you'll get the
performance fix while maintaining the flexibility you want.

cheers -ben

> Another problem is the scaling of images, really bad with morphic though
> Athens must be better.
>
> Auto completion problems are well knows, sometimes autocompletion does not
> show all methods, sometimes autocompletion shows every character you type so
> for example ChronosManager open will show
> ChronosManager o
> ChronosManager op
> ChronosManager ope
> ChronosManager open
>
> Sometimes it shows methods that do not even belong to the class forcing me
> to use Spotter to find the correct method. Its a a mess.
>
> I am not abandoning pharo, I love it even with its flaws. But I try to
> outsource as much as I can my workflow from pharo to external libraries and
> apps that are way more mature and efficient for what I am trying to do.
>
> I always inteded to make Blender work with Pharo, I accomplished that now I
> want to make Unreal engine to work with pharo, so I can make a triangle of
> love, Blender for asset creation, Unreal for real time rendering of 2d and
> 3d graphics , Pharo as the brain of the logic and advanced 

[Pharo-users] Nautilus code critic panel non functional

[Dimitris Chloupis]

Used to work ok, now with the latest pharo 5 image its just seem to scan
forever with no results

relevant bug report

https://pharo.fogbugz.com/f/cases/17401/

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

[Stephan Eggermont]

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

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

[Denis Kudriashov]

Hi.

I am not understand why you need to load images on startup? Why you not
save pharo image with preloaded png files?
With that case you will get immediate startup with ready to use forms.

Best regards,
Denis
16 янв. 2016 г. 14:50 пользователь "Dimitris Chloupis" <
kilon.al...@gmail.com> написал:

> 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 
> wrote:
>
>>
>>
>> 2016-01-16 13:50 GMT+01:00 Dimitris Chloupis :
>>
>>> 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"
>>
>

Re: [Pharo-users] Morphic is super slow

[Dimitris Chloupis]

Esteban I also get doSemantics: errors , I have been getting way way back
before Spur while trying to use shortcuts. It was messing also with the
rendering of the method list in Nautilus when there were too many methods,
it turned to a red box of death. So I am not convinced my problem are just
VM related but you can correct me if I am wrong.

On Sat, Jan 16, 2016 at 12:41 PM Esteban Lorenzano 
wrote:

> On 16 Jan 2016, at 11:27, Dimitris Chloupis  wrote:
>
> yes thanks Esteban I am back to Pharo 4 and I am fine :)
>
>
> you do not need to go back to Pharo 4… just downloading stable VM is
> enough :)
> (and I need people helping me to find the bugs on Pharo 5, spur, FFI, etc.
> *before* release :P)
>
> cheers,
> Esteban
>
>
> will stick with it, till the release of Pharo 5.
>
> On Sat, Jan 16, 2016 at 12:25 PM Esteban Lorenzano 
> wrote:
>
>> On 16 Jan 2016, at 01:01, Dimitris Chloupis 
>> wrote:
>>
>> 
>>
>> and by the way menus on latest pharo 5 are broken
>>
>>
>> not the menus
>> there is a problem with WideString and string primitives in latest spur
>> vm.
>> in the mean time you can download stable instead latest and you will be
>> ok.
>>
>> Esteban
>>
>>
>>
>> On Sat, Jan 16, 2016 at 1:29 AM Nicolai Hess 
>> wrote:
>>
>>> 2016-01-16 0:11 GMT+01:00 Nicolai Hess :
>>>


 2016-01-16 0:06 GMT+01:00 Sven Van Caekenberghe :

>
> > On 15 Jan 2016, at 23:30, Dimitris Chloupis 
> wrote:
> >
> > taskbar was the problem, damn pharo gui is a huge pain in the hat.
>
> How so ?
>

 I would like to now that too.

 Btw, this is interesting too:

 WorldState debugShowDamage:true.

 And look all the flashing in a nautilus and or playground window.

>>>
>>> Hm, I think this was my fault. The fix for
>>> 17201
>>> 
>>> Marking Diffs broken in Pharo5
>>> wasn't good.
>>>
>>>
>>>
>>>


>
> > On Fri, Jan 15, 2016 at 11:32 PM Dimitris Chloupis <
> kilon.al...@gmail.com> wrote:
> > ITs not the step, I removed the step as I said in my first post.
> Still 30% cpu consumption
> >
> > The images are PNGs and RGBA , 8bit
> >
> >
> > On Fri, Jan 15, 2016 at 10:54 PM Hilaire  wrote:
> > It depends on what you are doing in a step, but 1s step should not
> hurt.
> > May be the problem is somewhere else.
> > With DrGeo, I noted Athens is faster to BitBlt with bitmap operations
> > (in my case, only scaling and displaying a From in a DrGeo canvas).
> > Also, do your bitmaps come with 32 bits depth?
> >
> > --
> > Dr. Geo
> > http://drgeo.eu
> >
> >
> >
>
>
>
 ​
>>
>>

Re: [Pharo-users] Morphic is super slow

[Esteban Lorenzano]

yes, there is a problem in the cleanup of freetype fonts. 
that’s not a vm bug, but it started to happen very often after migrating.

Is in my high priority TODO list, right after a couple of FFI tweaks :S

Esteban

> On 16 Jan 2016, at 11:54, Dimitris Chloupis  wrote:
> 
> 
> ok if I open a nautilus window and then I save the image , it does not create 
> this error 
> 
> o_O
> 
> crazy stuff 
> 
> :D
> 
> On Sat, Jan 16, 2016 at 12:51 PM Dimitris Chloupis  > wrote:
> 
> 
> yes even with stable VM is a mess, new problem 
> 
> I got pharo with this
> 
> wget -O- get.pharo.org/alpha+vm  | bash
> 
> downloads fines, loads my libraries fine with my startup script as soon as i 
> try to save the image the above happens
> 
> 
> 
> 
> On Sat, Jan 16, 2016 at 12:43 PM Dimitris Chloupis  > wrote:
> Esteban I also get doSemantics: errors , I have been getting way way back 
> before Spur while trying to use shortcuts. It was messing also with the 
> rendering of the method list in Nautilus when there were too many methods, it 
> turned to a red box of death. So I am not convinced my problem are just VM 
> related but you can correct me if I am wrong.  
> 
> On Sat, Jan 16, 2016 at 12:41 PM Esteban Lorenzano  > wrote:
>> On 16 Jan 2016, at 11:27, Dimitris Chloupis > > wrote:
>> 
>> yes thanks Esteban I am back to Pharo 4 and I am fine :) 
> 
> you do not need to go back to Pharo 4… just downloading stable VM is enough :)
> (and I need people helping me to find the bugs on Pharo 5, spur, FFI, etc. 
> *before* release :P)
> 
> cheers,
> Esteban
> 
>> 
>> will stick with it, till the release of Pharo 5. 
>> 
>> On Sat, Jan 16, 2016 at 12:25 PM Esteban Lorenzano > > wrote:
>>> On 16 Jan 2016, at 01:01, Dimitris Chloupis >> > wrote:
>>> 
>>> 
>>> 
>>> and by the way menus on latest pharo 5 are broken 
>> 
>> not the menus
>> there is a problem with WideString and string primitives in latest spur vm. 
>> in the mean time you can download stable instead latest and you will be ok.
>> 
>> Esteban
>> 
>>> 
>>> 
>>> On Sat, Jan 16, 2016 at 1:29 AM Nicolai Hess >> > wrote:
>>> 2016-01-16 0:11 GMT+01:00 Nicolai Hess >> >:
>>> 
>>> 
>>> 2016-01-16 0:06 GMT+01:00 Sven Van Caekenberghe >> >:
>>> 
>>> > On 15 Jan 2016, at 23:30, Dimitris Chloupis >> > > wrote:
>>> >
>>> > taskbar was the problem, damn pharo gui is a huge pain in the hat.
>>> 
>>> How so ?
>>> 
>>> I would like to now that too.
>>> 
>>> Btw, this is interesting too:
>>> 
>>> WorldState debugShowDamage:true.
>>> 
>>> And look all the flashing in a nautilus and or playground window.
>>> 
>>> Hm, I think this was my fault. The fix for
>>> 17201 
>>>  
>>> Marking Diffs broken in Pharo5
>>> wasn't good.
>>> 
>>> 
>>>  
>>>  
>>> 
>>> > On Fri, Jan 15, 2016 at 11:32 PM Dimitris Chloupis >> > > wrote:
>>> > ITs not the step, I removed the step as I said in my first post. Still 
>>> > 30% cpu consumption
>>> >
>>> > The images are PNGs and RGBA , 8bit
>>> >
>>> >
>>> > On Fri, Jan 15, 2016 at 10:54 PM Hilaire >> > > wrote:
>>> > It depends on what you are doing in a step, but 1s step should not hurt.
>>> > May be the problem is somewhere else.
>>> > With DrGeo, I noted Athens is faster to BitBlt with bitmap operations
>>> > (in my case, only scaling and displaying a From in a DrGeo canvas).
>>> > Also, do your bitmaps come with 32 bits depth?
>>> >
>>> > --
>>> > Dr. Geo
>>> > http://drgeo.eu 
>>> >
>>> >
>>> >
>>> 
>>> 
>>> 
>>> ​

Re: [Pharo-users] Morphic is super slow

[Esteban Lorenzano]

> On 16 Jan 2016, at 11:59, Dimitris Chloupis  wrote:
> 
> syntax highlighting does not work, critics its keep looping forever with 
> "Updating critics..." message. I have to minimise and restore the nautlius 
> window to get back syntax highlighting for one method then the next method i 
> have to do the same. 

syntax highlighting is because there is a new somekind experimental AST based 
highlighter. 
We want to finish it, but we’ll see…

Esteban

> 
> Big Nope
> 
> Back I go to Pharo 4. Pharo 5 simply does not like me :D 
> 
> On Sat, Jan 16, 2016 at 12:54 PM Dimitris Chloupis  > wrote:
> 
> ok if I open a nautilus window and then I save the image , it does not create 
> this error 
> 
> o_O
> 
> crazy stuff 
> 
> :D
> 
> On Sat, Jan 16, 2016 at 12:51 PM Dimitris Chloupis  > wrote:
> 
> 
> yes even with stable VM is a mess, new problem 
> 
> I got pharo with this
> 
> wget -O- get.pharo.org/alpha+vm  | bash
> 
> downloads fines, loads my libraries fine with my startup script as soon as i 
> try to save the image the above happens
> 
> 
> 
> 
> On Sat, Jan 16, 2016 at 12:43 PM Dimitris Chloupis  > wrote:
> Esteban I also get doSemantics: errors , I have been getting way way back 
> before Spur while trying to use shortcuts. It was messing also with the 
> rendering of the method list in Nautilus when there were too many methods, it 
> turned to a red box of death. So I am not convinced my problem are just VM 
> related but you can correct me if I am wrong.  
> 
> On Sat, Jan 16, 2016 at 12:41 PM Esteban Lorenzano  > wrote:
>> On 16 Jan 2016, at 11:27, Dimitris Chloupis > > wrote:
>> 
>> yes thanks Esteban I am back to Pharo 4 and I am fine :) 
> 
> you do not need to go back to Pharo 4… just downloading stable VM is enough :)
> (and I need people helping me to find the bugs on Pharo 5, spur, FFI, etc. 
> *before* release :P)
> 
> cheers,
> Esteban
> 
>> 
>> will stick with it, till the release of Pharo 5. 
>> 
>> On Sat, Jan 16, 2016 at 12:25 PM Esteban Lorenzano > > wrote:
>>> On 16 Jan 2016, at 01:01, Dimitris Chloupis >> > wrote:
>>> 
>>> 
>>> 
>>> and by the way menus on latest pharo 5 are broken 
>> 
>> not the menus
>> there is a problem with WideString and string primitives in latest spur vm. 
>> in the mean time you can download stable instead latest and you will be ok.
>> 
>> Esteban
>> 
>>> 
>>> 
>>> On Sat, Jan 16, 2016 at 1:29 AM Nicolai Hess >> > wrote:
>>> 2016-01-16 0:11 GMT+01:00 Nicolai Hess >> >:
>>> 
>>> 
>>> 2016-01-16 0:06 GMT+01:00 Sven Van Caekenberghe >> >:
>>> 
>>> > On 15 Jan 2016, at 23:30, Dimitris Chloupis >> > > wrote:
>>> >
>>> > taskbar was the problem, damn pharo gui is a huge pain in the hat.
>>> 
>>> How so ?
>>> 
>>> I would like to now that too.
>>> 
>>> Btw, this is interesting too:
>>> 
>>> WorldState debugShowDamage:true.
>>> 
>>> And look all the flashing in a nautilus and or playground window.
>>> 
>>> Hm, I think this was my fault. The fix for
>>> 17201 
>>>  
>>> Marking Diffs broken in Pharo5
>>> wasn't good.
>>> 
>>> 
>>>  
>>>  
>>> 
>>> > On Fri, Jan 15, 2016 at 11:32 PM Dimitris Chloupis >> > > wrote:
>>> > ITs not the step, I removed the step as I said in my first post. Still 
>>> > 30% cpu consumption
>>> >
>>> > The images are PNGs and RGBA , 8bit
>>> >
>>> >
>>> > On Fri, Jan 15, 2016 at 10:54 PM Hilaire >> > > wrote:
>>> > It depends on what you are doing in a step, but 1s step should not hurt.
>>> > May be the problem is somewhere else.
>>> > With DrGeo, I noted Athens is faster to BitBlt with bitmap operations
>>> > (in my case, only scaling and displaying a From in a DrGeo canvas).
>>> > Also, do your bitmaps come with 32 bits depth?
>>> >
>>> > --
>>> > Dr. Geo
>>> > http://drgeo.eu 
>>> >
>>> >
>>> >
>>> 
>>> 
>>> 
>>> ​

Re: [Pharo-users] Morphic is super slow

[Dimitris Chloupis]

If there is anything I can do to help you out dont hesitate to ask.

I tried to improve auto completion but I have to confess after 30 hours of
work I could not figure out how things really worked. So I gave up and went
back to coding my own stuff.

On Sat, Jan 16, 2016 at 1:39 PM stepharo  wrote:

>
> >> syntax highlighting does not work, critics its keep looping forever
> >> with "Updating critics..." message. I have to minimise and restore
> >> the nautlius window to get back syntax highlighting for one method
> >> then the next method i have to do the same.
> >
> > syntax highlighting is because there is a new somekind experimental
> > AST based highlighter.
>
> What would be nice is that when we push something in the release there
> is a real support behind.
> It took us three months of work with frank to get rubric used. Then the
> last glitches are just because
> we do not want syntax hi in certain parts.
>
> Stef
> > We want to finish it, but we’ll see…
> >
> > Esteban
> >
>
>
>

Re: [Pharo-users] Morphic is super slow

[Marcus Denker]

> On 16 Jan 2016, at 12:38, stepharo  wrote:
> 
> 
>>> syntax highlighting does not work, critics its keep looping forever with 
>>> "Updating critics..." message. I have to minimise and restore the nautlius 
>>> window to get back syntax highlighting for one method then the next method 
>>> i have to do the same.
>> 
>> syntax highlighting is because there is a new somekind experimental AST 
>> based highlighter.
> 
> What would be nice is that when we push something in the release there is a 
> real support behind.
> It took us three months of work with frank to get rubric used. Then the last 
> glitches are just because
> we do not want syntax hi in certain parts.
> 
Slow syntax highlighting is not due to the new one but due to changes related 
to rubric.

It gets a bit hard to follow these discussions…. could people not instead use 
their time and 
energy to add issue tracker entries and (especially) comment on existing ones?

Marcus

Re: [Pharo-users] Morphic is super slow

[Ben Coman]

On Sat, Jan 16, 2016 at 8:43 PM, Dimitris Chloupis
 wrote:
> Hello Ben with your help and some more digging around I managed to solve my
> issues and I am now also able to update the taskbar button moprh without any
> major hit to my cpu. Pharo is now at 6-7% of one core which is not bad at
> all.
>
> So what you mention does not seem to affect my performance. However there is
> still the problem of ChronoManager taking over a second to open its gui .

That profile report didn't format very well. Probably better to put it
in a text file to attach.
let me know when you've updated the catalog and I'll take another look.

cheers -ben

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

[Dimitris Chloupis]

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  wrote:

>
>
> 2016-01-16 13:50 GMT+01:00 Dimitris Chloupis :
>
>> 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"
>

Re: [Pharo-users] Morphic is super slow

[stepharo]

syntax highlighting does not work, critics its keep looping forever 
with "Updating critics..." message. I have to minimise and restore 
the nautlius window to get back syntax highlighting for one method 
then the next method i have to do the same.


syntax highlighting is because there is a new somekind experimental 
AST based highlighter.


What would be nice is that when we push something in the release there 
is a real support behind.
It took us three months of work with frank to get rubric used. Then the 
last glitches are just because

we do not want syntax hi in certain parts.

Stef

We want to finish it, but we’ll see…

Esteban

[Pharo-users] Pharo Sound does not work on Pharo 4

[Dimitris Chloupis]

even though it works fine for me in Pharo 5 (with the exception I have to
restart the sound player because the primitive fails at times) in Pharo 4 I
have no sound and no errors. Just Silence of the Lamps.

opened bug report

https://pharo.fogbugz.com/f/cases/17402/Pharo-Sound-does-not-work-on-Pharo-4

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

[Dimitris Chloupis]

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

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

[Dimitris Chloupis]

Images are needed on startup when the project is updated which means any of
the image files could change.

Its a big problem for me , I can preload everything, save it to an image
and distribute the image instead with zero delays. I dont care if this is
going to be improved or not , since I can work around this limitation.

I was merely reporting the creating forms from pngs is too slow.

On Sat, Jan 16, 2016 at 4:07 PM Denis Kudriashov 
wrote:

> Hi.
>
> I am not understand why you need to load images on startup? Why you not
> save pharo image with preloaded png files?
> With that case you will get immediate startup with ready to use forms.
>
> Best regards,
> Denis
> 16 янв. 2016 г. 14:50 пользователь "Dimitris Chloupis" <
> kilon.al...@gmail.com> написал:
>
> 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 
>> wrote:
>>
>>>
>>>
>>> 2016-01-16 13:50 GMT+01:00 Dimitris Chloupis :
>>>
 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"
>>>
>>

Re: [Pharo-users] Morphic is super slow

[Dimitris Chloupis]

Yeap I cannot wait for Bloc :)

a big thanks to Alain, Bloc already looks amazing from the little I tried.
I am sure the loading of PNGs will be optimised at some point too in the
future. Everything is a matter of time.

Stef see my previous posts to see what was the issue but that summary is
that I copied a method from SystemWindow which apparently was not optimized
and was creation a new morph each cycle for a taskbar button.

On Sat, Jan 16, 2016 at 10:08 AM stepharo  wrote:

>
> taskbar was the problem,
>
> what was it?
>
> damn pharo gui is a huge pain in the hat.
>
> And we improved it a lot already.
> But this is not by accident that Alain spent a couple of years working on
> Bloc
>
>
> On Fri, Jan 15, 2016 at 11:32 PM Dimitris Chloupis 
> wrote:
>
>> ITs not the step, I removed the step as I said in my first post. Still
>> 30% cpu consumption
>>
>> The images are PNGs and RGBA , 8bit
>>
>>
>> On Fri, Jan 15, 2016 at 10:54 PM Hilaire  wrote:
>>
>>> It depends on what you are doing in a step, but 1s step should not hurt.
>>> May be the problem is somewhere else.
>>> With DrGeo, I noted Athens is faster to BitBlt with bitmap operations
>>> (in my case, only scaling and displaying a From in a DrGeo canvas).
>>> Also, do your bitmaps come with 32 bits depth?
>>>
>>> --
>>> Dr. Geo
>>> http://drgeo.eu
>>>
>>>
>>>
>>>
>

Re: [Pharo-users] Morphic is super slow

[Esteban Lorenzano]

> On 16 Jan 2016, at 11:27, Dimitris Chloupis  wrote:
> 
> yes thanks Esteban I am back to Pharo 4 and I am fine :) 

you do not need to go back to Pharo 4… just downloading stable VM is enough :)
(and I need people helping me to find the bugs on Pharo 5, spur, FFI, etc. 
*before* release :P)

cheers,
Esteban

> 
> will stick with it, till the release of Pharo 5. 
> 
> On Sat, Jan 16, 2016 at 12:25 PM Esteban Lorenzano  > wrote:
>> On 16 Jan 2016, at 01:01, Dimitris Chloupis > > wrote:
>> 
>> 
>> 
>> and by the way menus on latest pharo 5 are broken 
> 
> not the menus
> there is a problem with WideString and string primitives in latest spur vm. 
> in the mean time you can download stable instead latest and you will be ok.
> 
> Esteban
> 
>> 
>> 
>> On Sat, Jan 16, 2016 at 1:29 AM Nicolai Hess > > wrote:
>> 2016-01-16 0:11 GMT+01:00 Nicolai Hess > >:
>> 
>> 
>> 2016-01-16 0:06 GMT+01:00 Sven Van Caekenberghe > >:
>> 
>> > On 15 Jan 2016, at 23:30, Dimitris Chloupis > > > wrote:
>> >
>> > taskbar was the problem, damn pharo gui is a huge pain in the hat.
>> 
>> How so ?
>> 
>> I would like to now that too.
>> 
>> Btw, this is interesting too:
>> 
>> WorldState debugShowDamage:true.
>> 
>> And look all the flashing in a nautilus and or playground window.
>> 
>> Hm, I think this was my fault. The fix for
>> 17201 
>>  
>> Marking Diffs broken in Pharo5
>> wasn't good.
>> 
>> 
>>  
>>  
>> 
>> > On Fri, Jan 15, 2016 at 11:32 PM Dimitris Chloupis > > > wrote:
>> > ITs not the step, I removed the step as I said in my first post. Still 30% 
>> > cpu consumption
>> >
>> > The images are PNGs and RGBA , 8bit
>> >
>> >
>> > On Fri, Jan 15, 2016 at 10:54 PM Hilaire > > > wrote:
>> > It depends on what you are doing in a step, but 1s step should not hurt.
>> > May be the problem is somewhere else.
>> > With DrGeo, I noted Athens is faster to BitBlt with bitmap operations
>> > (in my case, only scaling and displaying a From in a DrGeo canvas).
>> > Also, do your bitmaps come with 32 bits depth?
>> >
>> > --
>> > Dr. Geo
>> > http://drgeo.eu 
>> >
>> >
>> >
>> 
>> 
>> 
>> ​

Re: [Pharo-users] Morphic is super slow

[Dimitris Chloupis]

my bad Marcus

done

https://pharo.fogbugz.com/f/cases/16020/Syntax-Highlighting-Rubric-First-shows-non-highlighted-text-then-color-Looks-slow

and

https://pharo.fogbugz.com/f/cases/17401/Nautilus-code-critic-seem-not-working




On Sat, Jan 16, 2016 at 2:03 PM Marcus Denker 
wrote:

>
> > On 16 Jan 2016, at 12:38, stepharo  wrote:
> >
> >
> >>> syntax highlighting does not work, critics its keep looping forever
> with "Updating critics..." message. I have to minimise and restore the
> nautlius window to get back syntax highlighting for one method then the
> next method i have to do the same.
> >>
> >> syntax highlighting is because there is a new somekind experimental AST
> based highlighter.
> >
> > What would be nice is that when we push something in the release there
> is a real support behind.
> > It took us three months of work with frank to get rubric used. Then the
> last glitches are just because
> > we do not want syntax hi in certain parts.
> >
> Slow syntax highlighting is not due to the new one but due to changes
> related to rubric.
>
> It gets a bit hard to follow these discussions…. could people not instead
> use their time and
> energy to add issue tracker entries and (especially) comment on existing
> ones?
>
> Marcus
>
>
>

Re: [Pharo-users] Morphic is super slow

[Dimitris Chloupis]

Hello Ben with your help and some more digging around I managed to solve my
issues and I am now also able to update the taskbar button moprh without
any major hit to my cpu. Pharo is now at 6-7% of one core which is not bad
at all.

So what you mention does not seem to affect my performance. However there
is still the problem of ChronoManager taking over a second to open its gui
.

The problem with the loading of image is purely on how PNG are loaded.

For example if I profile

ChronosManager open

I get 1241 for my the initialisation of the class out of this 800ms are
wasted just loading the pngs with this summary

48.8% {794ms} Form class>>fromFileNamed: | 47.9% {779ms} Form
class>>fromBinaryStream: | 47.9% {779ms} ImageReadWriter
class>>formFromStream: | 47.9% {779ms} PNGReadWriter>>nextImage | 47.6%
{774ms} PNGReadWriter>>processIDATChunk | 47.2% {768ms}
PNGReadWriter>>processNonInterlaced | 32.9% {536ms}
PNGReadWriter>>filterScanline:count: | |28.0% {456ms}
PNGReadWriter>>filterPaeth: | | |15.4% {250ms}
PNGReadWriter>>paethPredictLeft:above:aboveLeft: | | |12.6% {205ms}
primitives

Reading the full report is clear that a major hit is how pharo tries to
compile the png to a form.

full report

1624 tallies, 1626 msec. **Tree**  Process:
other processes  15.1% {246ms}
InputEventFetcher>>eventLoop 15.1% {246ms} InputEventFetcher>>waitForInput
8.6% {139ms} SoundPlayer class>>playLoop 8.3% {134ms} primitives
 Process: (40s) Morphic UI Process: nil
 76.3% {1241ms} ChronosManager
class(Behavior)>>new 76.3% {1241ms} ChronosManager>>initialize 76.3%
{1241ms} ChrGUIMorph class(Behavior)>>new 76.3% {1241ms}
ChrGUIMorph>>initialize 48.8% {794ms} ChrGUIMorph>>secondsTimerForm |48.8%
{794ms} Form class>>fromFileNamed: | 47.9% {779ms} Form
class>>fromBinaryStream: | 47.9% {779ms} ImageReadWriter
class>>formFromStream: | 47.9% {779ms} PNGReadWriter>>nextImage | 47.6%
{774ms} PNGReadWriter>>processIDATChunk | 47.2% {768ms}
PNGReadWriter>>processNonInterlaced | 32.9% {536ms}
PNGReadWriter>>filterScanline:count: | |28.0% {456ms}
PNGReadWriter>>filterPaeth: | | |15.4% {250ms}
PNGReadWriter>>paethPredictLeft:above:aboveLeft: | | |12.6% {205ms}
primitives | |2.8% {46ms} PNGReadWriter>>filterHorizontal: | |1.6% {26ms}
PNGReadWriter>>filterVertical: | 7.0% {113ms}
ZLibReadStream(InflateStream)>>next:into:startingAt: | |7.0% {113ms}
ZLibReadStream(InflateStream)>>next | | 7.0% {113ms}
ZLibReadStream(InflateStream)>>pastEndRead | | 4.7% {76ms}
ZLibReadStream(InflateStream)>>next | | 1.9% {31ms}
ZLibReadStream(InflateStream)>>bitPosition | 3.0% {49ms} primitives | 2.6%
{43ms} ZLibReadStream(InflateStream)>>next | |2.6% {43ms}
ZLibReadStream(InflateStream)>>pastEndRead | | 1.7% {28ms}
ZLibReadStream(InflateStream)>>next | 1.2% {19ms}
PNGReadWriter>>copyPixelsRGBA: 21.1% {342ms} ChrStopwatchPanelM
class(Behavior)>>new |21.1% {342ms} ChrStopwatchPanelM>>initialize | 3.0%
{48ms} ChrStopwatchSettingsPNG>>stopwatchSecondaryPanelIcon | |2.3% {37ms}
Form class>>fromBinaryStream: | | 2.3% {37ms} ImageReadWriter
class>>formFromStream: | | 2.3% {37ms} PNGReadWriter>>nextImage | | 2.3%
{37ms} PNGReadWriter>>processIDATChunk | | 2.3% {37ms}
PNGReadWriter>>processNonInterlaced | | 2.0% {33ms}
PNGReadWriter>>filterScanline:count: | | 1.9% {31ms}
PNGReadWriter>>filterPaeth: | | 1.1% {18ms} primitives | 2.8% {46ms}
ChrStopwatchPanelM>>prepareStopwatchButton | |2.7% {44ms} ChrSwitchButtonM
class>>createWithAction: | | 2.7% {44ms} ChrSwitchButtonM
class(Behavior)>>new | | 2.7% {44ms} ChrSwitchButtonM>>initialize | | 2.6%
{42ms} ChronosManager class>>defaultFont | | 2.6% {42ms} ChronosManager
class>>defaultFontPointSize: | | 2.3% {38ms}
FileReference(AbstractFileReference)>>allDirectories | | 2.3% {38ms}
SelectVisitor class>>breadthFirst:select: | | 2.3% {38ms}
SelectVisitor(AbstractEnumerationVisitor)>>breadthFirst: | | 2.3% {38ms}
SelectVisitor(AbstractEnumerationVisitor)>>visit:with: | | 2.3% {38ms}
BreadthFirstGuide>>show: | | 2.3% {38ms} BreadthFirstGuide>>visitNextEntry:
| | 2.3% {38ms} FileReference>>entries | | 2.3% {38ms}
FileSystem>>entriesAt: | | 2.3% {38ms} FileSystem>>entriesAt:do: | | 2.3%
{38ms} FileSystem>>entriesAt:ifAbsent:do: | | 2.0% {33ms}
MacStore(FileSystemStore)>>directoryAt:ifAbsent:nodesDo: | | 1.8% {29ms}
MacStore(DiskStore)>>basicEntry:path:nodesDo: | | 1.6% {26ms} primitives |
2.8% {45ms} ChrStopwatchPanelM>>prepareHelpLabel | |2.8% {45ms}
ChronosManager class>>defaultFontPointSize: | | 2.3% {38ms}
FileReference(AbstractFileReference)>>allDirectories | | 2.3% {38ms}
SelectVisitor class>>breadthFirst:select: | | 2.3% {38ms}
SelectVisitor(AbstractEnumerationVisitor)>>breadthFirst: | | 2.3% {38ms}
SelectVisitor(AbstractEnumerationVisitor)>>visit:with: | | 2.3% {38ms}
BreadthFirstGuide>>show: | | 2.3% {38ms} BreadthFirstGuide>>visitNextEntry:
| | 2.3% {38ms} FileReference>>entries | | 2.3% {38ms}

Re: [Pharo-users] Morphic is super slow

[Marcus Denker]

and this is all fixed by 
https://pharo.fogbugz.com/f/cases/17201/Marking-Diffs-broken-in-Pharo5


> On 16 Jan 2016, at 13:55, Henrik Nergaard  wrote:
> 
> Both the syntax highlighting and critics run their own background process to 
> do work.
> The general Morphic UI runs at priority 40, critics at 39 and 30.
> This means that highlighting will not be computed before the critics have 
> finished evaluating, and if there is too much work in the UI thread both of 
> these will take forever.
>  
> Best regards,
> Henrik
>  
>  
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org 
> ] On Behalf Of Dimitris Chloupis
> Sent: Saturday, January 16, 2016 12:00 PM
> To: Any question about pharo is welcome  >
> Subject: Re: [Pharo-users] Morphic is super slow
>  
> syntax highlighting does not work, critics its keep looping forever with 
> "Updating critics..." message. I have to minimise and restore the nautlius 
> window to get back syntax highlighting for one method then the next method i 
> have to do the same. 
> 
> Big Nope
> 
> Back I go to Pharo 4. Pharo 5 simply does not like me :D 
>  
> On Sat, Jan 16, 2016 at 12:54 PM Dimitris Chloupis  > wrote:
>  
> ok if I open a nautilus window and then I save the image , it does not create 
> this error
> 
> o_O
> 
> crazy stuff 
> 
> :D
>  
> On Sat, Jan 16, 2016 at 12:51 PM Dimitris Chloupis  > wrote:
> 
> 
> yes even with stable VM is a mess, new problem 
> 
> I got pharo with this
> 
> wget -O- get.pharo.org/alpha+vm  | bash
> 
> downloads fines, loads my libraries fine with my startup script as soon as i 
> try to save the image the above happens
> 
> 
> 
>  
> On Sat, Jan 16, 2016 at 12:43 PM Dimitris Chloupis  > wrote:
> Esteban I also get doSemantics: errors , I have been getting way way back 
> before Spur while trying to use shortcuts. It was messing also with the 
> rendering of the method list in Nautilus when there were too many methods, it 
> turned to a red box of death. So I am not convinced my problem are just VM 
> related but you can correct me if I am wrong. 
>  
> On Sat, Jan 16, 2016 at 12:41 PM Esteban Lorenzano  > wrote:
> On 16 Jan 2016, at 11:27, Dimitris Chloupis  > wrote:
>  
> yes thanks Esteban I am back to Pharo 4 and I am fine :) 
>  
> you do not need to go back to Pharo 4… just downloading stable VM is enough :)
> (and I need people helping me to find the bugs on Pharo 5, spur, FFI, etc. 
> *before* release :P)
>  
> cheers,
> Esteban
> 
> 
>  
> will stick with it, till the release of Pharo 5. 
>  
> On Sat, Jan 16, 2016 at 12:25 PM Esteban Lorenzano  > wrote:
> On 16 Jan 2016, at 01:01, Dimitris Chloupis  > wrote:
>  
> 
> 
> and by the way menus on latest pharo 5 are broken 
>  
> not the menus
> there is a problem with WideString and string primitives in latest spur vm. 
> in the mean time you can download stable instead latest and you will be ok.
>  
> Esteban
> 
> 
>  
> 
> On Sat, Jan 16, 2016 at 1:29 AM Nicolai Hess  > wrote:
> 2016-01-16 0:11 GMT+01:00 Nicolai Hess  >:
>  
>  
> 2016-01-16 0:06 GMT+01:00 Sven Van Caekenberghe  >:
> 
> > On 15 Jan 2016, at 23:30, Dimitris Chloupis  > > wrote:
> >
> > taskbar was the problem, damn pharo gui is a huge pain in the hat.
> 
> How so ?
>  
> I would like to now that too.
> 
> Btw, this is interesting too:
> 
> WorldState debugShowDamage:true.
> 
> And look all the flashing in a nautilus and or playground window.
>  
> Hm, I think this was my fault. The fix for
> 17201 
>  
> Marking Diffs broken in Pharo5
> wasn't good.
> 
> 
>  
>  
> 
> > On Fri, Jan 15, 2016 at 11:32 PM Dimitris Chloupis  > > wrote:
> > ITs not the step, I removed the step as I said in my first post. Still 30% 
> > cpu consumption
> >
> > The images are PNGs and RGBA , 8bit
> >
> >
> > On Fri, Jan 15, 2016 at 10:54 PM Hilaire  > > wrote:
> > It depends on what you are doing in a step, but 1s step should not hurt.
> > May be the problem is somewhere else.
> > With DrGeo, I noted Athens is faster to BitBlt with bitmap operations
> > (in my case, only scaling and displaying a From in a DrGeo 

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

[Nicolai Hess]

2016-01-16 13:50 GMT+01:00 Dimitris Chloupis :

> 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"


delay_image_loading.cs
Description: Binary data

Re: [Pharo-users] Morphic is super slow

[Dimitris Chloupis]

there is no need to update the catalog, my project is in github and catalog
always loads the latest github version .

One of the advantages of using github ;)

and any change I do my code is immediately commited and pushed into github.

On Sat, Jan 16, 2016 at 3:37 PM Ben Coman  wrote:

> On Sat, Jan 16, 2016 at 8:43 PM, Dimitris Chloupis
>  wrote:
> > Hello Ben with your help and some more digging around I managed to solve
> my
> > issues and I am now also able to update the taskbar button moprh without
> any
> > major hit to my cpu. Pharo is now at 6-7% of one core which is not bad at
> > all.
> >
> > So what you mention does not seem to affect my performance. However
> there is
> > still the problem of ChronoManager taking over a second to open its gui .
>
> That profile report didn't format very well. Probably better to put it
> in a text file to attach.
> let me know when you've updated the catalog and I'll take another look.
>
> cheers -ben
>
>

Re: [Pharo-users] Morphic is super slow

[Ben Coman]

Okay. So I haven't with git from Pharo before.  What definite actions
do I need to take to update?

I see the github://kilon/ChronosManager:master repository only contains:
* one BaselineOfChronosManager.package revision 4, which is the current loaded
* one ChronosManager.package revision 62, which is the current loaded

How do I get those to show a later version that I can load?

Also, if I click on  for ChronosManager.package revision 62,
then from ChronosManager-kilonAlios.61 context menu I select  it gives an error: "Error: Could not find version
'ChronosManager-kilonAlios.61'. Maybe you need to add a repository?"
  Being familiar with git command line that is somewhat expected, but
could those more familiar with its usage in Pharo comment on this?

cheers -ben

On Sat, Jan 16, 2016 at 9:41 PM, Dimitris Chloupis
 wrote:
> there is no need to update the catalog, my project is in github and catalog
> always loads the latest github version .
>
> One of the advantages of using github ;)
>
> and any change I do my code is immediately commited and pushed into github.
>
> On Sat, Jan 16, 2016 at 3:37 PM Ben Coman  wrote:
>>
>> On Sat, Jan 16, 2016 at 8:43 PM, Dimitris Chloupis
>>  wrote:
>> > Hello Ben with your help and some more digging around I managed to solve
>> > my
>> > issues and I am now also able to update the taskbar button moprh without
>> > any
>> > major hit to my cpu. Pharo is now at 6-7% of one core which is not bad
>> > at
>> > all.
>> >
>> > So what you mention does not seem to affect my performance. However
>> > there is
>> > still the problem of ChronoManager taking over a second to open its gui
>> > .
>>
>> That profile report didn't format very well. Probably better to put it
>> in a text file to attach.
>> let me know when you've updated the catalog and I'll take another look.
>>
>> cheers -ben
>>
>

Re: [Pharo-users] Morphic is super slow

[Ben Coman]

Cool.
cheers -ben

On Sat, Jan 16, 2016 at 10:51 PM, Dimitris Chloupis
 wrote:
> Ben just leave it, dont waste your time, again 1.000.000 thank you for
> helping me out but i am just too tired of battling with lack of
> documentation and pharo limitations. I will port my project to Unreal engine
> and maybe I will keep pharo just for scripting , but then I doubt that
> because Unreal has an IDE not unlike Pharo and full live coding abilities
> even for C++ code.
>
> It was fun, time to move on. Big thank you to the community for helping me
> out and the awesome work they do on Pharo,  I will definetly be around
> monitoring the mailing list and keep making video tutorials for pharo,
> though less frequently.
>
> On Sat, Jan 16, 2016 at 4:45 PM Dimitris Chloupis 
> wrote:
>>
>> Ben is super simple with github, you just load it from package browser in
>> a clean image (it will always get the latest version) or if you want to get
>> the latest version on top of existing ChronosManager version , because
>> Package Browser has a problem that does not get the latest version when you
>> have one older version already loaded
>>
>> you do
>>
>> Metacello new baseline: 'ChronosManager'; repository:
>> 'github://kilon/ChronosManager'; get; load
>>
>>
>>
>> On Sat, Jan 16, 2016 at 4:25 PM Ben Coman  wrote:
>>>
>>> Okay. So I haven't with git from Pharo before.  What definite actions
>>> do I need to take to update?
>>>
>>> I see the github://kilon/ChronosManager:master repository only contains:
>>> * one BaselineOfChronosManager.package revision 4, which is the current
>>> loaded
>>> * one ChronosManager.package revision 62, which is the current loaded
>>>
>>> How do I get those to show a later version that I can load?
>>>
>>> Also, if I click on  for ChronosManager.package revision 62,
>>> then from ChronosManager-kilonAlios.61 context menu I select >> changes> it gives an error: "Error: Could not find version
>>> 'ChronosManager-kilonAlios.61'. Maybe you need to add a repository?"
>>>   Being familiar with git command line that is somewhat expected, but
>>> could those more familiar with its usage in Pharo comment on this?
>>>
>>> cheers -ben
>>>
>>> On Sat, Jan 16, 2016 at 9:41 PM, Dimitris Chloupis
>>>  wrote:
>>> > there is no need to update the catalog, my project is in github and
>>> > catalog
>>> > always loads the latest github version .
>>> >
>>> > One of the advantages of using github ;)
>>> >
>>> > and any change I do my code is immediately commited and pushed into
>>> > github.
>>> >
>>> > On Sat, Jan 16, 2016 at 3:37 PM Ben Coman  wrote:
>>> >>
>>> >> On Sat, Jan 16, 2016 at 8:43 PM, Dimitris Chloupis
>>> >>  wrote:
>>> >> > Hello Ben with your help and some more digging around I managed to
>>> >> > solve
>>> >> > my
>>> >> > issues and I am now also able to update the taskbar button moprh
>>> >> > without
>>> >> > any
>>> >> > major hit to my cpu. Pharo is now at 6-7% of one core which is not
>>> >> > bad
>>> >> > at
>>> >> > all.
>>> >> >
>>> >> > So what you mention does not seem to affect my performance. However
>>> >> > there is
>>> >> > still the problem of ChronoManager taking over a second to open its
>>> >> > gui
>>> >> > .
>>> >>
>>> >> That profile report didn't format very well. Probably better to put it
>>> >> in a text file to attach.
>>> >> let me know when you've updated the catalog and I'll take another
>>> >> look.
>>> >>
>>> >> cheers -ben
>>> >>
>>> >
>>>
>

Re: [Pharo-users] Spec: Populating a playground with a particular content (was Re: Spec: Binding widgets how to)

[Johan Fabry]

Ah this is actually a Glamour question: If I have a GTPlayground, how do I set 
its content programmatically? I have been able to do it with something like the 
following:

| play |
“play is the GTPlayground instance"
play := (GTPlayground new openOn: GTPlayPage new) model.
play entity saveContent: '42'.
play update.

I don’t know if this is the officially approved way of doing it, maybe the 
Glamour crew can enlighten us.

> On Jan 14, 2016, at 18:34, Nicolai Hess  wrote:
> 
> but if I try running the interface with this I get: "MessageNotUnderstood: 
> GlamourPresentationModel>>content:", so I think that something more is needed 
> to create Playgrounds in the Spec-Glamour that are pre-populated with content.
> 
> How can I create a playground inside a Spec-Glamour interface that is already 
> populated with a given content?
> 
> 
> I would expect (content is the GlamourPresentationModel)
> 
> content glmPres codePresentation text: 'new text'.
> 
> but it does not work.



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
Chile

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

[Esteban Lorenzano]

> On 16 Jan 2016, at 17:17, Dimitris Chloupis  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  > 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 > > 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 > > 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 > > wrote:
>> On 16-01-16 

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

[Dimitris Chloupis]

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 
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 
> 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
>>
>>
>>
>>

Re: [Pharo-users] Spec: Populating a playground with a particular content (was Re: Spec: Binding widgets how to)

[Tudor Girba]

Here is a simpler way:
GTPlayground new openOn: (GTPlayPage new content: '42’)

Cheers,
Doru

> On Jan 16, 2016, at 4:23 PM, Johan Fabry  wrote:
> 
> 
> Ah this is actually a Glamour question: If I have a GTPlayground, how do I 
> set its content programmatically? I have been able to do it with something 
> like the following:
> 
> | play |
> “play is the GTPlayground instance"
> play := (GTPlayground new openOn: GTPlayPage new) model.
> play entity saveContent: '42'.
> play update.
> 
> I don’t know if this is the officially approved way of doing it, maybe the 
> Glamour crew can enlighten us.
> 
>> On Jan 14, 2016, at 18:34, Nicolai Hess  wrote:
>> 
>> but if I try running the interface with this I get: "MessageNotUnderstood: 
>> GlamourPresentationModel>>content:", so I think that something more is 
>> needed to create Playgrounds in the Spec-Glamour that are pre-populated with 
>> content.
>> 
>> How can I create a playground inside a Spec-Glamour interface that is 
>> already populated with a given content?
>> 
>> 
>> I would expect (content is the GlamourPresentationModel)
>> 
>> content glmPres codePresentation text: 'new text'.
>> 
>> but it does not work.
> 
> 
> 
> ---> Save our in-boxes! http://emailcharter.org <---
> 
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
> Chile
> 

--
www.tudorgirba.com
www.feenk.com

"Problem solving efficiency grows with the abstractness level of problem 
understanding."

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

[Esteban Lorenzano]

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  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  > 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  > 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
> 
> 
> 

Re: [Pharo-users] Morphic is super slow

[Hilaire]

No it is ok as Pharo depth is also 32 bits

Hilaire


Le 16/01/2016 18:00, Dimitris Chloupis a écrit :
> ah yes you are correct is per channel, my bad. You think thats what
> slows pharo down ?

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Spec: Populating a playground with a particular content (was Re: Spec: Binding widgets how to)

[Johan Fabry]

Ah, sorry for the confusion, for the sake of the example I oversimplified 
things. Let’s say that I have a GTPlayground instance that has been around for 
some time, and then I want to change its content. What should I do?

| play |
“play is the GTPlayground instance"
play := (GTPlayground new openOn: GTPlayPage new) model.

“… lots of things happen … the world turns … sun and moon go up and down … "

play entity saveContent: '42'.
play update.

Still like this ?

> On Jan 16, 2016, at 12:27, Tudor Girba  wrote:
> 
> Here is a simpler way:
> GTPlayground new openOn: (GTPlayPage new content: '42’)
> 
> Cheers,
> Doru
> 
>> On Jan 16, 2016, at 4:23 PM, Johan Fabry  wrote:
>> 
>> 
>> Ah this is actually a Glamour question: If I have a GTPlayground, how do I 
>> set its content programmatically? I have been able to do it with something 
>> like the following:
>> 
>> | play |
>> “play is the GTPlayground instance"
>> play := (GTPlayground new openOn: GTPlayPage new) model.
>> play entity saveContent: '42'.
>> play update.
>> 
>> I don’t know if this is the officially approved way of doing it, maybe the 
>> Glamour crew can enlighten us.
>> 
>>> On Jan 14, 2016, at 18:34, Nicolai Hess  wrote:
>>> 
>>> but if I try running the interface with this I get: "MessageNotUnderstood: 
>>> GlamourPresentationModel>>content:", so I think that something more is 
>>> needed to create Playgrounds in the Spec-Glamour that are pre-populated 
>>> with content.
>>> 
>>> How can I create a playground inside a Spec-Glamour interface that is 
>>> already populated with a given content?
>>> 
>>> 
>>> I would expect (content is the GlamourPresentationModel)
>>> 
>>> content glmPres codePresentation text: 'new text'.
>>> 
>>> but it does not work.
>> 
>> 
>> 
>> ---> Save our in-boxes! http://emailcharter.org <---
>> 
>> Johan Fabry   -   http://pleiad.cl/~jfabry
>> PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
>> Chile
>> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Problem solving efficiency grows with the abstractness level of problem 
> understanding."
> 
> 
> 
> 
> 
> 



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
Chile

[Pharo-users] Pharo 5 new vm crash on window resize

[Johan Fabry]

Hi all,

this just happened to me: I opened a new image (today’s build), resized it and 
the VM segfaulted. I am on MacOS. crash.dmp is in attachment. I have been 
unable to reproduce, sadly. Is this a known issue or should I add a new bug 
report ?




crash.dmp
Description: Binary data


---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
Chile

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

[Dimitris Chloupis]

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 
wrote:

> On 16 Jan 2016, at 17:17, Dimitris Chloupis  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 
> 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 
>> 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 
>> 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 

Re: [Pharo-users] Spec: Populating a playground with a particular content (was Re: Spec: Binding widgets how to)

[Offray Vladimir Luna Cárdenas]

Hi,

I'm still kind of lost here. If I try with these approaches I get a 
*new* GTPlayground window populated with content, instead of an embedded 
one. How can I made this GTPlayPage one that is embedded in a spec 
glamour interface, like the one in the minimalist example: a dictionary 
with two keys/values: one which is shown as text and other that is shown 
as a playground, both populated with the content in the dict values and 
both, embedded in a widget instead of on separate windows. Is this 
possible with the current Spec-Glamour implementation?, if not how can 
be it extended to make this happen?


Thanks,

Offray

On 16/01/16 10:36, Johan Fabry wrote:

Ah, sorry for the confusion, for the sake of the example I oversimplified 
things. Let’s say that I have a GTPlayground instance that has been around for 
some time, and then I want to change its content. What should I do?

| play |
“play is the GTPlayground instance"
play := (GTPlayground new openOn: GTPlayPage new) model.

“… lots of things happen … the world turns … sun and moon go up and down … "

play entity saveContent: '42'.
play update.

Still like this ?


On Jan 16, 2016, at 12:27, Tudor Girba  wrote:

Here is a simpler way:
GTPlayground new openOn: (GTPlayPage new content: '42’)

Cheers,
Doru


On Jan 16, 2016, at 4:23 PM, Johan Fabry  wrote:


Ah this is actually a Glamour question: If I have a GTPlayground, how do I set 
its content programmatically? I have been able to do it with something like the 
following:

| play |
“play is the GTPlayground instance"
play := (GTPlayground new openOn: GTPlayPage new) model.
play entity saveContent: '42'.
play update.

I don’t know if this is the officially approved way of doing it, maybe the 
Glamour crew can enlighten us.


On Jan 14, 2016, at 18:34, Nicolai Hess  wrote:

but if I try running the interface with this I get: "MessageNotUnderstood: 
GlamourPresentationModel>>content:", so I think that something more is needed to 
create Playgrounds in the Spec-Glamour that are pre-populated with content.

How can I create a playground inside a Spec-Glamour interface that is already 
populated with a given content?


I would expect (content is the GlamourPresentationModel)

content glmPres codePresentation text: 'new text'.

but it does not work.



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
Chile


--
www.tudorgirba.com
www.feenk.com

"Problem solving efficiency grows with the abstractness level of problem 
understanding."









---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
Chile

Re: [Pharo-users] Morphic is super slow

[Dimitris Chloupis]

Ben is super simple with github, you just load it from package browser in a
clean image (it will always get the latest version) or if you want to get
the latest version on top of existing ChronosManager version , because
Package Browser has a problem that does not get the latest version when you
have one older version already loaded

you do

Metacello new baseline: 'ChronosManager'; repository:
'github://kilon/ChronosManager'; get; load



On Sat, Jan 16, 2016 at 4:25 PM Ben Coman  wrote:

> Okay. So I haven't with git from Pharo before.  What definite actions
> do I need to take to update?
>
> I see the github://kilon/ChronosManager:master repository only contains:
> * one BaselineOfChronosManager.package revision 4, which is the current
> loaded
> * one ChronosManager.package revision 62, which is the current loaded
>
> How do I get those to show a later version that I can load?
>
> Also, if I click on  for ChronosManager.package revision 62,
> then from ChronosManager-kilonAlios.61 context menu I select  changes> it gives an error: "Error: Could not find version
> 'ChronosManager-kilonAlios.61'. Maybe you need to add a repository?"
>   Being familiar with git command line that is somewhat expected, but
> could those more familiar with its usage in Pharo comment on this?
>
> cheers -ben
>
> On Sat, Jan 16, 2016 at 9:41 PM, Dimitris Chloupis
>  wrote:
> > there is no need to update the catalog, my project is in github and
> catalog
> > always loads the latest github version .
> >
> > One of the advantages of using github ;)
> >
> > and any change I do my code is immediately commited and pushed into
> github.
> >
> > On Sat, Jan 16, 2016 at 3:37 PM Ben Coman  wrote:
> >>
> >> On Sat, Jan 16, 2016 at 8:43 PM, Dimitris Chloupis
> >>  wrote:
> >> > Hello Ben with your help and some more digging around I managed to
> solve
> >> > my
> >> > issues and I am now also able to update the taskbar button moprh
> without
> >> > any
> >> > major hit to my cpu. Pharo is now at 6-7% of one core which is not bad
> >> > at
> >> > all.
> >> >
> >> > So what you mention does not seem to affect my performance. However
> >> > there is
> >> > still the problem of ChronoManager taking over a second to open its
> gui
> >> > .
> >>
> >> That profile report didn't format very well. Probably better to put it
> >> in a text file to attach.
> >> let me know when you've updated the catalog and I'll take another look.
> >>
> >> cheers -ben
> >>
> >
>
>

Re: [Pharo-users] Morphic is super slow

[Dimitris Chloupis]

ah yes you are correct is per channel, my bad. You think thats what slows
pharo down ?

On Sat, Jan 16, 2016 at 6:55 PM Hilaire  wrote:

> 8 bits * 4 = 32 bits right?
>
> Le 15/01/2016 22:32, Dimitris Chloupis a écrit :
> >
> > The images are PNGs and RGBA , 8bit
> >
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

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

[Nicolai Hess]

2016-01-16 21:36 GMT+01:00 Dimitris Chloupis :

> how the bug report is bad ?
>
> No the workarounds were not helpful because I was already aware of them :)
>
> I appreciate people trying to help as always but yes it was upsetting to
> me , to be told that my bug report is bad, that loading 60 tiny images in 1
> second is acceptable for a GUI and that opening 60 files is also near the
> limitation of my hardware. Because I find every one of them , very far from
> the truth and not very helpful.
>
> But I may have overacted also in my part so I apologize. All is good life
> goes on :)
>
>
Yes, let's go on.

Re: [Pharo-users] Spec: Populating a playground with a particular content (was Re: Spec: Binding widgets how to)

[Johan Fabry]

Well that’s actually much easier. :-) What you need to do is to use the 
presentationClass:startOn: API method.

| ui |
ui := GlamourPresentationModel new.
ui presentationClass: GTPlayground startOn: (GTPlayPage new saveContent: '42').
ui openWithSpec

I just realized that this was not clear from the examples in the class comment. 
I have updated the class comment to reflect this.

I hope this resolves all your issues!

> On Jan 16, 2016, at 14:24, Offray Vladimir Luna Cárdenas  
> wrote:
> 
> Hi,
> 
> I'm still kind of lost here. If I try with these approaches I get a *new* 
> GTPlayground window populated with content, instead of an embedded one. How 
> can I made this GTPlayPage one that is embedded in a spec glamour interface, 
> like the one in the minimalist example: a dictionary with two keys/values: 
> one which is shown as text and other that is shown as a playground, both 
> populated with the content in the dict values and both, embedded in a widget 
> instead of on separate windows. Is this possible with the current 
> Spec-Glamour implementation?, if not how can be it extended to make this 
> happen?
> 
> Thanks,
> 
> Offray
> 
> On 16/01/16 10:36, Johan Fabry wrote:
>> Ah, sorry for the confusion, for the sake of the example I oversimplified 
>> things. Let’s say that I have a GTPlayground instance that has been around 
>> for some time, and then I want to change its content. What should I do?
>> 
>> | play |
>> “play is the GTPlayground instance"
>> play := (GTPlayground new openOn: GTPlayPage new) model.
>> 
>> “… lots of things happen … the world turns … sun and moon go up and down … "
>> 
>> play entity saveContent: '42'.
>> play update.
>> 
>> Still like this ?
>> 



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
Chile

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

[Nicolai Hess]

2016-01-16 15:40 GMT+01:00 Dimitris Chloupis :

> 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 
> 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
>>
>>
>>
>>

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

[Dimitris Chloupis]

how the bug report is bad ?

No the workarounds were not helpful because I was already aware of them :)

I appreciate people trying to help as always but yes it was upsetting to me
, to be told that my bug report is bad, that loading 60 tiny images in 1
second is acceptable for a GUI and that opening 60 files is also near the
limitation of my hardware. Because I find every one of them , very far from
the truth and not very helpful.

But I may have overacted also in my part so I apologize. All is good life
goes on :)

On Sat, Jan 16, 2016 at 9:51 PM Nicolai Hess  wrote:

> 2016-01-16 15:40 GMT+01:00 Dimitris Chloupis :
>
>> 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 
>> 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
>>>
>>>
>>>
>>>

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

[Denis Kudriashov]

2016-01-16 15:30 GMT+01:00 Dimitris Chloupis :

> Images are needed on startup when the project is updated which means any
> of the image files could change.
>
> Its a big problem for me , I can preload everything, save it to an image
> and distribute the image instead with zero delays. I dont care if this is
> going to be improved or not , since I can work around this limitation.
>
> I was merely reporting the creating forms from pngs is too slow.


Years ago I investigate this kind of problem for my application. I can't
optimize PNGReader on image side. I tried to connect some C library but no
success.
My time was limited for this issue. And it was not really critical for me.
So I gave up.

After that Athens was announced. And as I understand Cairo can work with
png-files directly without loading it to image side. I not try it. Maybe
you can experiment with this.

Re: [Pharo-users] Pharo 5 new vm crash on window resize

[Ben Coman]

I think logging every one-off non-reproducible bug leads to bug
bankruptcy.  Until there is a reproducible case, reporting here and
waiting for similar reports from a few people or a more occurrences
yourself is a good plan.
cheers -ben

On Sat, Jan 16, 2016 at 11:50 PM, Johan Fabry  wrote:
> Hi all,
>
> this just happened to me: I opened a new image (today’s build), resized it 
> and the VM segfaulted. I am on MacOS. crash.dmp is in attachment. I have been 
> unable to reproduce, sadly. Is this a known issue or should I add a new bug 
> report ?
>
>
>
>
>
> ---> Save our in-boxes! http://emailcharter.org <---
>
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
> Chile
>
>

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

[Dimitris Chloupis]

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  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
>
>
>
>

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

[Dimitris Chloupis]

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 :)

On Sat, Jan 16, 2016 at 5:49 PM Esteban Lorenzano 
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  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 
> 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 
>> 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
>>>
>>>
>>>
>>>
>