Regarding this, of the key points of Pharo is that most of the system is able to be looked at from a lot of angles in source code form.

Removing that ability is not going to be nice.

But this doesn't mean we can't go the other way around of course, allowing it to embrace new technical possibilities. But as extensions to a core that stays under full control.

At the moment, I've been tinkering with the idea of integrating a 3D demo engine (DirectX based) with Pharo.

The engine will get an API and being scripted from the Pharo side.

The engine can currently do things like:�http://www.youtube.com/watch?v=oRnogMokS_8

Phil

Phil


2013/4/17 Esteban Lorenzano <estebanlm@gmail.com>
Hi,�

This is just the cairo library rendering in a quartz format. No native quartz access yet, so...

1) yes... is 100% compatible with Cairo (because it is Cairo :)
2) no GPU, no OpenGL, just optimized rendering (one of this days I will write the novel "how we render world canvas nowadays"... it is a thriller end-of-the-world story)

we are thinking with Igor if a quartz native renderer has sense right now. Of course, in the long term, it has completely sense, but atm, I have the feeling that other more portable renderer (like an OpenGL renderer) is better investment.
Anyway, we still have some other stuff to do before:

- finish athens (including new text model)
- finish bridge�
- test same with linux, windows
etc.

On Apr 17, 2013, at 7:50 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

Hi

2013/4/17 Fernando Olivero <fernando.olivero@usi.ch>
NICE work Esteban!

Does the AthensQuartzSurface, support all Athens related code? (paths,
paints,etc..) I will be more than happy to move away from the software
rendering of the current cairo backend.

Is Quartz work by GPU? is it use openGL?
�

Fernando



On Tue, Apr 16, 2013 at 8:41 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
> not to say about efficiency.
>
> I've been doing some cpu cycle tests.
>
> Rendering a 1600@1200 gradient to world canvas (repeat each 50ms): � ~90% cpu consumption
>
> Same test, but sending it direct to window canvas using bridge: ~40% cpu consumption
>
> so... we are in the good path :)
>
> Esteban
>
> On Apr 16, 2013, at 8:28 PM, Igor Stasenko <siguctua@gmail.com> wrote:
>
>> On 16 April 2013 19:09, kilon <thekilon@yahoo.co.uk> wrote:
>>> And you guys then say that pharo is not macos first citizen
>>>
>>> ha
>>>
>>> ha
>>>
>>> and
>>>
>>> ha
>>>
>>> I am a macos user , I love my imac and macos, but my vote goes to cross
>>> platform.
>>>
>>> Still another great library that is more than welcomed, definitely cant do
>>> any harm ;)
>>>
>>
>> By saying that we don't need Cairo on MacOS i meant following:
>>
>> Athens designed to support multiple backends.
>> It is out of question, that better to use most suitable backend,
>> available on current platform.
>>
>> But apart of it stays ObjC bridge. Which would allow us to speak with
>> ObjC-runtime
>> (and Mac VM using it) directly.
>>
>>>
>>>
>>> --
>>> View this message in context: http://forum.world.st/Fwd-do-you-know-what-is-this-tp4681962p4681975.html
>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>