Dumping the rendering process in JavaFX

[Herve Girod]

Hello,

I did as it was proposed, and it work. I still have some cases where
textures are a little off compared to the position where they should be,
but it might be due to the post-processing I perform after creating the awt
BufferedImage.

Compared to what I thought, there were not a lot of classes I had to "hack"
(by accessing protected or package protected methods or constructors).
Mainly: I had to create a custom Screen (just to avoid NGRegion to fetch
textures from their cache), a custom ResourceProvider (to return my
Textures rather than the Platform ones), and I had to peform some code like
in NGCanvas to get an awt image for textures.

 I will post an openSource project with more generic code than mine after I
have performed some tests.

Hervé

2014-11-14 2:29 GMT+01:00 Jim Graham <james.graham at oracle.com>:

> Some pie in the sky observations about the background here...
>
> Note that there was a fine line there that had to be evaluated.  Many of
> the printing detection changes were basically just "Oh, look, I have a new
> ResourceFactory now, that probably means new Textures", but it was tempered
> with "One might think to permanently shift over to the resources from this
> new factory, but if we're just printing, we are probably going to switch
> right back to a screen factory so any permanent changes of internal state
> are likely unwarranted".  On the other hand, sometimes when you print a
> scene, it was specially created just for the printing process so the
> initial ResourceFactory it sees is likely the only one it will ever see
> (and then the tree will be tossed).
>
> It would be nice if we could generalize this or switch the way we manage
> resource states in the NGNode tree so that this was both flexible for
> switching seamlessly to a new resource factory/pool and flexibly dealt with
> the temporary/permanent nature of why those differences might come up (in
> other words, dynamically use and cache new resources without alienating or
> losing track of old ones unless that old pipeline/RF is going away).
>
> Right now there aren't any on-screen related changes that might require us
> to permanently switch pipelines/resource factories (not entirely sure about
> management of D3D resources when we lose access to the screen, though) and
> printing is really the only use case where we ever even see a new
> ResourceFactory.  But, who knows what the future may bring and making
> assumptions about the RF being a constant throughout the app life cycle are
> not necessarily the best implementation practice in the long run...
>
> Have fun!  ;)
>
>                         ...jim
>
>
> On 11/13/14 3:15 PM, Phil Race wrote:
>
>> 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é
>>>>
>>>
>>