Re: FXCanvas in a Java9 world

[Kevin Rushforth]

The JBS bug is here:

https://bugs.openjdk.java.net/browse/JDK-8131888

-- Kevin


Tom Schindl wrote:

Hi,

This is just a short notice for those who require FXCanvas to integrate
their applications in an existing SWT-Application - most notably Eclipse
RCP or Eclipse IDE.

I've created an defect in the Eclipse Bugtracking System [1] so that you
can subscribe to it if you want to follow how this is proceeding. Not
sure there's an explicit JBS-Entry already but Kevin might be able to
point me towards it.

Tom

[1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428

  

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Stefan Fuchs]

Hi Kevin,

well, removing libjfxwebkit.dylib from dmg files would definitely break 
our application, as we heavily rely on WebView.
Our application is not distributed via Mac App Store, but as a download 
from our website.


I think removing libjfxwebkit.dylib from the dmg should be an opt-in for 
users, that want to upload their application to the Mac App Store.


Stefan


Yes, this is correct. We consider this only a short term workaround 
for the problem. A longer term solution will be needed that will allow 
distributing WebView applications.


Chris: is there a way to override this behavior?

-- Kevin


Dr. Michael Paus wrote:
Just in order to better understand this issue and the fix. Does this 
mean that the packager
will now ALWAYS delete the libjfxwebkit.dylib when building a DMG 
file? That would mean
that I could not bundle and distribute any application anymore for 
the Mac which uses
a WebView. Have you considered the fact that many people do bundle 
their apps but
have their own distribution channels and do not upload the apps to 
the Apple store.

There should at least be some switch to override this behavior.
Just my 2+1/2 cents.
Michael




Am 17.11.15 um 18:31 schrieb Kevin Rushforth:

[taking awt-dev off of this thread]

The fix that was put into 8u72-b02 is that the packager will no 
longer include libjfxwebkit.dylib in the packaged app. Is this not 
working correctly?


-- Kevin


Sergey Bylokhov wrote:
I think openjfx-dev@openjdk.java.net (cc) is correct place to ask 
this question.


On 16.11.15 23:10, Ondřej Kvasnovský wrote:

Hi,

We are facing to an issue with latest Java updates when we try to
release apps into Apple app store. I have described the issue 
here, with

all my findings:
http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html 



In short, the issue is that we are not able to release Java app 
into app

store since 1.8_60 because it uses private API (see the link above if
you want to know how to verify that).

I spoke about this issue with Martijn Verburg and he pointed me to 
these

two issues:
https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72
https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix 
for 9

(replace private libs with public ones)

I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from
https://jdk8.java.net/download.html):
otool -L
/Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib 


| grep icu
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current
version 51.1.0)
And it the issue is still there, Build b05 still references 
private API.


I could even try to build and app and try to publish it for code 
review

by Apple... but since there is this reference, I do not believe it is
going to be successful.

Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is
considered to be fixed, but it seems it is not, could someone help 
with

that?


Best wishes,
Ondrej Kvasnovsky

FXCanvas in a Java9 world

[Tom Schindl]

Hi,

This is just a short notice for those who require FXCanvas to integrate
their applications in an existing SWT-Application - most notably Eclipse
RCP or Eclipse IDE.

I've created an defect in the Eclipse Bugtracking System [1] so that you
can subscribe to it if you want to follow how this is proceeding. Not
sure there's an explicit JBS-Entry already but Kevin might be able to
point me towards it.

Tom

[1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428

-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Danno Ferrin]

We never remove it from a .dmg.  Only if it is a .pkg targeting the Mac App 
Store do we remove it.


