Dumping the rendering process in JavaFX

[Herve Girod]

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.race at 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é
>>>
>>
>