On Sat, May 31, 2014 at 4:13 AM, kilon alios <[email protected]> wrote:

> Its not about having issues or not having issues, its about how much
> performance you consume for the GUI alone.
>
> I have installed both CPU performance monitor for 2.0GHZ Core2Duo iMac and
> my new i5  3.2 Ghz iMac. Moving a system browser window in the old iMac
> spikes the CPUs to 50-70% while moving the window in the new iMac is down
> to 20%. Of course the old imac is 7 years old the new one is 5 months old.
>
> The question here is "does it really worth doing something about it ?" .
>

It is true that I can write all the words I want to say with a dull pencil
but I prefer a nice sharp one :). How the interface feels is important.


>  Sure if you a creating the new CryEngine in Pharo it would be a major
> problem or any 3d game app that taxes even modern CPUs. But for non
> demanding usage even if pharo community does absolutely nothing this 20%
> will shrink down to 10% then 5% , 2.5% and eventually 1%. This has been
> also a major argument point for cpython. People used to complain A LOT
> about cpython's performance in old cpus, cause lets face it in some
> scenarios and many scenarios it was a BIG problem BUT nowday those voices
> are getting more and more quieter because CPUs have become insanely fast
> and there is no indication this will stop now.
>

Today's machines are thousands of times faster than the ones Smalltalk
originally ran on. How much faster is its UI now? I don't think Moore's Law
is going to fix the problem.

So on the subject of whether we need GPU accelerated GUI at large as a
> community I would say "Definetly Not" ,Morphic is messy enough as it is,
> lets not make it more complex..... please !
>

I agree. It should become less complex. Complexity makes it hard to improve
performance.

I am not saying that GPU acceleration does not have its merits, I am using
> Blender for 3d modeling and its new render engine Cycles makes uses of CUDA
> and its SWEET , I can almost have real time rendering, not final quality ,
> but still good enough to see how it would look in the final render. Real
> time rendering to a 3d artist is like live coding to a coder. Its like
> Christmas vacation in Santa Claus Toy Factory.
>

Sounds awesome.

But on the other hand none stops anyone from implementing a third party
> library that runs pharo headless and then uses the OS to open a new window
> completely bypassing morphic and taking advantage of GPU. I don't think we
> need to make Morphic more complex than it already is. Pharo should be first
> about simplicity and then performance.  But then if you can improve
> performance of Morphic and yet keep it simple enough please be my guest.
>

Fast new windows for 3D would be great and I want my development
environment to be fluid, responsive, and powerful too. Today it feels
sluggish and weighs on me.


> On Sat, May 31, 2014 at 1:47 PM, [email protected] <[email protected]>
> wrote:
>
>> On Sat, May 31, 2014 at 11:33 AM, Hilaire Fernandes <
>> [email protected]> wrote:
>>
>>> We could try to organize a task force on that matter. I will try to
>>> submit some proposals later, but now I want to prepare a delicious cake.
>>>
>>
>> Ha, cool. I am cleaning the home :-)
>>
>> Jokes aside, it is true that the Pharo UI is quite slow.
>> I do not have issues on my Core i7 PC but on my Core2Duo Mac it shows...
>>
>> There are enough benefits to having a software UI (flexibility etc) to
>> suffer that.
>>
>> But there is for sure room for improvement.
>>
>> As resolutions go higher, this problem will only get worse.
>>
>> Where would one have to start looking for performance improvements?
>>
>> Phil
>>
>>
>>> Hilaire
>>>
>>> Le 31/05/2014 10:48, Clément Bera a écrit :
>>> > The second thing is that BitBlt is slow for 2 reasons: it is bit based
>>> > and not vector based and its implementation half in the VM half in the
>>> > image forces to copy a huge number of bits that could be avoided
>>> >
>>> > So the answer is that you need to contribute to the refactoring of
>>> > Morphic or to Athens.
>>> >
>>> > GUI hardware acceleration is clearly not the problem yet.
>>> >
>>>
>>> --
>>> Dr. Geo http://drgeo.eu
>>>
>>>
>>>
>>
>

Reply via email to