The Canvas is simply a texture of the specified dimensions. (We do
scale that size by any pixel scale applied to the entire scene, as in
Mac retina's 2x scale, but it's size is interpreted in the same
coordinate space as the Stage, Scene and the root Node coordinates.)
Transform properties on the Canvas Node (scale, rotate, translate, list
of transform objects) are applied to the pixels in the texture as they
are incorporated into the scene as if it were an Image.
Transform properties in the GraphicsContext are applied during rendering.
So, neither affects the other or is a shortcut to the other. They do
combine visually into the end product, but one is at the
rendering-into-the-texture stage and the other is at the
blit-texture-to-the-screen stage. Transformations applied to the Canvas
node properties can lead to pixel stretching artifacts...
...jim
On 5/15/15 8:02 AM, Werner Lehmann wrote:
Hi Jeff,
interesting idea although I am not sure in which way this improves
things. I am already scaling the canvas node if it is bigger than
necessary (due to previous zoom, works like supersampling then) or
smaller than necessary (if the maximum size is reached but I need to
present the content bigger than that).
Looks as if the scaling of the canvas and the scaling of the
graphicscontext might both be applied at the same time - unless one is
simply a shortcut to the other. I have to experiment on this one.
Rgds
Werner
On 15.05.2015 16:15, Jeff Hain wrote:
Instead of creating an eventually (and quadratically) huge canvas,
you could try using Canvas.getGraphicsContext().scale(2
double)/translate(2 double),
and "bind" the scroll bars to the {canvas dimensions, applied transform}
data.