> On Nov 17, 2015, at 3:57 PM, Stefan Fuchs  wrote:
> 
> Hi Kevin,
> 
> well, removing libjfxwebkit.dylib from dmg files would definitely break our 
> application, as we heavily rely on WebView.
> Our application is not distributed via Mac App Store, but as a download from 
> our website.
> 
> I think removing libjfxwebkit.dylib from the dmg should be an opt-in for 
> users, that want to upload their application to the Mac App Store.
> 
> Stefan
> 
> 
>> Yes, this is correct. We consider this only a short term workaround for the 
>> problem. A longer term solution will be needed that will allow distributing 
>> WebView applications.
>> 
>> Chris: is there a way to override this behavior?
>> 
>> -- Kevin
>> 
>> 
>> Dr. Michael Paus wrote:
>>> Just in order to better understand this issue and the fix. Does this mean 
>>> that the packager
>>> will now ALWAYS delete the libjfxwebkit.dylib when building a DMG file? 
>>> That would mean
>>> that I could not bundle and distribute any application anymore for the Mac 
>>> which uses
>>> a WebView. Have you considered the fact that many people do bundle their 
>>> apps but
>>> have their own distribution channels and do not upload the apps to the 
>>> Apple store.
>>> There should at least be some switch to override this behavior.
>>> Just my 2+1/2 cents.
>>> Michael
>>> 
>>> 
>>> 
>>> 
>>> Am 17.11.15 um 18:31 schrieb Kevin Rushforth:
 [taking awt-dev off of this thread]
 
 The fix that was put into 8u72-b02 is that the packager will no longer 
 include libjfxwebkit.dylib in the packaged app. Is this not working 
 correctly?
 
 -- Kevin
 
 
 Sergey Bylokhov wrote:
> I think openjfx-dev@openjdk.java.net (cc) is correct place to ask this 
> question.
> 
> On 16.11.15 23:10, Ondřej Kvasnovský wrote:
>> Hi,
>> 
>> We are facing to an issue with latest Java updates when we try to
>> release apps into Apple app store. I have described the issue here, with
>> all my findings:
>> http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html
>>  
>> 
>> In short, the issue is that we are not able to release Java app into app
>> store since 1.8_60 because it uses private API (see the link above if
>> you want to know how to verify that).
>> 
>> I spoke about this issue with Martijn Verburg and he pointed me to these
>> two issues:
>> https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72
>> https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9
>> (replace private libs with public ones)
>> 
>> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from
>> https://jdk8.java.net/download.html):
>> otool -L
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib
>>  
>> | grep icu
>> /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current
>> version 51.1.0)
>> And it the issue is still there, Build b05 still references private API.
>> 
>> I could even try to build and app and try to publish it for code review
>> by Apple... but since there is this reference, I do not believe it is
>> going to be successful.
>> 
>> Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is
>> considered to be fixed, but it seems it is not, could someone help with
>> that?
>> 
>> 
>> Best wishes,
>> Ondrej Kvasnovsky
> 
> 
>>> 
>> 
> 

[Review request] 8097917: add a pulse listener facility

[Jonathan Giles]

Hi all,

Please review the new API proposal for a pulse listener API on Scene at 
the URL below. The proposed patch file is attached to the jira issue.


https://bugs.openjdk.java.net/browse/JDK-8097917

Thanks,
-- Jonathan

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Kevin Rushforth]

[moving this back to the openjfx alias; Bcc awt-dev]

The javapackager fix for JDK 8u72 does exactly this when generating .pkg 
files. So in short, libjfxwebkit.dylib is unchanged for 8u72, but will 
be excluded when generating an app for the Apple app store.


-- Kevin



Michael Hall wrote:
On Nov 16, 2015, at 2:10 PM, Ondřej Kvasnovský 
> wrote:




I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded 
from https://jdk8.java.net/download.html):
otool -L 
/Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib 
| grep icu


Would a work-around not being implement the current recommended fix 
yourself. Move this aside while you package or app and then put it 
back. Or a little more extreme, just delete it.
I’m not that familiar with packager yet, do you know this is the jdk 
that will be used by it for embedding?


Michael Hall

How to modify this mail list subscription?

[Victor Grazi]

Does anyone know how to modify this mail list subscription?
Thanks
Victor

Stage.Min/MaxWidth/Height don't scale

