date:20181104

Re: DropShadow effect kills gfx responsiveness OS-wide

2018-11-04 Thread Tom Schindl

I've never seen and don't see it slowing down other applications (I'm on
a MacBook Pro 13'') but I reported the DropShadow slow down and
documented the solution [1].

Tom

[1]
https://openjfx-dev.openjdk.java.narkive.com/I8NIK0db/bad-dropshadow-performance

On 04.11.18 20:22, Nir Lisker wrote:
>>
>> I don't have access to the OpenJDK bug tracker so I can't file a bug
>> report for this
>>
> 
> You can do it at https://bugreport.java.com/bugreport/
> 
> On Sun, Nov 4, 2018 at 9:18 PM Mike Hearn  wrote:
> 
>> I'm on macOS High Sierra with a very new and very high end MacBook Pro.
>>
>> I have a pretty basic GUI that uses translucency fairly aggressively. I
>> added a DropShadow effect to some nodes, which looks great, but to my great
>> surprise this one line of code kills the UI performance not of my app, but
>> other apps on the same machine, specifically:
>>
>>- I can see the frame rate of the dock's zoom animation is lower
>>- Chrome becomes nearly unusable. Opening a new tab goes from nearly
>>instant to sluggish, this is very noticeable if you watch the tab in the
>>tab strip itself expand. It goes from smooth and fast to being able to
>> see
>>the individual frames.
>>
>> Stopping my app immediately restores the other apps to full framerate. So
>> presumably, the DropShadow shader is triggering some slow path not only in
>> JavaFX but the GPU or driver itself. I've experimenting with caching and
>> that speeds up scrolling of nodes with drop shadows in my own app, but the
>> OS-wide slowdown remains.
>>
>> Has anyone seen anything like this before? I'm suspecting that I'll need to
>> render my own drop shadow effect using static bitmaps to work around it.
>>
>> I don't have access to the OpenJDK bug tracker so I can't file a bug report
>> for this and I'm not sure how to reproduce it reliably. It's the first time
>> I noticed it.
>>

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Re: JavaFX 11.0.1-ea+1 release

2018-11-04 Thread Johan Vos

It should.
I have the following:
javafx.version = 11.0.1-ea

Are you using an SDK or maven artifacts? For which platform?

- Johan

On Sun, Nov 4, 2018 at 4:07 PM Michael Paus  wrote:

> My application is reporting the following values for the respective
> properties:
>
> java.runtime.version: 11.0.1+13
> java.class.version: 55.0
> java.version: 11.0.1
> javafx.version: 11
>
> Shouldn't "javafx.version" follow the same naming conventions as used by
> "java.version"?
>
>
> Am 02.11.18 um 09:59 schrieb Johan Vos:
> > Hi,
> >
> > We are about to release JavaFX 11.0.1, containing the fixes that made it
> > into the 11-dev repository.
> > An early-access build for this is available as SDK/jmods at
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
> > <
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
> >
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
> >
> > The maven artifacts are available in the usual repositories, with version
> > tag being "11.0.1-ea+1" e.g.
> >
> > org.openjfx:javafx-base:11.0.1-ea+1 (see
> > http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/
> )
> >
> > If we don't hear major issues with this ea, it should become the 11.0.1
> > release.
> >
> > - Johan
>
>
>

Re: DropShadow effect kills gfx responsiveness OS-wide

2018-11-04 Thread Nir Lisker

>
> I don't have access to the OpenJDK bug tracker so I can't file a bug
> report for this
>

You can do it at https://bugreport.java.com/bugreport/

On Sun, Nov 4, 2018 at 9:18 PM Mike Hearn  wrote:

> I'm on macOS High Sierra with a very new and very high end MacBook Pro.
>
> I have a pretty basic GUI that uses translucency fairly aggressively. I
> added a DropShadow effect to some nodes, which looks great, but to my great
> surprise this one line of code kills the UI performance not of my app, but
> other apps on the same machine, specifically:
>
>- I can see the frame rate of the dock's zoom animation is lower
>- Chrome becomes nearly unusable. Opening a new tab goes from nearly
>instant to sluggish, this is very noticeable if you watch the tab in the
>tab strip itself expand. It goes from smooth and fast to being able to
> see
>the individual frames.
>
> Stopping my app immediately restores the other apps to full framerate. So
> presumably, the DropShadow shader is triggering some slow path not only in
> JavaFX but the GPU or driver itself. I've experimenting with caching and
> that speeds up scrolling of nodes with drop shadows in my own app, but the
> OS-wide slowdown remains.
>
> Has anyone seen anything like this before? I'm suspecting that I'll need to
> render my own drop shadow effect using static bitmaps to work around it.
>
> I don't have access to the OpenJDK bug tracker so I can't file a bug report
> for this and I'm not sure how to reproduce it reliably. It's the first time
> I noticed it.
>

