>> JavaFX does not use exclusive full-screen mode. It simulates full
>> screen by using an undecorated window that is exactly the size of the
>> screen. This means that pop-ups, such as those used by ComboBox and
>> content menus, will continue to work (they use separate windows).
>>
>>-- Kevin
>>
Hi Mark,
OK ignore that. I clicked through and looked at your POM.
Best,
Paul
On Sun, 22 Jul 2018 at 13:00, wrote:
> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
Hi Mark,
Are you using the v. latest version maven compiler in your POM?
Best,
Paul
On Sun, 22 Jul 2018 at 13:00, wrote:
> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
1. I have a game which I'm trying to performance tune: I can obviously
monitor how often I'm calling draw (draw rate), but I can't monitor how
often the GPU is actually rendering (FPS) since the PerformanceTracker was
removed from the JDK.
I'm running FX at full speed
Tom's right. Major news. Presumably prism would need to cater for a third
renderer, Metal. What would be the time scales for this? Is this an
opportunity to update the way javafx renderer works? Perhaps a tie in to
Lwjgl is better? They have Vulcan bindings and no doubt will wrap Metal.
But I
"and the desired direction of the Project" - perhaps, Kevin, it would be
worth you taking a few words describing what this "direction" is. We all
know with JFX is currently, but what is the future direction? What are
contributors working towards in the long run? I'm sure we've all got our
own
>We are looking at the possibility of providing a replacement packaging
tool in OpenJDK.
+1 for this. Or something like a Maven Shade build with an exacting set of
dependency exclusions, and Launch4J would accomplish something similar? Has
the advantage that all the other plugins like resources,
V. pleased to say it's working for me. It builds using our current Maven
build ( which is targeted in Maven at JDK 9)
org.apache.maven.plugins
maven-compiler-plugin
3.6.2
1.9
1.9
Excellent! I'll try to get this working for our game later in the week.
Best,
Paul
>* I'm thinking about this issue now because I quite like JavaFX and its
*>* future is clearly as a regular Java library, albeit a big one, distributed
*>* either via (not ideal) an SDK or (better) a set of regular libraries
*>* published to a Maven repository.
*>
+1 for this. (-1 for cross
>I'm not sure I understand the question about platform-specific jar files,
Last time I worked on native specifics (which was to package up RXTX dlls
for different OSs / in 64/32 bit) The easiest solution for pure Maven
builds seemed to be, to package DLLs inside a jar. We then used a profile
to
>If you use gradle or maven, the same should be achieved using e.g.
>dependencies {
>compile 'javafx:javafx.controls:11.0.0'
>}
So does this mean there a plan to offer this as pure Maven build - or will
it require Gradle? If pure Maven, are the native libs going to be packaged
inside a JAR
+1 :)
"This is imo the most important work right now, and a number of people are
working on it.
I am very positive this [both paths] will be realised before the Java 11
release date. "
On 6 April 2018 at 01:21, wrote:
> Send openjfx-dev mailing list
Yes please for some documentation. And the way that Prism renderer fails:
for example if you supply an OpenGL or D3D texture > max GPU texture size
is difficult to deal with.
There should be a set of catchable Prism Renderer errors.
On 2 April 2018 at 13:00,
"I mentioned our intention to make it easier for OpenJFX to be built,
tested, and run with OpenJDK builds that don't already contain javafx.*
modules."
+1 Great
I think ref: numbers of developers, the willingness of Oracle to open
JavaFX up to the community has not reached significant numbers. There are a
lot of people who've lost interest in following the framework a long time
ago. If we are going to improve the low level rendering API, (I've a great
+1
* more alignment with mobile
* a clean and lean low-level rendering pipeline API that would allow easier
plugability with upcoming low-level rendering systems
I would like to add a higher level desire
* a consensus that JavaFX will continue to open itself more to integration.
It has a rumour
"I think a discussion on "where we should take the platform" is a good
one to have...just not as part of this thread. "
I'm looking forwards to the new thread :)
Yeah - I looked at the windows build process recently - which was enough to
dissuade me from starting. I do know JavaFX fairly well, and have a potted
history working in software companies. I'd like to get on-board once I
finish my current game. I'd be interested in game related areas; but
realise
Hi OpenJFX -
Anyone point me to a community build for Java9 with JavaFX already added? I
understand I that i can't just overlay one on the other now? I'm seeking
windows right now, but will need to target Linux and Mac in the end.
Best,
Paul
Hi John,
>>>Re: Significant improvements in scene graph rendering speed using modern
game-engine style structures and algorithms.
Agree,
Also, I haven't been feeling the enthusiasm either. It's a mood that's
permeating the user base. You just have to scout YouTube for JavaFX games,
to read the
njfx-dev digest..."
>
>
> Today's Topics:
>
>1. Re: openjfx-dev Digest, Vol 72, Issue 14 (Paul Ray Russell)
>2. [10] Review Request: JDK-8184270 NullPointerException when
> usi
Ref: http://labonnesoupe.org/static/code/
I notice project Decora: are there any plans for JSL shader language
support for JavaFX in the near future?
Thanks,
Best,
Paul
On 14 November 2017 at 12:00, wrote:
> Send openjfx-dev mailing list submissions to
>
23 matches
Mail list logo