JavaFX Direct3D 12 rendering pipeline for Windows

[Nir Lisker]

This is exciting news!

I looked at the code quickly. Here are my thoughts.

My biggest remark is that JNI is still being used, which is being more and
more restricted. Recently, Kevin announced that we will be FFM-ready,
surely by the time this pipeline is released. I would like to see (and can
help, having used FFM since incubation) D3D12 being based on FFM.

This will also allow less cluttered code to be written with less effort.
Consider this mess in D3D12NativeMeshView (exists in D3D9 also, not blaming
you for this :) ):

    private native void nSetLight(long ptr, int index, float x, float y,
float z, float r, float g, float b,
                                  float enabled, float ca, float la, float
qa, float isAttenuated, float maxRange,
                                  float dirX, float dirY, float dirZ, float
innerAngle, float outerAngle, float falloff);

That, in a pure Java world, would be `void nSetLight(Light)` with `Light`
holding all its parameters. In fact, this could make whole files that just
prepare the data for the native layer redundant. At least I know this is
the case in the current D3D9 implementation.

It might also be the case that the pointer juggling that we do currently
(using `long ptr` everywhere) will not be needed because FFM does it for us
(Arena takes care of the lifecycle context). However, when it comes to
resource deallocation there are many caveats, so I'm speculating here.

Another design element that I think we can get rid of is the duplication of
data structures in the Java and native sides. if Java has a Light,
Material, and Mesh, the native side doesn't need them in reality, but in
D3D9 (and somewhat in D3D12) it does have them. Without checking, I suspect
that this duplication leads to inefficient memory usage. I speculate that
it was done to minimize the number of native calls, a consideration that
could be overturned with FFM. In general, a lot of the code in C++ can be
potentially moved to Java, with only the calls to DirectX being left of
course.

Thanks for this herculean effort!

On Mon, Oct 14, 2024 at 7:10 PM Lukasz Kostyra <lukasz.kostyra at oracle.com>
wrote:

> Hello openjfx-dev,
>
>
>
> we just pushed a prototype of a new JavaFX Direct3D 12 rendering pipeline
>
> for Windows to a new "direct3d12" branch on jfx-sandbox. It is more than an
>
> experiment branch - we intend to fully develop the D3D12 backend there.
>
>
>
> We're not necessarily looking for contributions at this point, but if
> anyone
>
> has early feedback about it or wants to try it by building it themselves,
>
> that would be fine. We also did not test it on a wider range of hardware,
> so
>
> your mileage may vary. While D3D12 pipeline will build by default, D3D9
>
> pipeline is still the default pick at runtime. To run anything on D3D12
>
> pipeline you need to force it with ex.:
>
>   java -Dprism.order=d3d12 ...
>
>
>
> Backend supports 2D rendering (albeit with some graphical issues here and
> there
>
> that need to be ironed out) and basic 3D rendering. Expect not everything
> fully
>
> working yet (ex. some gradients on 2D controls are incorrect, or 3D-in-2D
> will
>
> straight up not work) and the performance not matching D3D9 yet. Our goal
> is to
>
> first reach feature completion and then focus on performance.
>
>
>
> Lukasz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241015/b71747b2/attachment.htm>