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.
>
>

Reply via email to