Re: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow

[Karthik P K]

On Wed, 21 Jun 2023 06:34:00 GMT, Karthik P K  wrote:

> The text run selected in `PrismTextLayout::getHitInfo()` method for character 
> index calculation was not correct when Text node was embedded in TextFlow. 
> Hence wrong character index value was calculated for the same.
> 
> Since only x, y coordinates were available in the above mentioned method, 
> sending the text as a parameter to this method is necessary so as to know if 
> the text run selected for character index calculation is correct. Along with 
> this change modified the `PrismTextLayout::getHitInfo()` method to calculate 
> the correct character index.
> 
> Added tests to validate the changes.

The cause for above mentioned issue is that, the `line.getRuns()` call in line 
no.439 in PrismTextLayout.java returns text runs only for the first Text node. 
Because of this issue correct character index is not calculated.
It looks like the issue is in line creation. I will fix this issue along with 
the character index issue we are fixing already in this PR.

-

PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1603662527

Re: RFR: 8310667: Normalize comment blocks in newly-converted package-info.java files

[Andy Goryachev]

On Thu, 22 Jun 2023 18:38:43 GMT, Kevin Rushforth  wrote:

> This is a follow-up fix for 
> [JDK-8180066](https://bugs.openjdk.org/browse/JDK-8180066). As mentioned in 
> the description of PR #1159, we should normalize the javadoc comment blocks 
> in the `package-info.java` files, which were converted from `package.html`.
> 
> In addition to being good cleanup, it also resolves a CI test failure that 
> was introduced by [JDK-8180066](https://bugs.openjdk.org/browse/JDK-8180066), 
> and is being tracked by 
> [JDK-8310654](https://bugs.openjdk.org/browse/JDK-8310654).
> 
> The generated API docs are identical before and after this fix, excluding 
> white-space changes. So the following show zero differences:
> 
> 
> $ diff -w -r before/build/javadoc after/build/javadoc
> 
> 
> Additionally, the following now passes, whereas it fails without this fix:
> 
> 
> $ gradle :graphics:test

Marked as reviewed by angorya (Reviewer).

There are still whitespace diffs (leading whitespace, see the screenshot), but 
i think it's ok for all practical purposes.

https://github.com/openjdk/jfx/assets/107069028/5dfa0380-750e-4173-82d7-9c592c16786f";>

-

PR Review: https://git.openjdk.org/jfx/pull/1160#pullrequestreview-1494148655
PR Comment: https://git.openjdk.org/jfx/pull/1160#issuecomment-1603457021

RFR: 8310667: Normalize comment blocks in newly-converted package-info.java files

[Kevin Rushforth]

This is a follow-up fix for 
[JDK-8180066](https://bugs.openjdk.org/browse/JDK-8180066). As mentioned in the 
description of PR #1159, we should normalize the javadoc comment blocks in the 
`package-info.java` files, which were converted from `package.html`.

In addition to being good cleanup, it also resolves a CI test failure that was 
introduced by [JDK-8180066](https://bugs.openjdk.org/browse/JDK-8180066), and 
is being tracked by [JDK-8310654](https://bugs.openjdk.org/browse/JDK-8310654).

The generated API docs are identical before and after this fix, excluding 
white-space changes. So the following show zero differences:


$ diff -w -r before/build/javadoc after/build/javadoc


Additionally, the following now passes, whereas it fails without this fix:


$ gradle :graphics:test

-

Commit messages:
 - 8310667: Normalize comment blocks in newly-converted package-info.java files

Changes: https://git.openjdk.org/jfx/pull/1160/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1160&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310667
  Stats: 1368 lines in 39 files changed: 0 ins; 10 del; 1358 mod
  Patch: https://git.openjdk.org/jfx/pull/1160.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1160/head:pull/1160

PR: https://git.openjdk.org/jfx/pull/1160

Re: RFR: 8180066: Convert package.html files to package-info.java

[Kevin Rushforth]

On Wed, 21 Jun 2023 15:05:47 GMT, Kevin Rushforth  wrote:

> One thing I didn't do is add a  * at the beginning of the lines that are now 
> part of a javadoc-style comment block. This minimizes the diffs, but it means 
> we won't be using the usual pattern for those comment blocks. I'm inclined to 
> file a follow-up issue rather than changing that now.

I filed [JDK-8310667](https://bugs.openjdk.org/browse/JDK-8310667) to track 
normalizing the javadoc comment blocks.

-

PR Comment: https://git.openjdk.org/jfx/pull/1159#issuecomment-1603142724

Re: Is there any plan to add CSS new features?

[Michael Strauß]

There's a proposal to add implicit transitions:
https://github.com/openjdk/jfx/pull/870
But this is not a plan. The feature may or may not come to JavaFX.


On Thu, Jun 22, 2023 at 6:57 PM Anivie  wrote:
>
> We all know that the CSS features of javafx are developed based on the W3C 
> CSS2.1 version. Now, the new CSS3 introduces a lot of practical features, 
> which can help us quickly build amazing modern applications.
>
> I always think that CSS is an important feature in Javafx, and it is also an 
> important advantage of javafx and other UI frameworks. In recent years, 
> although many CSS features are still being added. But, the CSS features of 
> javafx are constantly lagging behind CSS3, and many commonly used and 
> important functions, are still not available in javafx.
>
> Is there any plan to let Javafx update or even refactor the CSS system to 
> bring features of CSS3 to help us build Javafx applications better?
>
> -- Anivie

Is there any plan to add CSS new features?

[Anivie]

We all know that the CSS features of javafx are developed based on the W3C
CSS2.1 version. Now, the new CSS3 introduces a lot of practical features,
which can help us quickly build amazing modern applications.

I always think that CSS is an important feature in Javafx, and it is also
an important advantage of javafx and other UI frameworks. In recent years,
although many CSS features are still being added. But, the CSS features of
javafx are constantly lagging behind CSS3, and many commonly used and
important functions, are still not available in javafx.

Is there any plan to let Javafx update or even refactor the CSS system to
bring features of CSS3 to help us build Javafx applications better?

-- Anivie

RE: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial

[Matija Brown]

I’ll do the OpenGL – have done quite a bit with Vulkan and GL in the past so 
there’s no problem there.
Certainly usefull if you would do some reviewing – if you finish the Metal 
texture maps someone will surely find
themselves to expand it with sampling.

Tomorrow I’ll give a short summary on what would be to do for OpenGL, as we 
have that for D3D already.
Then do a little example probably – doesn’t really seem too much work to me?

Thanks,
Matija.

From: Jayathirth Rao Daarapuram Venkatesh 
Murthy
Sent: Thursday, 22 June 2023 06:28
To: Nir Lisker; Kevin 
Rushforth
Cc: openjfx-dev@openjdk.org
Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling 
on PhongMaterial

Correcting myself:
Currently I am working on Metal implementation of Texture maps in JavaFX 3D : 
https://bugs.openjdk.org/browse/JDK-8310109 and not on adding nearest 
sampling(which last mail can imply).

Thanks,
Jay

From: openjfx-dev  on behalf of Jayathirth Rao 
Daarapuram Venkatesh Murthy 
Date: Thursday, 22 June 2023 at 9:22 AM
To: Nir Lisker , Kevin Rushforth 
Cc: openjfx-dev@openjdk.org 
Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling 
on PhongMaterial
Currently I am working on Metal implementation of the same and has no bandwidth 
to work on additional OpenGL thing.
But I can help in reviewing the code if we come up with addition of nearest 
filtering.

Thanks,
Jay

From: openjfx-dev  on behalf of Nir Lisker 

Date: Wednesday, 21 June 2023 at 9:40 PM
To: Kevin Rushforth 
Cc: openjfx-dev@openjdk.org 
Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling 
on PhongMaterial
If I remember correctly, in OpenGL you parse the texture filter when the 
texture is being created, while in DirectX as it is bound
to the sampler (it is a sampler state after all) it would have to be set before 
every render call. However it shouldn’t make any
API difference really, as we can just have a field somewhere and the parse it 
along when needed.

Yes, the JBS ticket mentions this difference as well.

Since Kevin approved this feature and the API seems to converge nicely between 
the pipelines, we can start the work. I'm somewhat busy with other tasks as of 
late, but I will try to formulate an API. Matija or Jay, if one of you can 
start investigating the changes to the OpenGL pipeline we could create a branch 
in the sandbox repo and work there.

On Wed, Jun 21, 2023 at 4:03 PM Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:
My preference would be to add support only for Linear and Nearest in any case.

-- Kevin

On 6/21/2023 4:48 AM, Matija Brown wrote:
As Jayathrith said, in OpenGL as well as Metal only NEAREST and LINEAR filters 
are available.

There might be a way of getting around it by implementing some own algorithm 
for OpenGL and Metal but that seem slightly
over the top. So either one would have to keep the options limited to the two 
supported everywhere
or go with the “conditional” features.

Having had a look at DirectX the APIs seem not to differ too much.
If I remember correctly, in OpenGL you parse the texture filter when the 
texture is being created, while in DirectX as it is bound
to the sampler (it is a sampler state after all) it would have to be set before 
every render call. However it shouldn’t make any
API difference really, as we can just have a field somewhere and the parse it 
along when needed.

Cheers,
Matija.

From: Jayathirth Rao Daarapuram Venkatesh 
Murthy
Sent: Wednesday, 21 June 2023 13:09
To: Nir Lisker; Matija 
Brown
Cc: openjfx-dev@openjdk.org
Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling 
on PhongMaterial

In OpenGL we set GL_LINEAR by default at : 
https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L221

And Metal supports only two types of Min/Max filters : Nearest(default) and 
Linear. So even if D3D supports multiple types we might be limited to support 
only these 2 filters for all platforms.

Thanks,
Jay

From: openjfx-dev 
 on behalf 
of Nir Lisker 
Date: Wednesday, 21 June 2023 at 3:57 PM
To: Matija Brown 
Cc: openjfx-dev@openjdk.org 

Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling 
on PhongMaterial
First of all, please excuse directly e-mailing you earlier today. Working with 
mailing lists is quite new for me and apparently I forgot to add
the mailing list to cc.

I didn't get any private email, so you seem to be doing better than you thought 
with the

Re: Vulkan

[Johan Vos]

I agree with Nir. For years now, I'd love to have a Vulkan pipeline, not
just for desktop linux but for the embedded/mobile platforms as well.
But it's a lot of work indeed. It's easy to go for the first 90%, or even
more. But the edge cases are the ones that will consume lots of time. I
wish we could find a sponsor for this, but that isn't easy.

- Johan

On Thu, Jun 22, 2023 at 3:27 PM Nir Lisker  wrote:

> The Vulkan pipeline option has been brought up several times over the past
> years. It's a good addition, but it's a lot of work and there aren't enough
> people who volunteered to work on it.
>
> Even "upgrading" the DirectX implementation from 9 to 11 hasn't taken off
> for the same reason.
>
> On Thu, Jun 22, 2023 at 3:04 PM Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Apple's native API is Metal, and that's what we are going to use on Mac
>> platforms. If we were to do a Vulkan port it would be for Linux (we use
>> DirectX on Windows). It's certainly something we could consider for the
>> future, but is not a high priority.
>>
>> -- Kevin
>>
>>
>> On 6/22/2023 3:14 AM, Mark Raynsford wrote:
>> > On 2023-06-22T06:56:48 -0300
>> > Thiago Milczarek Sayão  wrote:
>> >
>> >> Hi,
>> >>
>> >> Just curiosity. Would a Vulkan implementation offer any improvement
>> over
>> >> OpenGL in the case of JavaFX?
>> >>
>> >> I see that GTK has a Vulkan pipeline.
>> >>
>> >> Wayland too, it feels so fast and fluid.
>> >>
>> >> And why metal and not Vulkan since it's cross platform and metal isn't?
>> >>
>> >> Warning: It may be a stupid question. :)
>> > I second, third, and fourth this.
>> >
>> > I really don't know why any project is pursuing anything other than a
>> > Vulkan backend for rendering; the tools are better, the API is not
>> > utterly error-prone like OpenGL, and it works on every platform
>> > (assuming the presence of MoltenVK for Apple's walled garden).
>> >
>>
>>

Re: Vulkan

[Nir Lisker]

The Vulkan pipeline option has been brought up several times over the past
years. It's a good addition, but it's a lot of work and there aren't enough
people who volunteered to work on it.

Even "upgrading" the DirectX implementation from 9 to 11 hasn't taken off
for the same reason.

On Thu, Jun 22, 2023 at 3:04 PM Kevin Rushforth 
wrote:

> Apple's native API is Metal, and that's what we are going to use on Mac
> platforms. If we were to do a Vulkan port it would be for Linux (we use
> DirectX on Windows). It's certainly something we could consider for the
> future, but is not a high priority.
>
> -- Kevin
>
>
> On 6/22/2023 3:14 AM, Mark Raynsford wrote:
> > On 2023-06-22T06:56:48 -0300
> > Thiago Milczarek Sayão  wrote:
> >
> >> Hi,
> >>
> >> Just curiosity. Would a Vulkan implementation offer any improvement over
> >> OpenGL in the case of JavaFX?
> >>
> >> I see that GTK has a Vulkan pipeline.
> >>
> >> Wayland too, it feels so fast and fluid.
> >>
> >> And why metal and not Vulkan since it's cross platform and metal isn't?
> >>
> >> Warning: It may be a stupid question. :)
> > I second, third, and fourth this.
> >
> > I really don't know why any project is pursuing anything other than a
> > Vulkan backend for rendering; the tools are better, the API is not
> > utterly error-prone like OpenGL, and it works on every platform
> > (assuming the presence of MoltenVK for Apple's walled garden).
> >
>
>

Integrated: 8180066: Convert package.html files to package-info.java

[Kevin Rushforth]

On Wed, 21 Jun 2023 15:05:47 GMT, Kevin Rushforth  wrote:

> This is a doc cleanup task to convert all `package.html` files to 
> `package-info.java`, which is the recommended way to provide package 
> documentation.
> 
> The first commit is the result of running a shell script that 
> @jonathan-gibbons provided. The second commit removes an errant `` tag 
> from the `package-info.java` for one package, `javafx.util.converter` that is 
> unneeded and unwanted. That same file also had a redundant first sentence, 
> which was coincidentally removed by the tool, so once I removed the `` 
> tag the docs for that package now looks good and matches the other packages. 
> There are no other changes in the javadoc-generated API docs.
> 
> One thing I didn't do is add a ` *` at the beginning of the lines that are 
> now part of a javadoc-style comment block. This minimizes the diffs, but it 
> means we won't be using the usual pattern for those comment blocks. I'm 
> inclined to file a follow-up issue rather than changing that now.

This pull request has now been integrated.

Changeset: c2246159
Author:Kevin Rushforth 
URL:   
https://git.openjdk.org/jfx/commit/c224615991fb0f3647c21786ecd68b78ade4bcb6
Stats: 2982 lines in 68 files changed: 1289 ins; 1649 del; 44 mod

8180066: Convert package.html files to package-info.java

Reviewed-by: angorya

-

PR: https://git.openjdk.org/jfx/pull/1159

Re: RFR: 8273379: GTK3 stops sending key events during drag and drop [v32]

[Thiago Milczarek Sayao]

On Sat, 6 May 2023 21:20:59 GMT, Thiago Milczarek Sayao  
wrote:

>> This PR fixes 8273379.
>> 
>> I reverted back to use GDK (from 
>> [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the 
>> events. 
>> 
>> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
>> 
>> There's also some cleaup.
>> 
>> To do general testing (two tests were added):
>> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
>> 
>> Information for reviewing:
>> * Previously an offscreen window where used to pass events. Now it gets the 
>> window were Drag initially started  
>> (`WindowContextBase::sm_mouse_drag_window`);
>> * There's a new `DragSourceContext` instead of global variables;
>> * DragView were simplified;
>> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test 
>> case for this - It should happen when another window grabs the device during 
>> the drag);
>> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` 
>> will notify java about the button release and set `DnDGesture` to null 
>> before the end of the DND.
>> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be 
>> ignored (as it would "steal" destination motion events);
>> * The Scenario were the drag source window closes during the drag is now 
>> covered;
>> * It does not rely on `gdk_threads_add_idle` because it may be inconsistent.
>> 
>> 
>> ![image](https://user-images.githubusercontent.com/30704286/213877115-18f274ff-18c9-4d38-acc4-449f24174ecc.png)
>> ![image](https://user-images.githubusercontent.com/30704286/213877140-1d24c293-d70f-46e6-b040-c49170d2aa9a.png)
>
> Thiago Milczarek Sayao has updated the pull request with a new target base 
> due to a merge or a rebase. The pull request now contains 78 commits:
> 
>  - Merge branch 'master' into 8273379-dnd-keys
>  - Merge branch 'master' into 8273379-dnd-keys
>  - Merge branch 'master' into 8273379-dnd-keys
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'openjdk:master' into master
>  - ... and 68 more: https://git.openjdk.org/jfx/compare/c50ce609...53ee86e8

Since it makes sense to not send key events during DND, I'm closing it.

-

PR Comment: https://git.openjdk.org/jfx/pull/986#issuecomment-1602517385

Withdrawn: 8273379: GTK3 stops sending key events during drag and drop

[Thiago Milczarek Sayao]

On Tue, 27 Dec 2022 13:19:06 GMT, Thiago Milczarek Sayao  
wrote:

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from 
> [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> To do general testing (two tests were added):
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
> 
> Information for reviewing:
> * Previously an offscreen window where used to pass events. Now it gets the 
> window were Drag initially started  
> (`WindowContextBase::sm_mouse_drag_window`);
> * There's a new `DragSourceContext` instead of global variables;
> * DragView were simplified;
> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test 
> case for this - It should happen when another window grabs the device during 
> the drag);
> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` 
> will notify java about the button release and set `DnDGesture` to null before 
> the end of the DND.
> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored 
> (as it would "steal" destination motion events);
> * The Scenario were the drag source window closes during the drag is now 
> covered;
> * It does not rely on `gdk_threads_add_idle` because it may be inconsistent.
> 
> 
> ![image](https://user-images.githubusercontent.com/30704286/213877115-18f274ff-18c9-4d38-acc4-449f24174ecc.png)
> ![image](https://user-images.githubusercontent.com/30704286/213877140-1d24c293-d70f-46e6-b040-c49170d2aa9a.png)

This pull request has been closed without being integrated.

-

PR: https://git.openjdk.org/jfx/pull/986

Re: Vulkan

[Kevin Rushforth]

Apple's native API is Metal, and that's what we are going to use on Mac 
platforms. If we were to do a Vulkan port it would be for Linux (we use 
DirectX on Windows). It's certainly something we could consider for the 
future, but is not a high priority.


-- Kevin


On 6/22/2023 3:14 AM, Mark Raynsford wrote:

On 2023-06-22T06:56:48 -0300
Thiago Milczarek Sayão  wrote:


Hi,

Just curiosity. Would a Vulkan implementation offer any improvement over
OpenGL in the case of JavaFX?

I see that GTK has a Vulkan pipeline.

Wayland too, it feels so fast and fluid.

And why metal and not Vulkan since it's cross platform and metal isn't?

Warning: It may be a stupid question. :)

I second, third, and fourth this.

I really don't know why any project is pursuing anything other than a
Vulkan backend for rendering; the tools are better, the API is not
utterly error-prone like OpenGL, and it works on every platform
(assuming the presence of MoltenVK for Apple's walled garden).

Re: RFR: 8308644: [Linux] Missing mappings for dead keys + Alt Gr [v4]

[Thiago Milczarek Sayao]

On Wed, 24 May 2023 00:54:27 GMT, Thiago Milczarek Sayao  
wrote:

>> This PR adds missing key mappings for dead keys and fixes "Alt Gr" for some 
>> systems.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two 
> additional commits since the last revision:
> 
>  - Forgot test code
>  - Back to hash

Changed the scope of the PR to a minimum more "mergeable" approach.

-

PR Comment: https://git.openjdk.org/jfx/pull/1143#issuecomment-1602495328

Re: RFR: 8308644: [Linux] Simplify and fix small bugs on glass key related events [v5]

[Thiago Milczarek Sayao]

> This PR adds missing key mappings, fixes "Alt Gr" for some systems and cleans 
> `process_key`a little bit.

Thiago Milczarek Sayao has updated the pull request with a new target base due 
to a merge or a rebase. The incremental webrev excludes the unrelated changes 
brought in by the merge/rebase. The pull request contains 16 additional commits 
since the last revision:

 - Minimize changes
 - Merge branch 'master' into gdk_to_glass_key_map
 - Forgot test code
 - Back to hash
 - Revert key lock change because it has different behaviour
 - Revert modifier change + Remove F13 -> F24
 - Remove print statement
 - Use GDK instead of X calls (to ease in a future wayland implementation)
 - Avoid sending unknown key event
 - GDK_META_MASK is not ALT
 - ... and 6 more: https://git.openjdk.org/jfx/compare/af7d366c...aad021a6

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1143/files
  - new: https://git.openjdk.org/jfx/pull/1143/files/06968167..aad021a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1143&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1143&range=03-04

  Stats: 40615 lines in 878 files changed: 12420 ins; 3782 del; 24413 mod
  Patch: https://git.openjdk.org/jfx/pull/1143.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1143/head:pull/1143

PR: https://git.openjdk.org/jfx/pull/1143

Re: Vulkan

[Mark Raynsford]

On 2023-06-22T06:56:48 -0300
Thiago Milczarek Sayão  wrote:

> Hi,
> 
> Just curiosity. Would a Vulkan implementation offer any improvement over
> OpenGL in the case of JavaFX?
> 
> I see that GTK has a Vulkan pipeline.
> 
> Wayland too, it feels so fast and fluid.
> 
> And why metal and not Vulkan since it's cross platform and metal isn't?
> 
> Warning: It may be a stupid question. :)

I second, third, and fourth this.

I really don't know why any project is pursuing anything other than a
Vulkan backend for rendering; the tools are better, the API is not
utterly error-prone like OpenGL, and it works on every platform
(assuming the presence of MoltenVK for Apple's walled garden).

-- 
Mark Raynsford | https://www.io7m.com



pgpiR7Loh5E6E.pgp
Description: OpenPGP digital signature

Vulkan

[Thiago Milczarek Sayão]

Hi,

Just curiosity. Would a Vulkan implementation offer any improvement over
OpenGL in the case of JavaFX?

I see that GTK has a Vulkan pipeline.

Wayland too, it feels so fast and fluid.

And why metal and not Vulkan since it's cross platform and metal isn't?

Warning: It may be a stupid question. :)

-- Thiago