Fwd: do you know what is this?

meanwhile, Esteban works on ObjC bridge ;)




--
Best regards,
Igor Stasenko.

--
Best regards,
Igor Stasenko.

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 ;)

We mainly say that each travel has to start with one step

why do you think this is the final step?

Well to be fair any language that respects itself has an ObjC bridge , and its definetly a big deal if you want to embrace iOS too. So definetly the thumbs up from me. I am no way against this.

On 16 April 2013 19:31, kilon <[hidden email]> wrote:
> Well to be fair any language that respects itself has an ObjC bridge , and
> its definetly a big deal if you want to embrace iOS too. So definetly the
> thumbs up from me. I am no way against this.
>
>
well, it is good to stand on the shoulder of giant, but as long as he moves into
same direction as you want :)

>
> --
> View this message in context: http://forum.world.st/Fwd-do-you-know-what-is-this-tp4681962p4681982.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>



--
Best regards,
Igor Stasenko.

On 16 April 2013 19:09, kilon <[hidden email]> wrote:
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.

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 <[hidden email]> wrote:

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 <[hidden email]> wrote:

Hi

Hi, 

On Apr 17, 2013, at 9:27 AM, [hidden email] 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

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.

On 17 April 2013 11:23, kilon <[hidden email]> 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.

On 17 April 2013 08:34, Esteban Lorenzano <[hidden email]> wrote:
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.



--
Best regards,
Igor Stasenko.

Hi Phil,

Hi,

On Apr 17, 2013, at 11:23 AM, kilon <[hidden email]> 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 12:19, Esteban Lorenzano <[hidden email]> wrote:
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.



--
Best regards,
Igor Stasenko.