Blank stages when running JavaFX app in a macOS virtual machine

[Michael Paus]

Hi,
maybe you lost the response mail or it went into your trash.
I guess this is your bug report in the JBS.
https://bugs.openjdk.java.net/browse/JDK-8235627
--Michael

Am 10.12.19 um 11:33 schrieb thevenet.fred at free.fr:
> Hi,
>
> I've submitted bug report via https://bugreport.java.com/bugreport/ regarding the issue below about a week ago but I haven't heard from it yet.
> I understand this might not be the best place to inquire about it, but since this prevents me from submitting a PR (as I don't have an issue number) I was hoping someone here could offer some guidance on how to get this moving forward.
>
> Many thanks,
> Fred.
>
> ----- Mail original -----
> De: "thevenet fred" <thevenet.fred at free.fr>
> À: "Kevin Rushforth" <kevin.rushforth at oracle.com>
> Cc: "openjfx-dev" <openjfx-dev at openjdk.java.net>
> Envoyé: Mardi 3 Décembre 2019 18:46:57
> Objet: 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" <kevin.rushforth at oracle.com>
> À: "openjfx-dev" <openjfx-dev at openjdk.java.net>
> 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.fred at 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, &pix, &npix);
>> 096: if ((err == kCGLNoError) && (npix == 0))
>> 097: {
>> 098:   const CGLPixelFormatAttribute attributes2[] =
>> 099:   {
>> 100:     kCGLPFAAllowOfflineRenderers,
>> 101:     (CGLPixelFormatAttribute)0
>> 102:   };
>> 103:   err = CGLChoosePixelFormat(attributes2, &pix, &npix);
>> 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&page=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