RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture

[Nir Lisker]

On Thu, 9 Nov 2023 03:15:27 GMT, Michael Strauß <mstrauss at openjdk.org> wrote:

>> Moves the filter setting of the samplers from the device parameters configuration to the use-site, allowing for dynamic changes in the sampler. This PR does internal plumbing work only to bring it close to the ES2 pipeline. A followup PR will create the public API.
>> 
>> Summary of the changes:
>> * Created a new (internal for now) `TextureData` object that is intended to contain all the data of texture (map) of `PhongMaterial`, such as filters, addressing, wrapping mode, mipmaps etc. **This PR deals only with filters** as a starting point, more settings can be added later.
>> * Creates an update mechanism from the Java side material to the native D3D layer. The public API `PhoneMaterial` is *not* changed yet. The peer `NGPhongMaterial` is configured to receive update from the public `PhongMaterial` when the public API is created via new `ObjectProperty<TextureData>` properties.
>> * Small refactoring in the D3D layer with a new map types enum to control the texture settings more easily.
>> 
>> The JBS issue lists some regressions in a comment, but I couldn't reproduce them. It looks like the sampler settings needed to be added anywhere, and that was the easiest to do at the time. Now they were just moved.
>
> modules/javafx.graphics/src/main/native-prism-d3d/D3DMeshView.cc line 295:
> 
>> 293:     for (int i = 0; i < map_type::num_map_types; i++) {
>> 294:         map_type type = static_cast<map_type>(i);
>> 295:         SUCCEEDED(device->SetTexture(type, material->getMap(type)));
> 
> Wrapping the calls with the `SUCCEEDED` macro doesn't do anything useful.

Yes, but it's done everywhere else in the class, and was done for these calls before I changed this code. Maybe a better error handling design is needed.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1389570725