Re: [Pharo-project] do you know what is this?
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. 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.
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.
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.
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.
On Apr 17, 2013, at 9:27 AM, phil@highoctane.be wrote:
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 what do you actually get from a graphics engine from 1978, even if you can read its code? Marcus
Hi Phil, On Apr 17, 2013, at 9:26 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
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.
I do not understand this... why do you think that now you can do that and with an all-in-image approach you cannot?
Removing that ability is not going to be nice.
why do you think that this will remove it? Esteban
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.
On 17 April 2013 12:19, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi Phil,
On Apr 17, 2013, at 9:26 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
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.
I do not understand this... why do you think that now you can do that and with an all-in-image approach you cannot?
Removing that ability is not going to be nice.
why do you think that this will remove it?
Yes, especially that we're want to do straightly opposite: - move code from VM sources to image so people can understand it and use/change it much easier instead of keeping it frozen forever in VM.
Esteban
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.
-- Best regards, Igor Stasenko.
Of course we can still understand with an all in image style (leveraging ObjCBridge and NB). But it will be hard to study how things are occuring internally when leaving the image. e.g. using components from the OSX Frameworks for things like text editors may be powerful but ultimately, this will make us into "users" and not technology owners (mmmh, hard to explain what I want to convey). Pharo is an interesting platform to *really* understand how things do work at a low level. I agree with your view on doing most inside the image, plugins and stuff is actually hard to understand and master (I've been cutting my teeth at this for something like a year and still am a super n00b). One cool thing I'd like to have working is CUDA or OpenCL for example. That would be easier to do if on the image side of course. Phil 2013/4/17 Esteban Lorenzano <estebanlm@gmail.com>
Hi Phil,
On Apr 17, 2013, at 9:26 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
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.
I do not understand this... why do you think that now you can do that and with an all-in-image approach you cannot?
Removing that ability is not going to be nice.
why do you think that this will remove it?
Esteban
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<http://nabble.com/> .
-- Best regards, Igor Stasenko.
On 17 April 2013 13:34, phil@highoctane.be <phil@highoctane.be> wrote:
Of course we can still understand with an all in image style (leveraging ObjCBridge and NB).
But it will be hard to study how things are occuring internally when leaving the image. e.g. using components from the OSX Frameworks for things like text editors may be powerful but ultimately, this will make us into "users" and not technology owners (mmmh, hard to explain what I want to convey).
Well, you always have a choice to write everything from scratch :) For instance, try implement own sockets library or file system (not FS as in Pharo, but FS which deals with disks - ext, ext2, FAT, NTFS etc ;).
Pharo is an interesting platform to *really* understand how things do work at a low level.
I agree with your view on doing most inside the image, plugins and stuff is actually hard to understand and master (I've been cutting my teeth at this for something like a year and still am a super n00b).
One cool thing I'd like to have working is CUDA or OpenCL for example. That would be easier to do if on the image side of course.
Phil
2013/4/17 Esteban Lorenzano <estebanlm@gmail.com>
Hi Phil,
On Apr 17, 2013, at 9:26 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
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.
I do not understand this... why do you think that now you can do that and with an all-in-image approach you cannot?
Removing that ability is not going to be nice.
why do you think that this will remove it?
Esteban
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.
-- Best regards, Igor Stasenko.
Igor Stasenko wrote
Well, you always have a choice to write everything from scratch :)
These are not mutually exclusive. What we're doing now by harnessing external libraries is prototyping - we're on the first step of "make it work, make it right, make it fast" ( and maybe getting sone #3 for free ;) ). Of course ultimately, we would like turtles all the way down, but relying on the already-done work of others gives us leverage, allowing us to focus our limited resources on the key things that have /never been done before/ - our unique contribution to the future of computing. When time and resources allow, we are free to come back and write from Scratch in Smalltalk, especially since there is a nice abstraction layer in between. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Fwd-do-you-know-what-is-this-tp4681962p4682107.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Can NB also disassamble code called ? I know that gdb can do this, and since NB generates assembly code for the FFI calls I was wondering if it can disassemble them too. Assembly is definetly not as pretty as smalltalk but can be useful none the less to look at internals. Porting everything to smalltalk is not a realistic or a very useful scenario. Whos is going to port Cocoa to Morphic come on lets see some hands raising :D I see coding more as Aikido , use the force of your enemy ( in this case a big clumsy GUI API like Cocoa , yes I dont like Big GUI apis ) against him. An ObjC bridge and NB seem to fit that role fine to me. -- View this message in context: http://forum.world.st/Fwd-do-you-know-what-is-this-tp4681962p4682112.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Apr 17, 2013, at 2:35 PM, kilon <thekilon@yahoo.co.uk> wrote:
Porting everything to smalltalk is not a realistic or a very useful scenario. Whos is going to port Cocoa to Morphic come on lets see some hands raising :D
The idea never was to move everything. In fact is just the opposite. Morphic is, from a point of view, an attempt of replicate the native graphics/widgets libraries, already present in modern O.S. into the image. If you look close, today you are already using cocoa... just a small subset of it but is cocoa after all. You use cocoa to create a canvas and display a huge bitmap inside (the world), who actually displays some widgets who resembles something that is already there (windows, buttons, lists, etc.)... so, who rewrote everything and who don't? The idea is: move into the image everything that can be moved there (and makes sense). Esteban
Esteban I was replying to PhillipeBeck post, I think that is what he meant, to move things to smalltalk side instead of relying to external libraries. Unless I misunderstood his post . -- View this message in context: http://forum.world.st/Fwd-do-you-know-what-is-this-tp4681962p4682118.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
True, you have a point. 2013/4/17 Igor Stasenko <siguctua@gmail.com>
On 17 April 2013 13:34, phil@highoctane.be <phil@highoctane.be> wrote:
Of course we can still understand with an all in image style (leveraging ObjCBridge and NB).
But it will be hard to study how things are occuring internally when leaving the image. e.g. using components from the OSX Frameworks for things like text editors may be powerful but ultimately, this will make us into "users" and not technology owners (mmmh, hard to explain what I want to convey).
Well, you always have a choice to write everything from scratch :)
For instance, try implement own sockets library or file system (not FS as in Pharo, but FS which deals with disks - ext, ext2, FAT, NTFS etc ;).
Pharo is an interesting platform to *really* understand how things do work at a low level.
I agree with your view on doing most inside the image, plugins and stuff is actually hard to understand and master (I've been cutting my teeth at this for something like a year and still am a super n00b).
One cool thing I'd like to have working is CUDA or OpenCL for example. That would be easier to do if on the image side of course.
Phil
2013/4/17 Esteban Lorenzano <estebanlm@gmail.com>
Hi Phil,
On Apr 17, 2013, at 9:26 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
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.
I do not understand this... why do you think that now you can do that
and
with an all-in-image approach you cannot?
Removing that ability is not going to be nice.
why do you think that this will remove it?
Esteban
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.
-- Best regards, Igor Stasenko.
Estaban correct me if I am wrong but AFAIK MACOS GUI is based on opengl and it is hardware accelerated. I hear the same applied for Linux GUIs too in large. Anyway, my only objection is the fact that we will have twice the code to maintain and more to worry about. As I said I am on macos , I am a mac developer (not pro) still ObjC never made sense for me since it locks me down to a specific platform. It does however make sense to have platform specific code for providing better and smoother support for that platform. So its definetly good to have and thank you for your efforts. Speedwise , I know the subject on optimisation is a huge one and there thousands of ways to speed up specific code. Its a more a practical one, since not to many people work on athens we need to choose one way that makes life easier for everyone and especially people who develop Athens. Part of the sucess of Cairo is that is an easy to understand little library that is very well documented. I would like to see Athens maintain that. -- View this message in context: http://forum.world.st/Fwd-do-you-know-what-is-this-tp4681962p4682078.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 17 April 2013 11:23, kilon <thekilon@yahoo.co.uk> wrote:
Estaban correct me if I am wrong but AFAIK MACOS GUI is based on opengl and it is hardware accelerated. I hear the same applied for Linux GUIs too in large.
Not at all. It is same story as with Athens: - GUI uses Cocoa framework. Sure you can use OpenGL or Quartz for rendering, but in most cases you just have a canvas where you draw to using common protocol. So, you don't need to think whether it is opengl-based or quartz or cairo.
Anyway, my only objection is the fact that we will have twice the code to maintain and more to worry about. As I said I am on macos , I am a mac developer (not pro) still ObjC never made sense for me since it locks me down to a specific platform. It does however make sense to have platform specific code for providing better and smoother support for that platform. So its definetly good to have and thank you for your efforts.
Right. The objective for ObjC bridge is smoother integration with mac platform. It has little to do with Athens but more about communicating with underlying platform using language it understands.
Speedwise , I know the subject on optimisation is a huge one and there thousands of ways to speed up specific code. Its a more a practical one, since not to many people work on athens we need to choose one way that makes life easier for everyone and especially people who develop Athens.
Part of the sucess of Cairo is that is an easy to understand little library that is very well documented. I would like to see Athens maintain that.
We will get there. :)
-- View this message in context: http://forum.world.st/Fwd-do-you-know-what-is-this-tp4681962p4682078.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Hi, On Apr 17, 2013, at 11:23 AM, kilon <thekilon@yahoo.co.uk> wrote:
Anyway, my only objection is the fact that we will have twice the code to maintain and more to worry about.
let me explain this little thing a bit... Do you think that code doesn't need to be maintained and taken care how it is right now? I will draw you a picture of how it works this now /----------------------------------------------\ | "Pretended wonderland" (image) | =========================== | Lots of things: I/O, FFI, etc. | ----------------------------------------------- | Virtual Machine (Cog, Stack, Int) | \----------------------------------------------/ This is your world right now. You work on "pretended wonderland" side, assuming that everything below will work and hence you "don't need" to maintain what is below wonderland, isn't? Well, wrong. Everything need to be maintained. What you do not see too (you do not see it, but it is there, oh yes). The difference is: - in wonderland, everybody can try to fix things (even id they fail, it is there to play/change/adapt) - in levels below, there are just a few people on earth who actually can maintain that: Igor, myself and some others, but is for sure less than ten people. In fact, what happens now is that I have to maintain not two, but three different versions of the same thing (for each platform), in two different languages (C and Objective-C) and three different sets of libraries. And yes, I "personalize" and use the "I" instead "we" because most of the times is me, with some really valuable from Igor and Camillo (but well, they do Athens and a PhD respectively, so many times is just a one-man-work). So, what actually happens now is that problems stack waiting for a solution, a solution which btw will never be of total satisfaction of users. As an example, let's see the display plugin (which of course is not a plugin at all, if you remove that from vm, it stops to work). Display plugin is based in BitBlt, who creates/transforms bitmaps and renders them into screen. Forget about 2D vectorial graphics (or any thing that can bebefict of using of GPU). This technology is obsolete and retina displays on mac prove that: there is no way to do it work fine (that means: good rendering and good performance). So we need to change that. How to do it? There are two basic approaches possible: The traditional one says that some "gurus" should write a new plugin (ideally backward compatible with the previous one). Then you have an updated plugin (and probably a perfect one, if you don't want to maintain it), until next time technology changes and then the gurus can be summoned again to do their magic. As you can see, since our community of potential gurus is (with luck) ten persons in the world, that does not scales at all. Then it is our approach: move to the image all the things that can be moved. Then you will have this: /----------------------------------------------\ | "Pretended wonderland" | ----------------------------------------------- | Abstract system layer in image | | (that most of people will never | | see anyway) | =========================== | Virtual Machine (Cog, Stack, Int) | \----------------------------------------------/ With NativeBoost we can achieve same performance that we achieve using plain C. And we have an incredible huge extra bonus: it is there so everybody can try to modify/fix/update if needed, not just the gurus. And we also have much more advantages to show: this is moving also the low level programing to "pharo way", and as I showed in my silly videos, is bring the "immediate feedback" experience also to that level (something that you could never achieve with older way of thinking) And finally... been in image does not need that you will need to deal with that. How many of you know of the internals of Zinc/Zodiac or the Weak Registry? (just to put a couple of examples). Most of us just take it and use it. Our path is to bring to the whole community the power to change everything in your environment. To change it live, in the pharo way. And some times I feel that it is a power that the community is afraid to take :) lose your fear: having that power feels good :) And again: do you still think there is no need for maintain low level stuff? Think again. cheers, Esteban
Well said, Esteban, well said. This is a same idea and message which i wanted to deliver doing my NativeBoost presentation at 2012's Smalltalks conference in Puerto Madryn. So, we are pretty well aligned with our vision :) On 17 April 2013 12:53, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
On Apr 17, 2013, at 11:23 AM, kilon <thekilon@yahoo.co.uk> wrote:
Anyway, my only objection is the fact that we will have twice the code to maintain and more to worry about.
let me explain this little thing a bit...
Do you think that code doesn't need to be maintained and taken care how it is right now?
I will draw you a picture of how it works this now
/----------------------------------------------\ | "Pretended wonderland" (image) | =========================== | Lots of things: I/O, FFI, etc. | ----------------------------------------------- | Virtual Machine (Cog, Stack, Int) | \----------------------------------------------/
This is your world right now. You work on "pretended wonderland" side, assuming that everything below will work and hence you "don't need" to maintain what is below wonderland, isn't?
Well, wrong.
Everything need to be maintained. What you do not see too (you do not see it, but it is there, oh yes). The difference is:
- in wonderland, everybody can try to fix things (even id they fail, it is there to play/change/adapt) - in levels below, there are just a few people on earth who actually can maintain that: Igor, myself and some others, but is for sure less than ten people. In fact, what happens now is that I have to maintain not two, but three different versions of the same thing (for each platform), in two different languages (C and Objective-C) and three different sets of libraries. And yes, I "personalize" and use the "I" instead "we" because most of the times is me, with some really valuable from Igor and Camillo (but well, they do Athens and a PhD respectively, so many times is just a one-man-work).
So, what actually happens now is that problems stack waiting for a solution, a solution which btw will never be of total satisfaction of users. As an example, let's see the display plugin (which of course is not a plugin at all, if you remove that from vm, it stops to work).
Display plugin is based in BitBlt, who creates/transforms bitmaps and renders them into screen. Forget about 2D vectorial graphics (or any thing that can bebefict of using of GPU). This technology is obsolete and retina displays on mac prove that: there is no way to do it work fine (that means: good rendering and good performance).
So we need to change that.
How to do it? There are two basic approaches possible: The traditional one says that some "gurus" should write a new plugin (ideally backward compatible with the previous one). Then you have an updated plugin (and probably a perfect one, if you don't want to maintain it), until next time technology changes and then the gurus can be summoned again to do their magic. As you can see, since our community of potential gurus is (with luck) ten persons in the world, that does not scales at all.
Then it is our approach: move to the image all the things that can be moved. Then you will have this:
/----------------------------------------------\ | "Pretended wonderland" | ----------------------------------------------- | Abstract system layer in image | | (that most of people will never | | see anyway) | =========================== | Virtual Machine (Cog, Stack, Int) | \----------------------------------------------/
With NativeBoost we can achieve same performance that we achieve using plain C. And we have an incredible huge extra bonus: it is there so everybody can try to modify/fix/update if needed, not just the gurus. And we also have much more advantages to show: this is moving also the low level programing to "pharo way", and as I showed in my silly videos, is bring the "immediate feedback" experience also to that level (something that you could never achieve with older way of thinking) And finally... been in image does not need that you will need to deal with that. How many of you know of the internals of Zinc/Zodiac or the Weak Registry? (just to put a couple of examples). Most of us just take it and use it.
Our path is to bring to the whole community the power to change everything in your environment. To change it live, in the pharo way. And some times I feel that it is a power that the community is afraid to take :)
lose your fear: having that power feels good :)
And again: do you still think there is no need for maintain low level stuff? Think again.
cheers, Esteban
-- Best regards, Igor Stasenko.
Very interesting email, worth a post somewhere. 2013/4/17 Esteban Lorenzano <estebanlm@gmail.com>
Hi,
On Apr 17, 2013, at 11:23 AM, kilon <thekilon@yahoo.co.uk> wrote:
Anyway, my only objection is the fact that we will have twice the code to maintain and more to worry about.
let me explain this little thing a bit...
Do you think that code doesn't need to be maintained and taken care how it is right now?
I will draw you a picture of how it works this now
/----------------------------------------------\ | "Pretended wonderland" (image) | =========================== | Lots of things: I/O, FFI, etc. | ----------------------------------------------- | Virtual Machine (Cog, Stack, Int) | \----------------------------------------------/
This is your world right now. You work on "pretended wonderland" side, assuming that everything below will work and hence you "don't need" to maintain what is below wonderland, isn't?
Well, wrong.
Everything need to be maintained. What you do not see too (you do not see it, but it is there, oh yes). The difference is:
- in wonderland, everybody can try to fix things (even id they fail, it is there to play/change/adapt) - in levels below, there are just a few people on earth who actually can maintain that: Igor, myself and some others, but is for sure less than ten people. In fact, what happens now is that I have to maintain not two, but three different versions of the same thing (for each platform), in two different languages (C and Objective-C) and three different sets of libraries. And yes, I "personalize" and use the "I" instead "we" because most of the times is me, with some really valuable from Igor and Camillo (but well, they do Athens and a PhD respectively, so many times is just a one-man-work).
So, what actually happens now is that problems stack waiting for a solution, a solution which btw will never be of total satisfaction of users. As an example, let's see the display plugin (which of course is not a plugin at all, if you remove that from vm, it stops to work).
Display plugin is based in BitBlt, who creates/transforms bitmaps and renders them into screen. Forget about 2D vectorial graphics (or any thing that can bebefict of using of GPU). This technology is obsolete and retina displays on mac prove that: there is no way to do it work fine (that means: good rendering and good performance).
So we need to change that.
How to do it? There are two basic approaches possible: The traditional one says that some "gurus" should write a new plugin (ideally backward compatible with the previous one). Then you have an updated plugin (and probably a perfect one, if you don't want to maintain it), until next time technology changes and then the gurus can be summoned again to do their magic. As you can see, since our community of potential gurus is (with luck) ten persons in the world, that does not scales at all.
Then it is our approach: move to the image all the things that can be moved. Then you will have this:
/----------------------------------------------\ | "Pretended wonderland" | ----------------------------------------------- | Abstract system layer in image | | (that most of people will never | | see anyway) | =========================== | Virtual Machine (Cog, Stack, Int) | \----------------------------------------------/
With NativeBoost we can achieve same performance that we achieve using plain C. And we have an incredible huge extra bonus: it is there so everybody can try to modify/fix/update if needed, not just the gurus. And we also have much more advantages to show: this is moving also the low level programing to "pharo way", and as I showed in my silly videos, is bring the "immediate feedback" experience also to that level (something that you could never achieve with older way of thinking) And finally... been in image does not need that you will need to deal with that. How many of you know of the internals of Zinc/Zodiac or the Weak Registry? (just to put a couple of examples). Most of us just take it and use it.
Our path is to bring to the whole community the power to change everything in your environment. To change it live, in the pharo way. And some times I feel that it is a power that the community is afraid to take :)
lose your fear: having that power feels good :)
And again: do you still think there is no need for maintain low level stuff? Think again.
cheers, Esteban
you're right... I will cut&paste and write something extra next days :) On Apr 17, 2013, at 4:25 PM, phil@highoctane.be wrote:
Very interesting email, worth a post somewhere.
2013/4/17 Esteban Lorenzano <estebanlm@gmail.com> Hi,
On Apr 17, 2013, at 11:23 AM, kilon <thekilon@yahoo.co.uk> wrote:
Anyway, my only objection is the fact that we will have twice the code to maintain and more to worry about.
let me explain this little thing a bit...
Do you think that code doesn't need to be maintained and taken care how it is right now?
I will draw you a picture of how it works this now
/----------------------------------------------\ | "Pretended wonderland" (image) | =========================== | Lots of things: I/O, FFI, etc. | ----------------------------------------------- | Virtual Machine (Cog, Stack, Int) | \----------------------------------------------/
This is your world right now. You work on "pretended wonderland" side, assuming that everything below will work and hence you "don't need" to maintain what is below wonderland, isn't?
Well, wrong.
Everything need to be maintained. What you do not see too (you do not see it, but it is there, oh yes). The difference is:
- in wonderland, everybody can try to fix things (even id they fail, it is there to play/change/adapt) - in levels below, there are just a few people on earth who actually can maintain that: Igor, myself and some others, but is for sure less than ten people. In fact, what happens now is that I have to maintain not two, but three different versions of the same thing (for each platform), in two different languages (C and Objective-C) and three different sets of libraries. And yes, I "personalize" and use the "I" instead "we" because most of the times is me, with some really valuable from Igor and Camillo (but well, they do Athens and a PhD respectively, so many times is just a one-man-work).
So, what actually happens now is that problems stack waiting for a solution, a solution which btw will never be of total satisfaction of users. As an example, let's see the display plugin (which of course is not a plugin at all, if you remove that from vm, it stops to work).
Display plugin is based in BitBlt, who creates/transforms bitmaps and renders them into screen. Forget about 2D vectorial graphics (or any thing that can bebefict of using of GPU). This technology is obsolete and retina displays on mac prove that: there is no way to do it work fine (that means: good rendering and good performance).
So we need to change that.
How to do it? There are two basic approaches possible: The traditional one says that some "gurus" should write a new plugin (ideally backward compatible with the previous one). Then you have an updated plugin (and probably a perfect one, if you don't want to maintain it), until next time technology changes and then the gurus can be summoned again to do their magic. As you can see, since our community of potential gurus is (with luck) ten persons in the world, that does not scales at all.
Then it is our approach: move to the image all the things that can be moved. Then you will have this:
/----------------------------------------------\ | "Pretended wonderland" | ----------------------------------------------- | Abstract system layer in image | | (that most of people will never | | see anyway) | =========================== | Virtual Machine (Cog, Stack, Int) | \----------------------------------------------/
With NativeBoost we can achieve same performance that we achieve using plain C. And we have an incredible huge extra bonus: it is there so everybody can try to modify/fix/update if needed, not just the gurus. And we also have much more advantages to show: this is moving also the low level programing to "pharo way", and as I showed in my silly videos, is bring the "immediate feedback" experience also to that level (something that you could never achieve with older way of thinking) And finally... been in image does not need that you will need to deal with that. How many of you know of the internals of Zinc/Zodiac or the Weak Registry? (just to put a couple of examples). Most of us just take it and use it.
Our path is to bring to the whole community the power to change everything in your environment. To change it live, in the pharo way. And some times I feel that it is a power that the community is afraid to take :)
lose your fear: having that power feels good :)
And again: do you still think there is no need for maintain low level stuff? Think again.
cheers, Esteban
btw... as someone pointed here, I need to clarify something I said: I didn't mentioned Eliot because I was talking about the plugins... When we talk about the VM itself, the number of people who are capable of work on it reduces from 10 to maybe 5 (Eliot and some others like Igor... but certainly not me :) Disclaimer done... is so obvious for me that Eliot is "the master-guru" that I just forget to mention him (I'm really sorry for that). Esteban On Apr 17, 2013, at 6:30 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
you're right... I will cut&paste and write something extra next days :)
On Apr 17, 2013, at 4:25 PM, phil@highoctane.be wrote:
Very interesting email, worth a post somewhere.
2013/4/17 Esteban Lorenzano <estebanlm@gmail.com> Hi,
On Apr 17, 2013, at 11:23 AM, kilon <thekilon@yahoo.co.uk> wrote:
Anyway, my only objection is the fact that we will have twice the code to maintain and more to worry about.
let me explain this little thing a bit...
Do you think that code doesn't need to be maintained and taken care how it is right now?
I will draw you a picture of how it works this now
/----------------------------------------------\ | "Pretended wonderland" (image) | =========================== | Lots of things: I/O, FFI, etc. | ----------------------------------------------- | Virtual Machine (Cog, Stack, Int) | \----------------------------------------------/
This is your world right now. You work on "pretended wonderland" side, assuming that everything below will work and hence you "don't need" to maintain what is below wonderland, isn't?
Well, wrong.
Everything need to be maintained. What you do not see too (you do not see it, but it is there, oh yes). The difference is:
- in wonderland, everybody can try to fix things (even id they fail, it is there to play/change/adapt) - in levels below, there are just a few people on earth who actually can maintain that: Igor, myself and some others, but is for sure less than ten people. In fact, what happens now is that I have to maintain not two, but three different versions of the same thing (for each platform), in two different languages (C and Objective-C) and three different sets of libraries. And yes, I "personalize" and use the "I" instead "we" because most of the times is me, with some really valuable from Igor and Camillo (but well, they do Athens and a PhD respectively, so many times is just a one-man-work).
So, what actually happens now is that problems stack waiting for a solution, a solution which btw will never be of total satisfaction of users. As an example, let's see the display plugin (which of course is not a plugin at all, if you remove that from vm, it stops to work).
Display plugin is based in BitBlt, who creates/transforms bitmaps and renders them into screen. Forget about 2D vectorial graphics (or any thing that can bebefict of using of GPU). This technology is obsolete and retina displays on mac prove that: there is no way to do it work fine (that means: good rendering and good performance).
So we need to change that.
How to do it? There are two basic approaches possible: The traditional one says that some "gurus" should write a new plugin (ideally backward compatible with the previous one). Then you have an updated plugin (and probably a perfect one, if you don't want to maintain it), until next time technology changes and then the gurus can be summoned again to do their magic. As you can see, since our community of potential gurus is (with luck) ten persons in the world, that does not scales at all.
Then it is our approach: move to the image all the things that can be moved. Then you will have this:
/----------------------------------------------\ | "Pretended wonderland" | ----------------------------------------------- | Abstract system layer in image | | (that most of people will never | | see anyway) | =========================== | Virtual Machine (Cog, Stack, Int) | \----------------------------------------------/
With NativeBoost we can achieve same performance that we achieve using plain C. And we have an incredible huge extra bonus: it is there so everybody can try to modify/fix/update if needed, not just the gurus. And we also have much more advantages to show: this is moving also the low level programing to "pharo way", and as I showed in my silly videos, is bring the "immediate feedback" experience also to that level (something that you could never achieve with older way of thinking) And finally... been in image does not need that you will need to deal with that. How many of you know of the internals of Zinc/Zodiac or the Weak Registry? (just to put a couple of examples). Most of us just take it and use it.
Our path is to bring to the whole community the power to change everything in your environment. To change it live, in the pharo way. And some times I feel that it is a power that the community is afraid to take :)
lose your fear: having that power feels good :)
And again: do you still think there is no need for maintain low level stuff? Think again.
cheers, Esteban
On 17 April 2013 08:34, Esteban Lorenzano <estebanlm@gmail.com> wrote:
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.
Right. In a longer term, i think OpenGL is a way to go, to get access to hardware-accelerated renderer. It is , however a lot more work comparing to providing thin layer on top of existing vector-graphics library, because OpenGL operates with much more primitive entities: triangles.
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.
-- Best regards, Igor Stasenko.
participants (8)
-
Denis Kudriashov -
Esteban Lorenzano -
Fernando Olivero -
Igor Stasenko -
kilon -
Marcus Denker -
phil＠highoctane.be -
Sean P. DeNigris