[Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

Igor Stasenko siguctua at gmail.com
Mon May 24 12:05:38 EDT 2010


On 24 May 2010 18:33, Stéphane Ducasse <stephane.ducasse at 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 at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-dev mailing list