Re: [Pharo-project] Athens and Cairo, first baby steps
You are using the last approach, using getData, nice that is already implemented. Yes, i will move to Athens now. Up to now i've been playing with NBCairo, to render all the Gaucho shapes. I see that all NBCairo classes are replicated in Athens, NBCairoSurface=AthensCairoSurface, AthenCairoCanvas = NBCairoContext. Does it make sense to refactor Athens to use NBCairo? Currently there are two ways of interfacing with Cairo, maybe Athens should just reuse NBCairo. Athens should simply be "an adapter" from the Athens API, to the actual Cairo wrapper (NBCairo). Fernando On Wed, Dec 21, 2011 at 10:04 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Dec 21, 2011, at 8:52 AM, Fernando Olivero wrote:
Igor, what does newSurface: do?, in the context of Cairo.
I just create a cairo Surface
How do you render the contents of the Cairo surface to the Display? Or are you using the writeToPng->readFromPng to Form->Display Form mechanism.
Copy from buffer to a form. Have a look at the implementation.
I was planning to use, NBCairoSurface>>getData:, which returns a pointer to the data, and simply update the Display contents with the surface's data.
What would be good is that you use Athens?
Fernando
On Tue, Dec 20, 2011 at 11:09 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Alex normally you will just use athens and you will get a zoomable canvas :). So mondrian should not use Cairo (just athens. Athens defines an API and you will be able to have multiple back ends and your code should run the same on cairo or balloon (may be degraded in balloon). but your code will not be different.
Stef
Your work is truly important! I plan in the long term to make Mondrian and Roassal use Cairo. This has been on my todo list for quite some time already...
Alexandre
On 20 Dec 2011, at 14:56, Igor Stasenko wrote:
We binding an Athens API for Cairo library. It fits pretty well as a backend to API.
Today i got some basics working. Mostly, the functionality covered by:
AthensCairoSurfaceExamples example1 and AthensCairoSurfaceExamples example2
which drawing nothing fancy but just rectangle(s) with solid color.
example2 " self example2 "
   | surf |
   surf := self newSurface: 100@100.
   surf drawDuring: [:can |        surf clear.
       can setPaint: Color blue.
       can drawShape: (            can createPath: [:path |                path                    absolute;                    lineTo: 50@0;                    lineTo: 50@50;                    lineTo: 0@50            ])
   ].
   Display getCanvas drawImage:   surf asForm  at: 0@0
P.S. Stef says that Athens API is quite cool :)
-- Best regards, Igor Stasenko. <Screen Shot 2011-12-20 at 6.56.22 PM.png><Screen Shot 2011-12-20 at 6.57.04 PM.png>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
You are using the last approach, using getData, nice that is already implemented.
Yes, i will move to Athens now. Up to now i've been playing with NBCairo, to render all the Gaucho shapes.
I see that all NBCairo classes are replicated in Athens,
not replicated :) In fact Athens design supports well the decomposition of Cairo :)
NBCairoSurface=AthensCairoSurface, AthenCairoCanvas = NBCairoContext. Does it make sense to refactor Athens to use NBCairo?
No just gets inspiration.
Currently there are two ways of interfacing with Cairo, maybe Athens should just reuse NBCairo.
It depends what you call reuse. But for us NBCairo should disappear and just have Athens.
Athens should simply be "an adapter" from the Athens API, to the actual Cairo wrapper (NBCairo).
Why? because we can call directly the cairo library
Fernando
On Wed, Dec 21, 2011 at 10:04 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Dec 21, 2011, at 8:52 AM, Fernando Olivero wrote:
Igor, what does newSurface: do?, in the context of Cairo.
I just create a cairo Surface
How do you render the contents of the Cairo surface to the Display? Or are you using the writeToPng->readFromPng to Form->Display Form mechanism.
Copy from buffer to a form. Have a look at the implementation.
I was planning to use, NBCairoSurface>>getData:, which returns a pointer to the data, and simply update the Display contents with the surface's data.
What would be good is that you use Athens?
Fernando
On Tue, Dec 20, 2011 at 11:09 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Alex normally you will just use athens and you will get a zoomable canvas :). So mondrian should not use Cairo (just athens. Athens defines an API and you will be able to have multiple back ends and your code should run the same on cairo or balloon (may be degraded in balloon). but your code will not be different.
Stef
Your work is truly important! I plan in the long term to make Mondrian and Roassal use Cairo. This has been on my todo list for quite some time already...
Alexandre
On 20 Dec 2011, at 14:56, Igor Stasenko wrote:
We binding an Athens API for Cairo library. It fits pretty well as a backend to API.
Today i got some basics working. Mostly, the functionality covered by:
AthensCairoSurfaceExamples example1 and AthensCairoSurfaceExamples example2
which drawing nothing fancy but just rectangle(s) with solid color.
example2 " self example2 "
| surf |
surf := self newSurface: 100@100.
surf drawDuring: [:can | surf clear.
can setPaint: Color blue.
can drawShape: ( can createPath: [:path | path absolute; lineTo: 50@0; lineTo: 50@50; lineTo: 0@50 ])
].
Display getCanvas drawImage: surf asForm at: 0@0
P.S. Stef says that Athens API is quite cool :)
-- Best regards, Igor Stasenko. <Screen Shot 2011-12-20 at 6.56.22 PM.png><Screen Shot 2011-12-20 at 6.57.04 PM.png>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 21 December 2011 10:58, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
You are using the last approach, using getData, nice that is already implemented.
Yes, i will move to Athens now. Up to now i've been playing with NBCairo, to render all the Gaucho shapes.
I see that all NBCairo classes are replicated in Athens,
not replicated :) In fact Athens design supports well the decomposition of Cairo :)
NBCairoSurface=AthensCairoSurface, AthenCairoCanvas = Â NBCairoContext. Does it make sense to refactor Athens to use NBCairo?
No just gets inspiration.
Currently there are two ways of interfacing with Cairo, maybe Athens should just reuse NBCairo.
It depends what you call reuse. But for us NBCairo should disappear and just have Athens.
Athens should simply be "an adapter" from the Athens API, to the actual Cairo wrapper (NBCairo).
Why? because we can call directly the cairo library
Athens defines a roles, like surface, canvas, paints, shapes and transformation and protocols for them. The concrete implementation (or classes) are not that important, since you should rely on protocol(s) of objects with designated roles. In this way a different backend may serve as well as any other for your application. I hope it will also teach people to not use directly classes everywhere, but instead use factory messages available from factory objects (which can be asked for creating a new object of certain properties), instead of using direct class name(s). NBCairo originally created by Javier as an example how to write binding of external library using NativeBoost. There was no any plans concerning developing NBCairo beyond serving as a simple example. I think it is more important to have a framework with own balanced and well designed API for vector graphics, not tied to some concrete library (like that we can switch the backend at any moment, while keep everything running). -- Best regards, Igor Stasenko.
On 21 December 2011 10:16, Fernando Olivero <fernando.olivero@usi.ch> wrote:
You are using the last approach, using getData, nice that is already implemented.
Yes. But it is quite ineffective, since you need to transfer bulk of data in memory for nothing. Later we should think how to avoid extra copying and directly use/display rendered artifacts. But right now it is sufficient :) -- Best regards, Igor Stasenko.
participants (3)
-
Fernando Olivero -
Igor Stasenko -
Stéphane Ducasse