On 24 May 2010 17:22, Stéphane Ducasse <[email protected]> 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 <[email protected]> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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
