[Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]
On 24 May 2010 13:36, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On May 23, 2010, at 11:04 PM, Igor Stasenko wrote:
2010/5/23 Javier Pimás <elpochodelagente@gmail.com>:
Hi, may I ask how you are rendering these fonts? You parse the glyphs and then render lines with opengl or use freetype to render to a texture without antialiasing or both?
Squeak has already a TT font reader, so i just taking the data from there and piping to GPU. What you see here is freely scalable vector/curve rendering done completely on GPU.
If you asked me, I'd say I like the method but for fonts they look a bit blury, I'd say too much for the smaller ones.
I think this is best what you can achieve without hinting / subpixel AA.
Also, what are you working on?
I once did a GLCanvas, and now i want to reiterate and improve it using new callout mechanism (NativeBoost), and full coverage of OpenGL API, with all extensions available at your disposal.
Igor it would be good it we could have
NativeBoostRomeCanvas
if you see what I mean :)
Yes, i actually want to do that. I plan to inject the new methods into a Morph Morph>>fullDrawOnRomeCanvas: aCanvas Morph>>drawOnRomeCanvas: aCanvas which should tell the morph to use a different instructions/commands to perform drawing, to conform with RomeReferenceCanvas protocol. I don't want to repeat a balloon canvas protocol. Then, eventually, when we will have everything ready, we will be free to use different rendering backend than Balloon canvas. And its important to make it a non-intrusive. So, the plan is: - create a separate package, which will contain extension methods to Morph and its various subclasses. And maybe some little classes. - this package !!_should not_!! have any dependencies on Rome , and should be loaded cleanly, even if you don't have Rome installed. It only should conform with Rome canvas protocol for implementing rendering. This will ensure a backend agnostic nature of new morphic rendering code. If you think this plan is cool, then lets pick a package name and repository, and i will start happy coding :)
Regards, Â Â Â Â Â Â Javier.
2010/5/23 Igor Stasenko <siguctua@gmail.com>
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Just an idea how to call the package: Romph-Rendering if you swizzle first 3 letters, you'll get Morph-Rendering :) On 24 May 2010 14:36, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 May 2010 13:36, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On May 23, 2010, at 11:04 PM, Igor Stasenko wrote:
2010/5/23 Javier Pimás <elpochodelagente@gmail.com>:
Hi, may I ask how you are rendering these fonts? You parse the glyphs and then render lines with opengl or use freetype to render to a texture without antialiasing or both?
Squeak has already a TT font reader, so i just taking the data from there and piping to GPU. What you see here is freely scalable vector/curve rendering done completely on GPU.
If you asked me, I'd say I like the method but for fonts they look a bit blury, I'd say too much for the smaller ones.
I think this is best what you can achieve without hinting / subpixel AA.
Also, what are you working on?
I once did a GLCanvas, and now i want to reiterate and improve it using new callout mechanism (NativeBoost), and full coverage of OpenGL API, with all extensions available at your disposal.
Igor it would be good it we could have
NativeBoostRomeCanvas
if you see what I mean :)
Yes, i actually want to do that.
I plan to inject the new methods into a Morph
Morph>>fullDrawOnRomeCanvas: aCanvas Morph>>drawOnRomeCanvas: aCanvas
which should tell the morph to use a different instructions/commands to perform drawing, to conform with RomeReferenceCanvas protocol.
I don't want to repeat a balloon canvas protocol.
Then, eventually, when we will have everything ready, we will be free to use different rendering backend than Balloon canvas.
And its important to make it a non-intrusive. So, the plan is:
- create a separate package, which will contain extension methods to Morph and its various subclasses. And maybe some little classes.
- this package !!_should not_!! have any dependencies on Rome , and should be loaded cleanly, even if you don't have Rome installed. It only should conform with Rome canvas protocol for implementing rendering.
This will ensure a backend agnostic nature of new morphic rendering code.
If you think this plan is cool, then lets pick a package name and repository, and i will start happy coding :)
Regards, Â Â Â Â Â Â Javier.
2010/5/23 Igor Stasenko <siguctua@gmail.com>
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
Yes, i actually want to do that.
I'm trying to understand the reason of such a plan? Is it because like that the clients of existing rendering do not have to be touched?
I plan to inject the new methods into a Morph
Morph>>fullDrawOnRomeCanvas: aCanvas Morph>>drawOnRomeCanvas: aCanvas
which should tell the morph to use a different instructions/commands to perform drawing, to conform with RomeReferenceCanvas protocol.
I don't want to repeat a balloon canvas protocol.
what was wrong with it?
Then, eventually, when we will have everything ready, we will be free to use different rendering backend than Balloon canvas.
And its important to make it a non-intrusive. So, the plan is:
- create a separate package, which will contain extension methods to Morph and its various subclasses. And maybe some little classes.
- this package !!_should not_!! have any dependencies on Rome , and should be loaded cleanly, even if you don't have Rome installed. It only should conform with Rome canvas protocol for implementing rendering.
This will ensure a backend agnostic nature of new morphic rendering code.
If you think this plan is cool, then lets pick a package name and repository, and i will start happy coding :)
Regards, Javier.
2010/5/23 Igor Stasenko <siguctua@gmail.com>
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 24 May 2010 17:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Yes, i actually want to do that.
I'm trying to understand the reason of such a plan? Is it because like that the clients of existing rendering do not have to be touched?
To make things minimally dependent on implementation.
I plan to inject the new methods into a Morph
Morph>>fullDrawOnRomeCanvas: aCanvas Morph>>drawOnRomeCanvas: aCanvas
which should tell the morph to use a different instructions/commands to perform drawing, to conform with RomeReferenceCanvas protocol.
I don't want to repeat a balloon canvas protocol.
what was wrong with it?
I did this once for GLCanvas, and don't want to repeat that again :) The Balloon canvas and its uses is too damn focused on blitting, which makes it too hard to provide a backend which doing most things on GPU. If you want to go into vector world, you should keep a distance from any blitting operations. Simply because they are ineffective, CPU hungry and don't scale well.
Then, eventually, when we will have everything ready, we will be free to use different rendering backend than Balloon canvas.
And its important to make it a non-intrusive. So, the plan is:
- create a separate package, which will contain extension methods to Morph and its various subclasses. And maybe some little classes.
- this package !!_should not_!! have any dependencies on Rome , and should be loaded cleanly, even if you don't have Rome installed. It only should conform with Rome canvas protocol for implementing rendering.
This will ensure a backend agnostic nature of new morphic rendering code.
If you think this plan is cool, then lets pick a package name and repository, and i will start happy coding :)
Regards, Â Â Â Â Â Â Javier.
2010/5/23 Igor Stasenko <siguctua@gmail.com>
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I did this once for GLCanvas, and don't want to repeat that again :) The Balloon canvas and its uses is too damn focused on blitting, which makes it too hard to provide a backend which doing most things on GPU. If you want to go into vector world, you should keep a distance from any blitting operations. Simply because they are ineffective, CPU hungry and don't scale well.
In that case what would be the next generation API (call it Athens) that would make ROME getting better and that your code would propose an API compliant interface? You could that way have a class that implements the Athens interface and the system gets improved and you would not depend on Athens. Because we should not neglect that without common API change and adaptation is and will be a pain. Stef
On 24 May 2010 18:33, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I did this once for GLCanvas, and don't want to repeat that again :) The Balloon canvas and its uses is too damn focused on blitting, which makes it too hard to provide a backend which doing most things on GPU. If you want to go into vector world, you should keep a distance from any blitting operations. Simply because they are ineffective, CPU hungry and don't scale well.
In that case what would be the next generation API (call it Athens) that would make ROME getting better and that your code would propose an API compliant interface? You could that way have a class that implements the Athens interface and the system gets improved and you would not depend on Athens. Â Because we should not neglect that without common API change and adaptation is and will be a pain.
Yes. But i want to stress, what meaning we are putting into 'API'. 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. 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.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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. 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. Stef
On 24 May 2010 21:16, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Ok. Let me start.
Excellent I want to learn. And I will ask cyrille to read all that. The first things is that we should get Rome working then we fix the api.
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.
how to you see that?
This means, that if i'd want to use different canvas, i will need to add another method which will perform a conversion.
you lost me there. But I ;m sure that you will explain it to me :)
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.
do you have a sketch that I follow the example 100%
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.
I see we need a factory and the canvas will play this role. Stef
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 24 May 2010 22:11, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Ok. Let me start.
Excellent I want to learn. And I will ask cyrille to read all that. The first things is that we should get Rome working then we fix the api.
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.
how to you see that?
Well, consider this: 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]. most likely, this will be inappropriate for anything else than RomePlugin. While, of course each kind of canvas could implement own #primFillLinearGradientOriginX: y:directionX: y: colorStops: except that it should not be a prim, and then it will waste time converting color stops again - into a form, which fits best for its own needs. So, why using 2 conversions, where 1 is enough? :) In same way, #asFloat may be not necessary, because canvas could accept integers as well as floats, so converting everything to floats is just a waste of time.
This means, that if i'd want to use different canvas, i will need to add another method which will perform a conversion.
you lost me there. But I ;m sure that you will explain it to me :)
I meant that i would need to add the GradientFillStyle>>installOnRomeGLCanvas: aCanvas instead of reusing the code.
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.
do you have a sketch that I follow the example 100%
GradientFillStyle>>installOnRomeCanvas: aCanvas ^ aCanvas cacheAt: self ifAbsentPut: [ aCanvas gradientFill: #linear origin: ... colors: ... ] and generally, a persistent resources (or ones which may change, but rarely) could use a following pattern: Something>>installOnRomeCanvas: aCanvas self isChanged ifTrue: [ aCanvas invalidateCache: self ]. ^ aCanvas cacheAt: self ifAbsentPut: [ aCanvas createSomething: ... ] Then, after heating-up, it will run at maximum efficiency by using a cached (and already converted resources) instead of performing conversions each time.
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.
I see we need a factory and the canvas will play this role.
Yes.
Stef
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Some news (sources at www.squeaksource.com/Athens): About having a first 'minimal' version, working with RomePluginCanvas and RomeReferenceCanvas, it seems to be ok. I retrieve the tests from Sophie and all are green. In romeDemo, I made a category with some working examples (using RomePluginCanvas and RomeRefrenceCanvas). However, There is still some primitive faillures for which I'm not able to do a lot of things: see for example RomeDemo class >> demoRotateWindow. Now about fonts, I thing the best is to rebuild all: a part of the code is using some Tweak specific classes, or other classes no longer present in Pharo. Morover I wonder why it is usefull to have a Rome-comon API for fonts (RomeFont), when pharo as already its own AbstractFont API ? fonts are just set to a canvas to draw strings. You can see an example using fonts in RomeDemo class >> demoRotateSophieLogo.
From tweak, I only kept classes about CTransformCanvas, but I don't know what it is :) There is just a working example in RomeDemo. So maybe it could be removed (I think all the 'Athens-Tweak' category could be removed).
So maybe at this point we could start to fix the API (?) 2010/5/24 Igor Stasenko <siguctua@gmail.com>
On 24 May 2010 22:11, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Ok. Let me start.
Excellent I want to learn. And I will ask cyrille to read all that. The first things is that we should get Rome working then we fix the api.
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.
how to you see that?
Well, consider this:
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].
most likely, this will be inappropriate for anything else than RomePlugin. While, of course each kind of canvas could implement own #primFillLinearGradientOriginX: y:directionX: y: colorStops: except that it should not be a prim, and then it will waste time converting color stops again - into a form, which fits best for its own needs. So, why using 2 conversions, where 1 is enough? :)
In same way, #asFloat may be not necessary, because canvas could accept integers as well as floats, so converting everything to floats is just a waste of time.
This means, that if i'd want to use different canvas, i will need to add another method which will perform a conversion.
you lost me there. But I ;m sure that you will explain it to me :)
I meant that i would need to add the GradientFillStyle>>installOnRomeGLCanvas: aCanvas instead of reusing the code.
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.
do you have a sketch that I follow the example 100%
GradientFillStyle>>installOnRomeCanvas: aCanvas ^ aCanvas cacheAt: self ifAbsentPut: [ aCanvas gradientFill: #linear origin: ... colors: ... ]
and generally, a persistent resources (or ones which may change, but rarely) could use a following pattern:
Something>>installOnRomeCanvas: aCanvas self isChanged ifTrue: [ aCanvas invalidateCache: self ]. ^ aCanvas cacheAt: self ifAbsentPut: [ aCanvas createSomething: ... ]
Then, after heating-up, it will run at maximum efficiency by using a cached (and already converted resources) instead of performing conversions each time.
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.
I see we need a factory and the canvas will play this role.
Yes.
Stef
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Some news (sources at www.squeaksource.com/Athens):
About having a first 'minimal' version, working with RomePluginCanvas and RomeReferenceCanvas, it seems to be ok. I retrieve the tests from Sophie and all are green. In romeDemo, I made a category with some working examples (using RomePluginCanvas and RomeRefrenceCanvas).
However, There is still some primitive faillures for which I'm not able to do a lot of things: see for example RomeDemo class >> demoRotateWindow.
Now about fonts, I thing the best is to rebuild all: a part of the code is using some Tweak specific classes, or other classes no longer present in Pharo. Morover I wonder why it is usefull to have a Rome-comon API for fonts (RomeFont), when pharo as already its own AbstractFont API ?
I guess that the idea was really to have an API
fonts are just set to a canvas to draw strings. You can see an example using fonts in RomeDemo class >> demoRotateSophieLogo.
From tweak, I only kept classes about CTransformCanvas, but I don't know what it is :) There is just a working example in RomeDemo. So maybe it could be removed (I think all the 'Athens-Tweak' category could be removed).
So maybe at this point we could start to fix the API (?)
Excellent! So may be we could put ROME in pharo-dev as a demo? Stef
On 2 June 2010 16:59, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Some news (sources at www.squeaksource.com/Athens):
About having a first 'minimal' version, working with RomePluginCanvas and RomeReferenceCanvas,  it seems to be ok. I retrieve the tests from Sophie and all are green. In romeDemo, I made a category  with some working examples (using RomePluginCanvas and RomeRefrenceCanvas).
However, There is still some primitive faillures for which I'm not able to do a lot of things: see for example RomeDemo class >> demoRotateWindow.
Now about fonts, I thing the best is to rebuild all: a part of the code is using some Tweak specific classes, or other classes no longer present in Pharo. Morover I wonder why it is usefull to have a Rome-comon API for fonts (RomeFont), when pharo as already its own AbstractFont API ?
I guess that the idea was really to have an API
fonts are just set to a canvas to draw strings. You can see an example using fonts in RomeDemo class >> demoRotateSophieLogo.
From tweak, I only kept classes about CTransformCanvas, but I don't know what it is  :) There is just a working example in RomeDemo. So maybe it could be removed (I think all the 'Athens-Tweak' category could be removed).
So maybe at this point we could start to fix the API (?)
Excellent! So may be we could put ROME in pharo-dev as a demo?
But without bindings with Morphic, its not really userful.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (3)
-
Cyrille Delaunay -
Igor Stasenko -
Stéphane Ducasse