Are there real world cases (apart from tests) that have multiple Display instances over the lifetime of the process?

[jonahgraham]

There are two ways to interpret this question, and I am looking for answers for both.

1. from the Display Javadoc "some platforms do not support creating a new display if one already exists" - macOS/GTK explicitly ban this, and Windows allows it. But in practice, does anyone have multiple Display instances (multiple main threads) active simultaneously?
2. does anyone have a lifecycle for their application that after disposing a Display they create another Display? (Tests do this all the time, but do applications?)
3. Related question. Does anyone have an application life cycle that creates a native display (whatever the equivalent may be) and an SWT display in the same process, either simultaneously or serially?

I closed this corner case #2675 in part because I assumed that no one is really doing item 2 or 3 on GTK and, after sleeping on it, I wanted to check that assumption

[ptziegler]

I know that our sister-product has implemented a custom "progress UI thread" that is managed by a secondary Display instance. The code itself is from 2011 and I can only speculate why it was done like this and what problem it solves, but I believe it's used to mimic something like a JFace ProgressMonitorDialog that is able to provide feedback, even if the "primary" UI thread is busy.

The application only runs on Windows, so the fact that macOS/GTK prohibits this was never a problem. So while I don't think that this is a very good use-case, 1) does happen in the wild.

[jonahgraham]

Thanks @ptziegler for the input - and interesting use case.

[HeikoKlare]

We use multiple displays with multiple UI threads and we also frequently dispose and create them throughout the application lifecycle (except for the "main" display showing the workbench). This is of course limited to Windows (our product is currently Windows-only). For us, this is an essential functionality.

[jonahgraham]

While @ptziegler's case is interesting, even if GTK supported multiple displays the progress monitor dialog isn't likely to expose the problem.

However I think @HeikoKlare's case is more closely aligned with the use case I worry about - even though the crash in #2675 is GTK only, understanding the use case is very helpful. I am going to reopen #2675 and think about at least a way of detecting the problem before the crash happens.

[HeikoKlare]

After taking a look into #2675, it seems like some more information on our use case could be helpful here: we use additional displays for what we call "off-screen rendering" tasks. We render diagrams including other UI-related stuff (which is quite expensive and takes some time) on a different display so that it can be done in the background while the main UI threads stays responsive. I am pretty sure this could also be realized in a different and more lightweight way than using multiple displays, but since the capabilities were there, it worked easily and now a bunch of functionality is built on top of it, it would not be easy to get rid of it.
But regarding the referenced issue: I don't think that would affect our use case as to the best of my knowledge no user interactions and in particular no clipboard interactions are involved here. And I am not sure if clipboard interaction is something we need to expect on additional displays of multi-display applications. In productive use, I would only expect such an error if a clipboard operation is accidentally pending when the primarily display is disposed (i.e., usually at the end of the application lifecycle).

[jonahgraham]

I have a proposal for how to fix my issue on GTK3 in #2684 - and I have added new tests in that PR that cover the single display at a time use case of the Clipboard. I can consider writing some multi-Display at a time clipboard test cases in the future, but that part is low priority for me at the moment because I am not editing Clipboard implementation on Windows.

[laeubi]

I saw this on windows in some cases but more by accident than by purpose.

I believe it's used to mimic something like a JFace ProgressMonitorDialog that is able to provide feedback, even if the "primary" UI thread is busy.

Yes that was a case I'm seeing as well but more because "we don't know it better".

This is of course limited to Windows (our product is currently Windows-only). For us, this is an essential functionality.

This is the main concern with that as it hinders adoption of other OS, what might be fine. In general it would have been better to be disabled by default and only enabled explicitly for those who knows what they do and want to be limited to windows.