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.