Dumping the rendering process in JavaFX

Herve Girod herve.girod at gmail.com
Thu Nov 13 22:53:54 UTC 2014


Thanks a lot, I did not think about that.

2014-11-13 23:49 GMT+01:00 Kevin Rushforth <kevin.rushforth at oracle.com>:

> 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é
>>
>>
>


More information about the openjfx-dev mailing list