[Chris Nahr]

On Windows the minimum & maximum size properties of Stage don't scale to 
the current DPI settings, unlike all other drawing coordinates. The 
explicit size properties (setWidth/setHeight) do scale but setMinWidth, 
setMaxWidth, setMinHeight & setMaxHeight were apparently overlooked. Any 
values passed to them are interpreted as unscaled pixels.


Below I've added a short sample program to demonstrate the issue. 
Minimum size should just cover the drawn rectangle plus margins, and 
maximum size should be twice as big. But running at 200% DPI the 
*maximum* size will just cover the rectangle whereas the minimum size 
will show only a fraction of the rectangle.


(I'd file a bug report but my JIRA account didn't transition to the new 
bug tracking system, probably because I'm not an OpenJDK contributor.)


-- Chris

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.layout.StackPane;
import javafx.scene.shape.Rectangle;
import javafx.stage.Stage;

public class StageSizeTest extends Application {

@Override
public void start(Stage primaryStage) {

// draw scene-filling rectangle with margin
final int margin = 10, size = 200;
Rectangle rect = new Rectangle(margin, margin, size, size);
StackPane root = new StackPane(rect);
final int sceneSize = size + 2 * margin;
Scene scene = new Scene(root, sceneSize, sceneSize);

// add extra margin for non-client area
final int stageSize = sceneSize + 3 * margin;
primaryStage.setMinWidth(stageSize);
primaryStage.setMinHeight(stageSize);
primaryStage.setMaxWidth(2 * stageSize);
primaryStage.setMaxHeight(2 * stageSize);

primaryStage.setTitle("Stage Size Test");
primaryStage.setScene(scene);
primaryStage.show();
}

public static void main(String[] args) {
launch(args);
}
}

Re: Stage.Min/MaxWidth/Height don't scale

[Kevin Rushforth]

Hi Chris,

Application developers can file bugs here:

http://bugs.java.com/

Thanks.

-- Kevin


Chris Nahr wrote:
On Windows the minimum & maximum size properties of Stage don't scale 
to the current DPI settings, unlike all other drawing coordinates. The 
explicit size properties (setWidth/setHeight) do scale but 
setMinWidth, setMaxWidth, setMinHeight & setMaxHeight were apparently 
overlooked. Any values passed to them are interpreted as unscaled pixels.


Below I've added a short sample program to demonstrate the issue. 
Minimum size should just cover the drawn rectangle plus margins, and 
maximum size should be twice as big. But running at 200% DPI the 
*maximum* size will just cover the rectangle whereas the minimum size 
will show only a fraction of the rectangle.


(I'd file a bug report but my JIRA account didn't transition to the 
new bug tracking system, probably because I'm not an OpenJDK 
contributor.)


-- Chris

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.layout.StackPane;
import javafx.scene.shape.Rectangle;
import javafx.stage.Stage;

public class StageSizeTest extends Application {

@Override
public void start(Stage primaryStage) {

// draw scene-filling rectangle with margin
final int margin = 10, size = 200;
Rectangle rect = new Rectangle(margin, margin, size, size);
StackPane root = new StackPane(rect);
final int sceneSize = size + 2 * margin;
Scene scene = new Scene(root, sceneSize, sceneSize);

// add extra margin for non-client area
final int stageSize = sceneSize + 3 * margin;
primaryStage.setMinWidth(stageSize);
primaryStage.setMinHeight(stageSize);
primaryStage.setMaxWidth(2 * stageSize);
primaryStage.setMaxHeight(2 * stageSize);

primaryStage.setTitle("Stage Size Test");
primaryStage.setScene(scene);
primaryStage.show();
}

public static void main(String[] args) {
launch(args);
}
}

Re: How to modify this mail list subscription?

[Kevin Rushforth]

You can control your subscription here:

http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev

-- Kevin


Victor Grazi wrote:

Does anyone know how to modify this mail list subscription?
Thanks
Victor
  

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Dr. Michael Paus]

