Thursday, February 11, 2010

How to Render a JavaFX Node into an Image

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.


Sometimes you want to render a Node tree into an Image. For example, you may want to do it for performance reasons (such as this example), or you may want to create thumbnail views, or perhaps you want to create a nice drag & drop effect where there is a ghost image of the object being manipulated showing both the current position (the real node) and its target position (its image).



There are some solutions posted for this, but they rely on pretty deep ties to AWT and scenegraph internals. There isn't a way to do it using public APIs yet, but here is a simpler solution. This uses a method on Scene to render the scene to an image, so the trick is to temporarily remove the Node from its current location in the node hierarchy, place it in a new Scene, render the image and put the Node back. This is all pretty simple - you just have to take care of some minor details - like the fact that the scene render will render from (0,0) to the size of the scene bounds, rather than from minX to maxX and minY to maxY. So, we have to add a reverse Translation to place the image back. There is also a problem that the scene render will truncate the bottom and rightmost pixels, so we need to explicitly set the scene size and padd it by 1. And finally, with CSS in the picture we want to duplicate the stylesheet reference from the Node's scene in the render scene, and we also need to preserve the style context. (There are more issues here around CSS; it is a key new feature in JavaFX 1.3 and central to the controls, and there are implementation aspects here for when the CSS phase is running, and it turns out currently the layout styles stay intact - they only get recomputed on the next layout pulse - so this all works beautifully. But the implementation is changing a lot these days so this may need tweaking before this ink dries!)



The only limitation here is that we need to be able to move the Node to render it - which means you cannot render any Nodes that are bound to its parent, e.g. you have a parent group whose content property is a bound sequence including the Node.


http://piliq.com/javafx/?p=1108
http://forums.sun.com/thread.jspa?threadID=5392972

Note - NOT official APIs - much cleaner.
Limitation
Couple of necessary tricks: must set scene bounds, and shift it to (0,0); scale

def platformImage = scene.renderToImage(null);
image = Image.impl_fromPlatformImage(platformImage);

Anyway, I wrote some code to do this today. This doesn't only render the node; it also has the possibility to scale the image if its width or height exceeds a certain number. We do that because in the authoring tool we show a little preview of the selected component, and this uses the render to node facility.
(Screenshot here)


My Test Environment

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.


Last year I documented my setup for running unit tests on my Mac. The solution relied on a quirk of how the window system on the Mac worked. And unfortunately, when I upgraded to Snow Leopard a few months ago, the solution stopped working.



However, after trying a few things I've found a new setup which works -- and thanks to some other improvements I now have a better setup than ever!



In short,


  • I run the unit tests via Hudson, the continuous integration server. The tests are running on a different account on this Mac, such that
    the UI tests never interfere with my work - no focus loss, no windows popping up, etc.
  • I use a special Hudson plugin to filecopy my source tree to the build server repository, such that I don't have to check in the code I want to run tests again.
  • Since Hudson is running locally it has access to my audio, so I have it speak when the build is done (and whether it succeeded or failed) so that I know immediately whether to push my changes or investigate the build or test failures.



The tri
AUDIO