I get the point now, something like the brushes in seaside. Thanks for the explanation. Regarding the protocol, did you consider reusing the same idea, but one step before, as in the following: pathTransform := canvas transformDescribedBy: 'path'. pathTransform scaleBy: 0.5. imageTransform := canvas transformDescribedBy: 'image'. imageTransform scaleBy: 0.5. Maybe add the following for documentation: AthensCairo>>availableTransforms ^ #('path'. 'image'. ) AthensOpenGL>>availableTransforms ^ #('modelView'. 'projection'. ) This would unify the canvas protocol, for all the available rendering engines. Fernando On Mon, Nov 28, 2011 at 6:43 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 28 November 2011 16:04, Fernando Olivero <fernando.olivero@usi.ch> wrote:

...

Don't know, but in case we cant modify Athens, we can always rename the project and start fresh, given that Igor rewrote most of it right?.

Fernando

On Fri, Nov 25, 2011 at 12:58 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

On Nov 25, 2011, at 10:35 AM, Fernando Olivero wrote:

...

Ok, i will try to do so from now on!

Igor, thanks for detailed response, i see now there's no real need for caching the glyphs, even though i didn't consider rotation as an available affine transformation.

Just a question on the protocol of the canvas, i found it better to use the following convenience methods, instead of exposing the transformation (or canvas state) directly to the sender:

drawOn: aCanvas   aCanvas pathTransform …

drawOn: aCanvas    aCanvas scaleBy: 0.5 @0.5 ; translateBy: 10@10 .    …..

the canvas #pathTransform actually should answer a delegate, which should allow you to manipulate coordinate system transformation. There's no intent to expose the state directly. You can modify transformation matrix only via corresponding protocol, but don't manipulate its state directly.

now about canvas scaleBy: ... versus canvas pathTransform scaleBy:... why i did it like that? because there are multiple transformation matrices responsible for different parts of computations. for instance, in OpenVG model there are four:  - path  - image  - stroke  - (forgot) :)

or take an openGL for example there are 3 (or 4) matrices again:  - model  - projection  - texture  - color space

if you expose all of them via canvas, then you have to bloat canvas protocol with duplicate messages like:

canvas pathScale: canvas pathRotate: canvas imageScale: canvas imageRotate: ... etc

that's why there are separate delegates, which represent concrete matrix, and common protocol which you can use for all of them:

canvas pathTransform scaleBy: canvas imageTransform scaleBy: etc

-- Best regards, Igor Stasenko.