A lot of the confusion here is probably caused by the fact that I (and 
obviously others too)
did not know about the possibility to distinguish between building for 
the Apple app store
and building a package for self-distribution. Is this distinction made 
by either creating a
DMG for self-distribution or a PKG for the Apple app store or is there 
even some other
switch? I could live with that for the moment but is all this documented 
somewhere?
At least the help function of the javapackager does not even mention the 
possibility

of creating PKG files.

Am 18.11.15 um 14:18 schrieb Kevin Rushforth:

[moving this back to the openjfx alias; Bcc awt-dev]

The javapackager fix for JDK 8u72 does exactly this when generating 
.pkg files. So in short, libjfxwebkit.dylib is unchanged for 8u72, but 
will be excluded when generating an app for the Apple app store.


-- Kevin



Michael Hall wrote:
On Nov 16, 2015, at 2:10 PM, Ondřej Kvasnovský 
> 
wrote:




I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from 
https://jdk8.java.net/download.html):
otool -L 
/Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib 
| grep icu


Would a work-around not being implement the current recommended fix 
yourself. Move this aside while you package or app and then put it 
back. Or a little more extreme, just delete it.
I’m not that familiar with packager yet, do you know this is the jdk 
that will be used by it for embedding?


Michael Hall

Pausing Quantum Renderer

[Johan Vos]

Hi,

On Android, a JavaFX Application might transfer control to another app (and
become invisible) and enter the foreground later. In that case, the
GLSurface we are rendering on becomes invalid. In order to avoid problems
and save battery, we want to pause the renderer thread, but this turns out
to be more difficult than I expected.

When our app transfers control, we get a callback from Android. We
intercept this in javafxports, and we set the Screen width/height to 0/0 as
we don't want to render on the (invalid) surface while we lost control.
When we regain control, we resize the Screen and the app renders again.

The reason we set the width/height to 0/0 is because the PresentingPainter
will call SceneState.isValid() and this returns false in case getWidth() or
getHeight() are 0.

However, SceneState extends PresentableState and it overrides the update
method. It will call PresentatbleState.update() which will set the
viewWidth to the width of the new Screen (hence, 0) , but after that it
overwrites the viewWidth with camera.getViewWidth(). The latter still
contains the old value. A quick inspection shows that camera.setViewWidth()
is called when validate(...) is called on NGDefaultCamera, which is called
by ES2Context.updateRenderTarget() which happens during rendering, hence
*after* the PresentingPainter checks if the width is 0.

So immediately after we set the width of the Screen to 0 (on the FX App
Thread), a Pulse happens, and this one still things the screen is the
original size. While the pulse is happening, the android system destroys
our context, and the rendering fails. Moreover, the EGL system is in a
unpredictable state (recreating the surface fails).

A very dirty workaround for this is to wait for 1 pulse (with the new
pulselistener API this should be possible) before we return from the
callback method called by Android when the surface is about to be
destroyed. That way, we will have 1 bogus rendering on an existing (but
about-to-be-destroyed) surface.

But it would be better if there is some way to tell the quantum renderer to
immediately stop rendering. Existing pulses are no problem, as the
renderLock guarantuees that we set the size to 0 only when no other thread
(quantum renderer) has a lock on the renderLock.

- Johan

Re: Pausing Quantum Renderer

[Alexander Kouznetsov]

Shouldn't this be an equivalent of minimizing the window?

Best regards,
Alexander Kouznetsov
(408) 276-0387

On 18 ноя 2015 12:45, Johan Vos wrote:

Hi,

On Android, a JavaFX Application might transfer control to another app (and
become invisible) and enter the foreground later. In that case, the
GLSurface we are rendering on becomes invalid. In order to avoid problems
and save battery, we want to pause the renderer thread, but this turns out
to be more difficult than I expected.

When our app transfers control, we get a callback from Android. We
intercept this in javafxports, and we set the Screen width/height to 0/0 as
we don't want to render on the (invalid) surface while we lost control.
When we regain control, we resize the Screen and the app renders again.

