The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
We should also document that when taking a snapshot of something that is animating, either explicitly under user control or implicitly (such as chart animation, see RT-22736), the snapshot will be done based on the state of the scene graph at the moment the snapshot is taken and will not reflect any subsequent animation changes.
16-07-2012
As part of this, we also need to document the limitation in CSS and layout processing, where in order for either to work correctly for Node.snapshot(), the node in question must be attached to a Scene. The scene need not be attached to a Stage. As a workaround, an app just needs to call:
new Scene(root)
Where "root" is either the node on which snapshot is called, or is an ancestor of that node.
15-06-2012
When reviewing a recent change, Kirill noted:
-----------------------------------------------------------------------------------------------------------------
> + int xMin = (int)Math.floor(x);
> + int yMin = (int)Math.floor(y);
> + int xMax = (int)Math.ceil(x + w);
> + int yMax = (int)Math.ceil(y + h);
it seems that the {x,y,w,h} is never used outside of the block above.
It mean that the images from the two following calls would be identical:
> doSnapshot(scene, 3.1, 3.1, 5, 5);
> doSnapshot(scene, 3.4, 3.4, 5, 5);
Is it documented somehow ?
-----------------------------------------------------------------------------------------------------------------
A discussion of how a floating point bounds or viewport maps to integer pixel locations when taking a snapshot seems like a good idea.