| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3462
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 3 - Moderate, e.g. unable to compile the software |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | Fullscreen windows not updated when screens are added or removed |
Version: | 1.3-current |
Created By: | astrand |
Assigned To: | AlbrechtS |
Fix Version: | 1.4.0 |
Fix Commit: | unknown |
Update Notification: | |
Trouble Report Files:
No files
Trouble Report Comments:
|
#1 | astrand 06:41 Apr 17, 2018 |
| If screens ("outputs" using RandR nomenclature) are added or removed, existing fullscreen windows are not updated. For example:
* Start the "fullscreen" test application when you have one screen
* Select "All Screens" and "FullScreen".
* Add a new screen. This can possibly happen if you plugin or turn on a additional screen. Another case is if the application is running inside a Xvnc session and the viewer switches to "All Screens"+"FullScreen" on a multi monitor client. It can also happen if the user manually enables an earlier disabled screen. (For testing, I'm using: "sleep 10; xrandr --output VGA-1 --mode 1280x1024 --right-of LVDS-1" to enable a previously disabled output.)
In this case, the fullscreen application will still only cover the screen(s) that existed before the additional screen was added. The only way to get the application to cover the new screen as well is to turn fullscreen mode off+on.
If you do the opposite, remove a screen, things are worse: The "fullscreen" test application will print:
"drawing size 32747 32407"
Then, on my CentOS 7 machine, either the Xserver or gnome-shell crashes, or the OOM killer starts working.
The "crash" part needs to be fixed, and there needs to be some way of updating the fullscreen window to cover new windows. I'm currently investigating if/how FL_SCREEN_CONFIGURATION_CHANGED can be used for this. If this is the way to go, test/fullscreen should use this approach. | |
|
#2 | astrand 12:20 Apr 17, 2018 |
| The crash only happens if there's a second screen (later to be removed) present when "fullscreen" starts. If the screen is added after it has started, there's no problem. I've also determined that the window is actually resized to a strange size:
xwininfo: Window id: 0x2400002 "FLTK"
Absolute upper-left X: 0 Absolute upper-left Y: 0 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 32767 Height: 900 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +0+0 --31167+0 --31167-0 +0-0 -geometry 32767x900+0+0 | |
|
#3 | astrand 05:15 May 07, 2018 |
| The crash problems seems to be caused by WM bugs.
As for handling added/removed screens, I've implemented this for TigerVNC, see:
https://github.com/TigerVNC/tigervnc/pull/642
Only possible for Windows and Linux though.
The "fullscreen" example should be updated accordingly; call fullscreen() upon FL_SCREEN_CONFIGURATION_CHANGED. | |
|
#4 | AlbrechtS 07:16 Jan 01, 2019 |
| Thanks for the report and the shown workaround (is it as simple as described in comment #3?). I can't test since I don't have a system where I can similate screen addition and removal right now).
Anyway, I'm going to reduce priority to 3 (moderate) since this is a very special issue. | |
|
#5 | AlbrechtS 12:44 Mar 13, 2024 |
| Fixed in Git repository.
The issues with adding and removing monitors while a program is in fullscreen mode has obviously been fixed - at least on Linux. I tested FLTK 1.3.4 (current when this STR was filed), 1.3.9 (git current as of today), and 1.4.0 (git) and could not reproduce a crash.
I tested this with X11 and Wayland (1.4.0) and couldn't find an issue. Maybe my test environment (Linux Debian Bookworm, Gnome/Wayland) is not exactly the same though, or my tests were different...
Anyway, since FLTK's screen handling has been changed a lot in 1.4.0 I believe that this issue has very likely been fixed. It is also possible that the issue was caused by the OP's Desktop environment.
If this still needs attention - in 1.4.x - please file a GitHub Issue.
Note: I also made a quick test with 1.3 (git) and release 1.3.4 and couldn't reproduce the crash. It looks like the fullscreen window behaves as expected (by me). Note also that we don't intend to update 1.3.x anymore but *if* you can describe a scenario that reproduces a crash in release 1.3.x (x >= 9) or git 'branch-1.3' then we /might/ try to fix it in branch-1.3 as well.
In any case, patches would be appreciated.
Please feel free to reply to this STR - it will be closed if there's no reply within 2 weeks.
Please open a GitHub issue if necessary. | |
[ Return to Bugs & Features ]
|
| |