Thanks for you two, I will try this tomorrow - I'm in France so it's late now ;) Our project is Open Source, but this functionality is not central to it, I will extract this on another Open Source project then after it's done, this could be useful to other devs think.
Hervé 2014-11-14 0:15 GMT+01:00 Phil Race <philip.r...@oracle.com>: > Basically for printing we had to detect that we were printing and use a > non-cached texture. > If you look for references to "PrinterGraphics" you might find some of > them. > Canvas is one place we had to deal with this. There are at least one or > two others. > Doing anything like only this via public API is probably an insurmountable > challenge. > > -phil. > > > On 11/13/14 2:49 PM, Kevin Rushforth wrote: > >> You could take a look at what JavaFX internally does for printing, which >> is similar to what you are trying to do. It also forces the J2D pipeline >> and had to deal with this issue. You likely won't be able to do it without >> modifying FX internals, though, which is what printing does in a few places. >> >> -- Kevin >> >> >> Herve Girod wrote: >> >>> Hello, >>> >>> I think that more than one year ago, I asked if it was possible to dump >>> the >>> JavaFX rendering process. More than one year later, I (or we, for I am >>> speaking on behalf of my project) are almost there. We use this in a >>> library for a "JavaFX to any format you want" converter. For example we >>> are >>> currently able to convert a live JavaFX image to a PowerPoint slider >>> (using >>> POI), or we also could do the same with a WMF / EMF / SVG image, keeping >>> the vector content of course. >>> >>> What we did is hacking the J2DPrismGraphics class to render it in a >>> custom >>> Graphics2D context which in turn can be a PPT / SVG / WMF / or EMF >>> serializer. >>> >>> Our use case is the use of JavaFX in an Editor (no it's not a JavaFX >>> Editor, we edit graphic specifications for an avionics standard called >>> ARINC 661), and the ability to produce another Vector format with exactly >>> the same UI. >>> >>> It works very well, except that of course we had to hack a few JavaFX >>> core >>> classes to do that (obviously J2DPrismGraphics was not designed to allow >>> this). We did not recompile the core library, it's just separate classes >>> which uses com.sun classes when possible, or we used PrivilegedActions >>> when >>> a method we needed was package protected. >>> >>> But we have still a big problem (I think that it might be the only one, >>> except for the fact that our solution is an ugly hack, as you can see): >>> >>> There is still one case where our solution does not work: Textures. In >>> fact >>> we would have been able to convert JavaFX textures to BufferedImages if >>> we >>> could use the Java2D-based Texture class, but of course as we did nothing >>> special, we encounter a D3D Texture (for example on Windows) which we >>> don't >>> know how to deal with. >>> >>> Which leads me to my two questions: >>> >>> - Is there a programmatic way (even a contorted one) to force JavaFX to >>> use >>> our own specific Pipeline (the idea is to be able to do this temporarily >>> when serializing the JavaFX content, so without having to use command >>> line >>> argument) >>> >>> - I think that it could be very useful to have a neutral and JavaFX - >>> supported way for developers to use their own Pipeline, even if it was >>> limited and with a lower than average performance. Being able to convert >>> from / to the JavaFX format is something that can be very useful. >>> >>> Hervé >>> >> >