DropShadow effect kills gfx responsiveness OS-wide

2018-11-04 Thread Mike Hearn

I'm on macOS High Sierra with a very new and very high end MacBook Pro.

I have a pretty basic GUI that uses translucency fairly aggressively. I
added a DropShadow effect to some nodes, which looks great, but to my great
surprise this one line of code kills the UI performance not of my app, but
other apps on the same machine, specifically:

   - I can see the frame rate of the dock's zoom animation is lower
   - Chrome becomes nearly unusable. Opening a new tab goes from nearly
   instant to sluggish, this is very noticeable if you watch the tab in the
   tab strip itself expand. It goes from smooth and fast to being able to see
   the individual frames.

Stopping my app immediately restores the other apps to full framerate. So
presumably, the DropShadow shader is triggering some slow path not only in
JavaFX but the GPU or driver itself. I've experimenting with caching and
that speeds up scrolling of nodes with drop shadows in my own app, but the
OS-wide slowdown remains.

Has anyone seen anything like this before? I'm suspecting that I'll need to
render my own drop shadow effect using static bitmaps to work around it.

I don't have access to the OpenJDK bug tracker so I can't file a bug report
for this and I'm not sure how to reproduce it reliably. It's the first time
I noticed it.

Re: Running JavaFX-11 applications from within Eclipse fails

2018-11-04 Thread Tom Schindl

I think the more general problem is that they don‘t run on the module-path - in 
the m2e case this because the modules are transitive deps and those are not 
supported properly

Tom

Von meinem iPhone gesendet

> Am 04.11.2018 um 16:17 schrieb José Pereda :
> 
> I've just noticed that this issue happens not only with Maven but also with
> Gradle projects (Gradle + Eclipse 2018-09 + Windows with Oracle JDK 1.8),
> running gradle tasks from Eclipse.
> 
> The same proposed workaround can be applied to the build file:
> 
> run {
> 
>systemProperty "java.library.path", "C:\tmp"
> 
> }
> 
> 
> 
> 
> On Mon, Oct 22, 2018 at 4:43 PM Kevin Rushforth 
> wrote:
> 
>> 
>>> Renaming the native libraries in JavaFX would probably solve this, but
>> that
>>> seems the wrong solution to me.
>> 
>> Yes, it seems like a workaround rather than a fix...
>> 
>> -- Kevin
>> 
>> 
>>> On 10/21/2018 10:45 AM, Johan Vos wrote:
>>> Hi Tom,
>>> 
>>> Nice workaround, but what do you think needs to be done to fix it? Can
>> the
>>> java.library.path somehow be changed in a plugin or so?
>>> Renaming the native libraries in JavaFX would probably solve this, but
>> that
>>> seems the wrong solution to me.
>>> 
>>> - Johan
>>> 
>>> On Thu, Oct 18, 2018 at 3:39 PM Tom Schindl >> 
>>> wrote:
>>> 
 Hi,
 
 I just wanted to make you aware that if you run a JavaFX-11 application
 from within Eclipse it is very likely that you'll get an error like
>> this.
 
> Exception in thread "WindowsNativeRunloopThread"
 java.lang.NoSuchMethodError: 
> at
 
>> javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native
 Method)
> at
 javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
> at
 
>> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
> at
 javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
>> Method)
> at
 
>> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Exception in thread "JavaFX Application Thread"
 java.lang.NullPointerException
> at
 
>> javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
> at
 
>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
> at
 
>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
> at
 
>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
> at
 
>> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
> at
 javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
>> Method)
> at
 
>> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
> at java.base/java.lang.Thread.run(Thread.java:834)
 Scary right! The reason is that JavaFX-11 is loading the wrong glass.dll
 because Eclipse sets a java.library.path who also contains the
 JVM-Directories used to launch your Eclipse IDE.
 
 The simple work-around is to add
 -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch
 configuration.
 
 Small tiny question on the side: Wouldn't it make sense to version our
 .dlls somehow to match the release eg glass-11.dll?
 
 Tom
 
 --
 Tom Schindl, CTO
 BestSolution.at EDV Systemhaus GmbH
 Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
 Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
 
