API Review RT:17407 Canvas Node

[Jim Graham]

On 4/20/12 2:39 AM, Dr. Michael Paus wrote:
> Am 20.04.2012 02:09, schrieb Jim Graham:
>> Constructing a path in the GC vs. separate Path object?
> Not having to create Path objects is one of the main motivations to
> use a direct mode graphics interface. The assumption is that all
> information that is needed to create the path is already stored
> somewhere in your own model and having to create a Path object
> is just an unnecessary duplication of that information.

The reason it is awkward is that each segment you add to the path is 
relative to the current transform.  I suppose that someone somewhere has 
a compelling need for constructing a path in multiple coordinate 
systems, but they can usually work around that with appropriate support 
for manually transforming parts of paths stored in a path object.

The problem it creates is for methods like the arc methods.  The 
geometry they add depends on calculations that involve the current 
point, but if the last point added to the path was in a different 
coordinate system then you have to transform it before you can do the 
work.  If the current transform is non-invertible then you can't 
transform it so you end up with path construction methods that fail 
depending on rendering conditions.  If you have paths as objects then 
they get constructed as a whole path and you then operate on them in a 
consistent attribute environment.  It is either rendered in a 
non-invertible coordinate system (in which case it collapses to a line 
or point and nothing is filled) or not.  You don't have "some visible 
parts that can be rendered and other invisible parts that were 
collapsed, and some other visible parts that have an undefined start or 
end because they interact with some geometry that got collapsed by a bad 
transform".

The point you make about not having to duplicate the path storage across 
potentially different areas of the rendering pipeline and application is 
important.  In the Java2D system we get around that by processing the 
Path2D objects directly inside the rendering model so it ends up being 
our internal path storage.  Though the object has some restrictions on 
it as a result (like lots of methods being final so that we can bypass 
the access interfaces when we need to without violating a subclass's 
contract)...

			...jim