[XWayland] Windows show in rendering order

[Craig Raw]

Hi Thiago,

Here is a reproducible example: https://github.com/craigraw/waylandtester

After further investigation, I have found that the following two conditions
need to be true for the issue to occur:

   1. The dialog is owned by the primary stage (with initOwner)
   2. The dialog is sufficiently simple in layout to render quickly

I've added a README on configuring the example accordingly.

Craig

On Tue, Sep 10, 2024 at 12:38 PM Thiago Milczarek Sayão <
thiago.sayao at gmail.com> wrote:

> Hi Craig,
>
> Could you provide a reproducible example?
>
> You are describing default wayland behaviour, which is to only show the
> surface on screen when it has a buffer.
>
> One solution might be to show an initial background on the window.
>
> I don't discard the possibility of a bug, so the reproducible example
> would help.
>
> -- Thiago.
>
>
>
> Em ter., 10 de set. de 2024 às 06:22, Craig Raw <craigraw at gmail.com>
> escreveu:
>
>> I have noticed a regression in JavaFX 22 (that was not present in JavaFX
>> 18) on XWayland.
>>
>> For JavaFX apps running on XWayland, Window.show() returns almost
>> immediately, before the window has been rendered onscreen. This has the
>> effect that if multiple windows are shown consecutively, the z order of
>> these windows is determined by the complexity of rendering, not by the
>> order in which show() was called on each. A practical example of this is
>> showing the primary stage, followed by a dialog during application startup.
>> The dialog, being simpler, will appear under the primary stage (despite it
>> being modal, and owned by the primary stage) as it renders quicker. The
>> application in this case appears unresponsive, requiring input on the
>> hidden modal dialog.
>>
>> There appears to be no way to programmatically determine whether a window
>> has been rendered or not, so I'm not aware of any workarounds to this
>> issue, apart from introducing a long fixed delay between calling show()
>> methods and hoping it is long enough :(
>>
>> Craig
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240910/c0ee0f6a/attachment.htm>