True, you have a point.
2013/4/17 Igor Stasenko <siguc...@gmail.com> > On 17 April 2013 13:34, p...@highoctane.be <p...@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 <esteba...@gmail.com> > >> > >> Hi Phil, > >> > >> On Apr 17, 2013, at 9:26 AM, "p...@highoctane.be" <p...@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 <esteba...@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 <dionisi...@gmail.com> > >>> wrote: > >>> > >>> Hi > >>> > >>> 2013/4/17 Fernando Olivero <fernando.oliv...@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 < > esteba...@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 <siguc...@gmail.com> > wrote: > >>>> > > >>>> >> On 16 April 2013 19:09, kilon <theki...@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. > >