[Pharo-users] Morphic is super slow
kilon.alios at gmail.com
Sat Jan 16 03:55:05 EST 2016
ok found how to update the taskbar button , I add this to my step
World submorphs do: [ :each| (each isKindOf: TaskbarMorph) ifTrue: [each
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 <kilon.alios at gmail.com>
> 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 <stepharo at free.fr> 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
>> On Fri, Jan 15, 2016 at 11:32 PM Dimitris Chloupis <kilon.alios at gmail.com>
>>> 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 <hilaire at drgeo.eu> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-users