The reason we set the width/height to 0/0 is because the PresentingPainter
will call SceneState.isValid() and this returns false in case getWidth() or
getHeight() are 0.

However, SceneState extends PresentableState and it overrides the update
method. It will call PresentatbleState.update() which will set the
viewWidth to the width of the new Screen (hence, 0) , but after that it
overwrites the viewWidth with camera.getViewWidth(). The latter still
contains the old value. A quick inspection shows that camera.setViewWidth()
is called when validate(...) is called on NGDefaultCamera, which is called
by ES2Context.updateRenderTarget() which happens during rendering, hence
*after* the PresentingPainter checks if the width is 0.

So immediately after we set the width of the Screen to 0 (on the FX App
Thread), a Pulse happens, and this one still things the screen is the
original size. While the pulse is happening, the android system destroys
our context, and the rendering fails. Moreover, the EGL system is in a
unpredictable state (recreating the surface fails).

A very dirty workaround for this is to wait for 1 pulse (with the new
pulselistener API this should be possible) before we return from the
callback method called by Android when the surface is about to be
destroyed. That way, we will have 1 bogus rendering on an existing (but
about-to-be-destroyed) surface.

But it would be better if there is some way to tell the quantum renderer to
immediately stop rendering. Existing pulses are no problem, as the
renderLock guarantuees that we set the size to 0 only when no other thread
(quantum renderer) has a lock on the renderLock.

- Johan

Re: Pausing Quantum Renderer

[Jim Graham]

And, even if it isn't, shouldn't we have a concept of "you can't draw 
right now, just go away and we'll tell you when it's available again" 
built into the Presentable API?  You shouldn't have to set the 
dimensions to 0,0 to mean "I'm not here right now"...


...jim

On 11/18/15 5:02 PM, Alexander Kouznetsov wrote:

Shouldn't this be an equivalent of minimizing the window?

Best regards,
Alexander Kouznetsov
(408) 276-0387

On 18 ноя 2015 12:45, Johan Vos wrote:

Hi,

On Android, a JavaFX Application might transfer control to another app
(and
become invisible) and enter the foreground later. In that case, the
GLSurface we are rendering on becomes invalid. In order to avoid problems
and save battery, we want to pause the renderer thread, but this turns
out
to be more difficult than I expected.

When our app transfers control, we get a callback from Android. We
intercept this in javafxports, and we set the Screen width/height to
0/0 as
we don't want to render on the (invalid) surface while we lost control.
When we regain control, we resize the Screen and the app renders again.

The reason we set the width/height to 0/0 is because the
PresentingPainter
will call SceneState.isValid() and this returns false in case
getWidth() or
getHeight() are 0.

However, SceneState extends PresentableState and it overrides the update
method. It will call PresentatbleState.update() which will set the
viewWidth to the width of the new Screen (hence, 0) , but after that it
overwrites the viewWidth with camera.getViewWidth(). The latter still
contains the old value. A quick inspection shows that
camera.setViewWidth()
is called when validate(...) is called on NGDefaultCamera, which is
called
by ES2Context.updateRenderTarget() which happens during rendering, hence
*after* the PresentingPainter checks if the width is 0.

So immediately after we set the width of the Screen to 0 (on the FX App
Thread), a Pulse happens, and this one still things the screen is the
original size. While the pulse is happening, the android system destroys
our context, and the rendering fails. Moreover, the EGL system is in a
unpredictable state (recreating the surface fails).

A very dirty workaround for this is to wait for 1 pulse (with the new
pulselistener API this should be possible) before we return from the
callback method called by Android when the surface is about to be
destroyed. That way, we will have 1 bogus rendering on an existing (but
about-to-be-destroyed) surface.

But it would be better if there is some way to tell the quantum
renderer to
immediately stop rendering. Existing pulses are no problem, as the
renderLock guarantuees that we set the size to 0 only when no other
thread
(quantum renderer) has a lock on the renderLock.

- Johan