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.