On 24 May 2010 21:16, Stéphane Ducasse <[email protected]> wrote:
> Guess what is my choice :)
>
>>>>>
>> Yes. But i want to stress, what meaning we are putting into 'API'.
>
> the real one :)
>>
>> API is protocols, not classes.
>
>
>> So, a code which renders something using API, should use only messages
>> sent to a canvas object.
>> The difference could be illustrated by following:
>>
>> a)
>> drawOn: aCanvas
>>
>> path := RomePath new.
>> path moveTo: .. lineTo:... close.
>> aCanvas strokePath: path
>>
>> b)
>> drawOn: aCanvas
>>
>> path := aCanvas newPath.
>> path moveTo: .. lineTo:... close.
>> aCanvas strokePath: path
>>
>> In case a) you are introducing a dependency on a concrete path
>> implementation(RomePath).
>> in case b) you asking a canvas to provide a path instance, which
>> conforms to a path protocol.
>>
>> Here lies the main difference, which either gives you a freedom of
>> choice, or otherwise makes your code inflexible.
>> That's what i mean by no dependecy.
>
> I understood it :)
>
>> In case b), a rendering backend is
>> free to use own data structures
>> to optimally reify a path(s), while in case a) you forcing a canvas to
>> have an intimate knowledge about RomePath
>> - a concrete implementation, which may not fit best for canvas and
>> hence it will waste cycles converting a path
>> representation into more appropriate form, in order to render it.
>>
>> That's why, if we follow path b), then morphic rendering could be
>> completely autonomous,
>> and do not depend on concrete Rome API implementation.
>> And enforcing it from a very starting, will make sure that we won't
>> introduce unnecessary
>> dependencies and inflexibility.
>
> so this is why it would be good to have a concrete scenario to stress and
> validate
> the Athens new canvas
> I would really like to see how the one of Morphic 30 will fit into it too.
>
Me too!
> So let us start like that:
> - design your API with flexibility in mind + ROME from the point of
> you of Canvas method
> - give feedback about athens inflexibility
> - we update it
> - we iterate
> the goal should be that at the end we can get really fast a different
> back-end.
> With a bit of chance we will d the same with Morphic30 and we will have a
> cool system.
>
Ok. Let me start.
Rome/Athens adds variouls extension methods to classes which are
involved with graphics.
Here is one of them:
GradientFillStyle>>installOnRomePluginCanvas: aCanvas
| colorStops i |
colorStops := WordArray new: colorRamp size * 3.
i := 0.
colorRamp do: [:stop |
colorStops at: (i:=i+1) put: (stop key * 65536.0) rounded.
colorStops at: (i:=i+1) put: stop value privateRGB.
colorStops at: (i:=i+1) put: stop value privateAlpha].
radial == true
ifTrue: [
aCanvas primFillRadialGradientOriginX: origin x asFloat
y: origin y asFloat
directionX: direction x asFloat
y: direction y asFloat
normalX: self normal x asFloat
y: self normal y asFloat
colorStops: colorStops]
ifFalse: [
aCanvas primFillLinearGradientOriginX: origin x asFloat
y: origin y asFloat
directionX: direction x asFloat
y: direction y asFloat
colorStops: colorStops]
Good:
- a conversion method is context sensitive (it takes a canvas as an argument)
Bad:
- this conversion method will work only for Rome plugin and nothing else.
This means, that if i'd want to use different canvas, i will need to
add another method
which will perform a conversion.
But this can be avoided, if we provide a generic canvas method to
create a gradient fills.
Then this method could be renamed to #installOnRomeCanvas:
and implementation will consist of messages, sent to canvas to build a
gradient fill.
Another example:
asRomeFill , asRomeFont
- this is bad.
Its not a context-sensitive. And therefore , an implementation of
these methods assumes that it will provide
the most suitable conversion of fill or font for Rome backend.
But depending on backend, it may not be the case!
So, all methods like this, should always use a canvas as argument and
talk back to canvas
to perform a conversion.
> Stef
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