>> 
>> 
> 
> --

Re: Running JavaFX-11 applications from within Eclipse fails

2018-11-04 Thread José Pereda

I've just noticed that this issue happens not only with Maven but also with
Gradle projects (Gradle + Eclipse 2018-09 + Windows with Oracle JDK 1.8),
running gradle tasks from Eclipse.

The same proposed workaround can be applied to the build file:

run {

systemProperty "java.library.path", "C:\tmp"

}




On Mon, Oct 22, 2018 at 4:43 PM Kevin Rushforth 
wrote:

>
> > Renaming the native libraries in JavaFX would probably solve this, but
> that
> > seems the wrong solution to me.
>
> Yes, it seems like a workaround rather than a fix...
>
> -- Kevin
>
>
> On 10/21/2018 10:45 AM, Johan Vos wrote:
> > Hi Tom,
> >
> > Nice workaround, but what do you think needs to be done to fix it? Can
> the
> > java.library.path somehow be changed in a plugin or so?
> > Renaming the native libraries in JavaFX would probably solve this, but
> that
> > seems the wrong solution to me.
> >
> > - Johan
> >
> > On Thu, Oct 18, 2018 at 3:39 PM Tom Schindl  >
> > wrote:
> >
> >> Hi,
> >>
> >> I just wanted to make you aware that if you run a JavaFX-11 application
> >> from within Eclipse it is very likely that you'll get an error like
> this.
> >>
> >>> Exception in thread "WindowsNativeRunloopThread"
> >> java.lang.NoSuchMethodError: 
> >>>  at
> >>
> javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native
> >> Method)
> >>>  at
> >> javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
> >>>  at
> >>
> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
> >>>  at
> >> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
> Method)
> >>>  at
> >>
> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
> >>>  at java.base/java.lang.Thread.run(Thread.java:834)
> >>> Exception in thread "JavaFX Application Thread"
> >> java.lang.NullPointerException
> >>>  at
> >>
> javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
> >>>  at
> >>
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
> >>>  at
> >>
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
> >>>  at
> >>
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
> >>>  at
> >>
> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
> >>>  at
> >> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
> Method)
> >>>  at
> >>
> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
> >>>  at java.base/java.lang.Thread.run(Thread.java:834)
> >> Scary right! The reason is that JavaFX-11 is loading the wrong glass.dll
> >> because Eclipse sets a java.library.path who also contains the
> >> JVM-Directories used to launch your Eclipse IDE.
> >>
> >> The simple work-around is to add
> >> -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch
> >> configuration.
> >>
> >> Small tiny question on the side: Wouldn't it make sense to version our
> >> .dlls somehow to match the release eg glass-11.dll?
> >>
> >> Tom
> >>
> >> --
> >> Tom Schindl, CTO
> >> BestSolution.at EDV Systemhaus GmbH
> >> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> >>
>
>

--

Re: JavaFX 11.0.1-ea+1 release

2018-11-04 Thread Michael Paus

My application is reporting the following values for the respective 
properties:


java.runtime.version: 11.0.1+13
java.class.version: 55.0
java.version: 11.0.1
javafx.version: 11

Shouldn't "javafx.version" follow the same naming conventions as used by 
"java.version"?



Am 02.11.18 um 09:59 schrieb Johan Vos:

Hi,

We are about to release JavaFX 11.0.1, containing the fixes that made it
into the 11-dev repository.
An early-access build for this is available as SDK/jmods at
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip

http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip

The maven artifacts are available in the usual repositories, with version
tag being "11.0.1-ea+1" e.g.

org.openjfx:javafx-base:11.0.1-ea+1 (see
http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)

If we don't hear major issues with this ea, it should become the 11.0.1
release.

- Johan

Re: DropShadow effect kills gfx responsiveness OS-wide

Re: JavaFX 11.0.1-ea+1 release

Re: DropShadow effect kills gfx responsiveness OS-wide

DropShadow effect kills gfx responsiveness OS-wide

Re: Running JavaFX-11 applications from within Eclipse fails

Re: Running JavaFX-11 applications from within Eclipse fails

Re: JavaFX 11.0.1-ea+1 release

7 matches

Site Navigation

Mail list logo

Footer information