RE: Blank stages when running JavaFX app in a macOS virtual machine
In this precise case, it is kCGLPFAAccelerated
Regards
Frederic Thevenet
-Original Message-
From: Sergey Bylokhov [mailto:sergey.bylok...@oracle.com]
Sent: 03 December 2019 21:20
To: thevenet.f...@free.fr; openjfx-dev
Subject: Re: Blank stages when running JavaFX app in a macOS virtual machine
Just curious what attribute caused the first request to fail.
Is it related to kCGLPFAAccelerated or XXXSize?
87 kCGLPFAAccelerated,
88 kCGLPFAColorSize, 32,
89 kCGLPFAAlphaSize, 8,
90 kCGLPFADepthSize, depth,
91 kCGLPFAAllowOfflineRenderers, // lets OpenGL know this context is
offline renderer aware
92 (CGLPixelFormatAttribute)0
On 12/3/19 7:11 am, thevenet.f...@free.fr wrote:
> Hello,
>
> When running a JavaFX application in macOS guest VM, the main stage is
> completely blank, with the following errors: CGLChoosePixelFormat error:
> 10002, CGLCreateContext error: 10002 This behavior was observed with a macOS
> 10.15 guest OS on both VMWare player and VirtualBox, on a Windows 10 host.
>
> This is an old issue that has already been reported several times (notably as
> JDK-8154852) but is claimed to have been fixed by JDK-8154148.
> However the fix provided by JDK-8154148 is incomplete; while it does fix a
> JVM crash, it doesn't prevent an incorrect pixel format to be retrieved,
> which is the root cause for the stage being empty.
>
> The problematic code is located at #96 in GlassView3D.m:
>
> 095: CGLError err = CGLChoosePixelFormat(attributes, , );
> 096: if ((err == kCGLNoError) && (npix == 0))
> 097: {
> 098: const CGLPixelFormatAttribute attributes2[] =
> 099: {
> 100: kCGLPFAAllowOfflineRenderers,
> 101: (CGLPixelFormatAttribute)0
> 102: };
> 103: err = CGLChoosePixelFormat(attributes2, , );
> 104: }
>
>
> In a comment in JDK-8154148, the following claim is made: "[...] an
> error happens is when something bad or invalid has occurred. An
> unsatisfied pixel format request is indicated by npix is 0 and pix is
> NULL. Hence I feel it is a cleaner and clearer logic to request a
> different format when npix is 0 and err is kCGLNoError."
> (https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=139
> 80465=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-t
> abpanel#comment-13980465)
>
> From what I could observe, this is not necessarily true; in this case where
> a pixel format satisfying the initial conditions could not be found, the
> return code is kCGLBadPixelFormat (10002); which means we don't try to get a
> pixel format with less restrictive condition.
> This suggests that a better condition for the second call to
> CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if
> ((err == kCGLNoError) && (npix == 0))"
> This is further supported by a sample in Apple developer's
> documentation on how to choose a pixel format:
> https://developer.apple.com/library/archive/documentation/GraphicsImag
> ing/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelfor
> mats.html
>
> I have verified that this change produces the expected behavior and I
> propose to submit a PR with this change (I have already signed the
> OCA)
>
> A quick question before I do, however; should I file a new issue prior to
> submitting a PR or is it better that someone with privileges reopens
> JDK-8154148?
>
> Regards,
>
> Frederic Thevenet
>
--
Best regards, Sergey.
Re: RFR: 8235150: IosApplication does not pass the required object in _leaveNestedEventLoopImpl
On Sun, 1 Dec 2019 16:31:39 GMT, Johan Vos wrote: > On Sat, 30 Nov 2019 18:23:07 GMT, Jose Pereda wrote: > >> In `GlassApplication.m` for iOS, the method >> `Java_com_sun_glass_ui_ios_IosApplication__1leaveNestedEventLoopImpl` has >> signature `(Ljava/lang/Object;)V`, however in `IosApplication.java`, >> `_leaveNestedEventLoopImpl()` signature doesn't match that. >> >> This PR fixes this. >> >> >> >> Commits: >> - e5fc04a9: Use correct signature in _leaveNestedEventLoopImpl >> >> Changes: https://git.openjdk.java.net/jfx/pull/57/files >> Webrev: https://webrevs.openjdk.java.net/jfx/57/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8235150 >> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >> Patch: https://git.openjdk.java.net/jfx/pull/57.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/57/head:pull/57 > > Looks like a trivial fix to me. > It only impacts the iOS platform. Yes, this looks like a simple, and correct fix. A single reviewer will be sufficient. PR: https://git.openjdk.java.net/jfx/pull/57
Re: RFR: WIP: 8231372: Correctly terminate secondary event loop in JFXPanel.setScene()
On Wed, 13 Nov 2019 20:00:14 GMT, Kevin Rushforth wrote: > On Mon, 21 Oct 2019 22:52:47 GMT, Kevin Rushforth wrote: > >> On Thu, 17 Oct 2019 15:28:31 GMT, Kevin Rushforth wrote: >> >>> On Thu, 17 Oct 2019 15:28:30 GMT, mruzicka >>> wrote: >>> On Thu, 17 Oct 2019 15:28:28 GMT, mruzicka wrote: > Secondary event loop introduced as a means of synchronization with the > JavaFX Application thread in [1] never terminates as the > SecondaryLoop.exit() call is not reached because the thread is blocked in > the SecondaryLoop.enter() call. > This patch fixes the problem by submitting the UI work (including the > call to the SecondaryLoop.exit() method) before entering the secondary > loop. > > [1] > https://github.com/openjdk/jfx/commit/7cf2dfa0b3c5bfd0f1a2de36d46b62f7e9e256c4 > > > > Commits: > - 9483ccde: 8231372: Correctly terminate secondary event loop in > JFXPanel.setScene() > > Changes: https://git.openjdk.java.net/jfx/pull/16/files > Webrev: https://webrevs.openjdk.java.net/jfx/16/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8231372 > Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod > Patch: https://git.openjdk.java.net/jfx/pull/16.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/16/head:pull/16 @kevinrushforth I believe you should be able to move forward with the review of this PR now as I've filed a bug report for the problem and signed the OCA as required. (As I did not know I needed to have my github account associated with the OCA, I did not include it in my details. I've asked Dalibor Topic from the Java SE PM team to help me have that fixed or get in touch with you to confirm my signing of the OCA.) >>> >>> @mruzicka once Dalibor connects your OCA with your GitHub account, this >>> review will be able to proceed. >> >> Do you have a test program that shows the bug? >> >> Also, can you take a look at whether you could turn the test case into an >> automated test? > > @mruzicka - are you interested in moving this forward? If so, there is a > pending request for a test case that needs to be answered before the review > can proceed. Marking as WIP pending a test case to reproduce it. If you are still interested in pursuing this, please let us know. PR: https://git.openjdk.java.net/jfx/pull/16
Re: Blank stages when running JavaFX app in a macOS virtual machine
Just curious what attribute caused the first request to fail.
Is it related to kCGLPFAAccelerated or XXXSize?
87 kCGLPFAAccelerated,
88 kCGLPFAColorSize, 32,
89 kCGLPFAAlphaSize, 8,
90 kCGLPFADepthSize, depth,
91 kCGLPFAAllowOfflineRenderers, // lets OpenGL know this context is
offline renderer aware
92 (CGLPixelFormatAttribute)0
On 12/3/19 7:11 am, thevenet.f...@free.fr wrote:
Hello,
When running a JavaFX application in macOS guest VM, the main stage is
completely blank, with the following errors: CGLChoosePixelFormat error: 10002,
CGLCreateContext error: 10002
This behavior was observed with a macOS 10.15 guest OS on both VMWare player
and VirtualBox, on a Windows 10 host.
This is an old issue that has already been reported several times (notably as
JDK-8154852) but is claimed to have been fixed by JDK-8154148.
However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM
crash, it doesn't prevent an incorrect pixel format to be retrieved, which is
the root cause for the stage being empty.
The problematic code is located at #96 in GlassView3D.m:
095: CGLError err = CGLChoosePixelFormat(attributes, , );
096: if ((err == kCGLNoError) && (npix == 0))
097: {
098: const CGLPixelFormatAttribute attributes2[] =
099: {
100: kCGLPFAAllowOfflineRenderers,
101: (CGLPixelFormatAttribute)0
102: };
103: err = CGLChoosePixelFormat(attributes2, , );
104: }
In a comment in JDK-8154148, the following claim is made: "[...] an error happens is
when something bad or invalid has occurred. An unsatisfied pixel format request is indicated
by npix is 0 and pix is NULL. Hence I feel it is a cleaner and clearer logic to request a
different format when npix is 0 and err is kCGLNoError."
(https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)
From what I could observe, this is not necessarily true; in this case where a
pixel format satisfying the initial conditions could not be found, the return
code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel
format with less restrictive condition.
This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be
"if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
This is further supported by a sample in Apple developer's documentation on how
to choose a pixel format:
https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html
I have verified that this change produces the expected behavior and I propose
to submit a PR with this change (I have already signed the OCA)
A quick question before I do, however; should I file a new issue prior to
submitting a PR or is it better that someone with privileges reopens
JDK-8154148?
Regards,
Frederic Thevenet
--
Best regards, Sergey.
Re: Blank stages when running JavaFX app in a macOS virtual machine
Ok thanks, will do that.
Regards,
Frederic Thevenet
- Mail original -
De: "Kevin Rushforth"
À: "openjfx-dev"
Envoyé: Mardi 3 Décembre 2019 18:35:49
Objet: Re: Blank stages when running JavaFX app in a macOS virtual machine
A new follow-on bug ID will be needed. We never reopen a JBS issue once
it has been resolved as fixed by a changeset that has been pushed.
-- Kevin
On 12/3/2019 7:11 AM, thevenet.f...@free.fr wrote:
> Hello,
>
> When running a JavaFX application in macOS guest VM, the main stage is
> completely blank, with the following errors: CGLChoosePixelFormat error:
> 10002, CGLCreateContext error: 10002
> This behavior was observed with a macOS 10.15 guest OS on both VMWare player
> and VirtualBox, on a Windows 10 host.
>
> This is an old issue that has already been reported several times (notably as
> JDK-8154852) but is claimed to have been fixed by JDK-8154148.
> However the fix provided by JDK-8154148 is incomplete; while it does fix a
> JVM crash, it doesn't prevent an incorrect pixel format to be retrieved,
> which is the root cause for the stage being empty.
>
> The problematic code is located at #96 in GlassView3D.m:
>
> 095: CGLError err = CGLChoosePixelFormat(attributes, , );
> 096: if ((err == kCGLNoError) && (npix == 0))
> 097: {
> 098: const CGLPixelFormatAttribute attributes2[] =
> 099: {
> 100: kCGLPFAAllowOfflineRenderers,
> 101: (CGLPixelFormatAttribute)0
> 102: };
> 103: err = CGLChoosePixelFormat(attributes2, , );
> 104: }
>
>
> In a comment in JDK-8154148, the following claim is made: "[...] an error
> happens is when something bad or invalid has occurred. An unsatisfied pixel
> format request is indicated by npix is 0 and pix is NULL. Hence I feel it is
> a cleaner and clearer logic to request a different format when npix is 0 and
> err is kCGLNoError."
> (https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)
>
> From what I could observe, this is not necessarily true; in this case where
> a pixel format satisfying the initial conditions could not be found, the
> return code is kCGLBadPixelFormat (10002); which means we don't try to get a
> pixel format with less restrictive condition.
> This suggests that a better condition for the second call to
> CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if
> ((err == kCGLNoError) && (npix == 0))"
> This is further supported by a sample in Apple developer's documentation on
> how to choose a pixel format:
> https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html
>
> I have verified that this change produces the expected behavior and I propose
> to submit a PR with this change (I have already signed the OCA)
>
> A quick question before I do, however; should I file a new issue prior to
> submitting a PR or is it better that someone with privileges reopens
> JDK-8154148?
>
> Regards,
>
> Frederic Thevenet
Re: Blank stages when running JavaFX app in a macOS virtual machine
A new follow-on bug ID will be needed. We never reopen a JBS issue once
it has been resolved as fixed by a changeset that has been pushed.
-- Kevin
On 12/3/2019 7:11 AM, thevenet.f...@free.fr wrote:
Hello,
When running a JavaFX application in macOS guest VM, the main stage is
completely blank, with the following errors: CGLChoosePixelFormat error: 10002,
CGLCreateContext error: 10002
This behavior was observed with a macOS 10.15 guest OS on both VMWare player
and VirtualBox, on a Windows 10 host.
This is an old issue that has already been reported several times (notably as
JDK-8154852) but is claimed to have been fixed by JDK-8154148.
However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM
crash, it doesn't prevent an incorrect pixel format to be retrieved, which is
the root cause for the stage being empty.
The problematic code is located at #96 in GlassView3D.m:
095: CGLError err = CGLChoosePixelFormat(attributes, , );
096: if ((err == kCGLNoError) && (npix == 0))
097: {
098: const CGLPixelFormatAttribute attributes2[] =
099: {
100: kCGLPFAAllowOfflineRenderers,
101: (CGLPixelFormatAttribute)0
102: };
103: err = CGLChoosePixelFormat(attributes2, , );
104: }
In a comment in JDK-8154148, the following claim is made: "[...] an error happens is
when something bad or invalid has occurred. An unsatisfied pixel format request is indicated
by npix is 0 and pix is NULL. Hence I feel it is a cleaner and clearer logic to request a
different format when npix is 0 and err is kCGLNoError."
(https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)
From what I could observe, this is not necessarily true; in this case where a
pixel format satisfying the initial conditions could not be found, the return
code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel
format with less restrictive condition.
This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be
"if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
This is further supported by a sample in Apple developer's documentation on how
to choose a pixel format:
https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html
I have verified that this change produces the expected behavior and I propose
to submit a PR with this change (I have already signed the OCA)
A quick question before I do, however; should I file a new issue prior to
submitting a PR or is it better that someone with privileges reopens
JDK-8154148?
Regards,
Frederic Thevenet
Blank stages when running JavaFX app in a macOS virtual machine
Hello,
When running a JavaFX application in macOS guest VM, the main stage is
completely blank, with the following errors: CGLChoosePixelFormat error: 10002,
CGLCreateContext error: 10002
This behavior was observed with a macOS 10.15 guest OS on both VMWare player
and VirtualBox, on a Windows 10 host.
This is an old issue that has already been reported several times (notably as
JDK-8154852) but is claimed to have been fixed by JDK-8154148.
However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM
crash, it doesn't prevent an incorrect pixel format to be retrieved, which is
the root cause for the stage being empty.
The problematic code is located at #96 in GlassView3D.m:
095: CGLError err = CGLChoosePixelFormat(attributes, , );
096: if ((err == kCGLNoError) && (npix == 0))
097: {
098: const CGLPixelFormatAttribute attributes2[] =
099: {
100: kCGLPFAAllowOfflineRenderers,
101: (CGLPixelFormatAttribute)0
102: };
103: err = CGLChoosePixelFormat(attributes2, , );
104: }
In a comment in JDK-8154148, the following claim is made: "[...] an error
happens is when something bad or invalid has occurred. An unsatisfied pixel
format request is indicated by npix is 0 and pix is NULL. Hence I feel it is a
cleaner and clearer logic to request a different format when npix is 0 and err
is kCGLNoError."
(https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)
>From what I could observe, this is not necessarily true; in this case where a
>pixel format satisfying the initial conditions could not be found, the return
>code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel
>format with less restrictive condition.
This suggests that a better condition for the second call to
CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if
((err == kCGLNoError) && (npix == 0))"
This is further supported by a sample in Apple developer's documentation on how
to choose a pixel format:
https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html
I have verified that this change produces the expected behavior and I propose
to submit a PR with this change (I have already signed the OCA)
A quick question before I do, however; should I file a new issue prior to
submitting a PR or is it better that someone with privileges reopens
JDK-8154148?
Regards,
Frederic Thevenet
Re: [Integrated] RFR: 8211308: Support HTTP/2 in WebView
Changeset: 98035cb2 Author:Arunprasad Rajkumar Date: 2019-12-03 08:24:01 + URL: https://git.openjdk.java.net/jfx/commit/98035cb2 8211308: Support HTTP/2 in WebView Reviewed-by: ghb, kcr ! modules/javafx.web/src/main/java/com/sun/webkit/network/ByteBufferPool.java + modules/javafx.web/src/main/java/com/sun/webkit/network/HTTP2Loader.java ! modules/javafx.web/src/main/java/com/sun/webkit/network/NetworkContext.java ! modules/javafx.web/src/main/java/com/sun/webkit/network/URLLoader.java + modules/javafx.web/src/main/java/com/sun/webkit/network/URLLoaderBase.java ! modules/javafx.web/src/main/java/module-info.java ! modules/javafx.web/src/main/native/Source/WebCore/mapfile-macosx ! modules/javafx.web/src/main/native/Source/WebCore/mapfile-vers ! modules/javafx.web/src/main/native/Source/WebCore/platform/java/IDNJava.cpp ! modules/javafx.web/src/main/native/Source/WebCore/platform/network/ResourceHandle.h ! modules/javafx.web/src/main/native/Source/WebCore/platform/network/ResourceHandleInternal.h ! modules/javafx.web/src/main/native/Source/WebCore/platform/network/java/ResourceHandleJava.cpp ! modules/javafx.web/src/main/native/Source/WebCore/platform/network/java/URLLoader.cpp ! modules/javafx.web/src/main/native/Source/WebCore/platform/network/java/URLLoader.h
