| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3322
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 3 - Moderate, e.g. unable to compile the software |
Scope: | 2 - Specific to an operating system |
Subsystem: | WIN32 |
Summary: | Fl_Paged_Device::draw_decorated_window() can fail under Windows 10 |
Version: | 1.3-current |
Created By: | manolo |
Assigned To: | manolo |
Fix Version: | 1.3-current (SVN: v11903) |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | manolo 07:30 Aug 25, 2016 |
| Under MSWindows 10, it is possible to Change the size of text, apps and other items using the Display settings of the OS. When this parameter is set to a value other than 100%, Fl_Window::decorated_w() and Fl_Window::decorated_h() and Fl_Paged_Device::draw_decorated_window() are seriously wrong.
To reproduce, under Windows 10: - run the device demo program - hit the "Go" button - close the new window - go to Settings -> System -> Display - change the "size of apps" parameter to 125 % (or more) - hit the "Go" button of the device app ===> the content of the new window is plain wrong
There's probably something similar under Windows 8
The attached decorated.patch should fix all of that. | |
|
#2 | AlbrechtS 03:47 Aug 26, 2016 |
| Using decorated.patch doesn't fix the issue for me. :-(
System: Windows 10 Native display resolution: 3200 x 1800 Scaling factor (Win 10 settings): 175 % Calculated display resolution: 1828.57 x 1028.57
test/fullscreen shows: 1829x989 (DPI:96.0x96.0) ... which is the work area w/o the task bar at the bottom of the screen
Running device.exe, using default selections, I get a window that is higher than the display height. Its size is approximately 1070 x 1340. The original is 500 x 560.
Using the radio button Fl_Copy_Surface I get an even larger image, which is 1872x2305 pixels. See attached file device_Fl_Copy_Surface.png.
Note: I get similar (i results with branch-1.3-porting (svn r11893) which seems to have this patch or a similar one already. (?) | |
|
#3 | manolo 04:24 Aug 26, 2016 |
| @Albrecht:
Thanks for testing. I'm surprised by your result, because the patch does work here (see attached Win10-175.png showing the top of the new window and the Settings->Display window).
What you get is exactly what is expected without the patch. Thus, no offense, is it possible that you did not recompile Fl_win32.cxx, because it is not compiled directly but included by Fl.cxx, which is not changed by the patch ?
Alternatively, I'm on VirtualBox here. Could a virtualization artefact render the patch effective?
There still is a wrong image size with the Copy function, to be taken care of. | |
|
#4 | AlbrechtS 04:47 Aug 26, 2016 |
| @Manolo: I'm pretty sure I compiled everything. My first try was only to run make (in a CMake build) after patching, and it compiled Fl_x.cxx, so even that should have worked. After the negative result I recompiled everything, but w/o success. I verified that the patch was installed.
I can try to debug it if you like, but I can't do it now. Maybe over the weekend.
Question: is branch-1.3-porting expected to work with the commit mentioned above? In my tests it didn't work as well. | |
|
#5 | manolo 05:45 Aug 26, 2016 |
| The patch has been already committed to the porting branch, so expect the same outcomes with that as with 1.3+patch.
The patch works by computing the value of the current scaling factor. The screen size reported by the fullscreen test app contains the information used by the patch. For example, here with VirtualBox, my screen size changes as follows 100% 1443x932 125% 1154x746 150% 962x621 The ratio 1443/1154 gives the 125% value and 1443/962 gives 150%.
Then, the window size is multiplied by the scaling factor to give its size in memory, where the window decoration is read.
In your case, at 175%, a window 500x560 becomes 875x980, and what is between the window frame reported by DwmGetWindowAttribute() and a client zone 875x980 is the window decoration. You report that the device app creates a window approximately sized at 1070 x 1340. This is much larger than 875x980.
Thus, for some reason, in your setting, the client zone size in memory is much larger than 500*scaling x 560*scaling.
I'll try later on a true Windows10 box, changing the scaling factor. I already know it works OK at 100%.
I have no debugging environment under Windows, even more if true/virtualized computers differ. So any debugging proposal is very useful.
The crucial data are the values bx, by, bt, and scaling computed by Fl_WinAPI_Window_Driver::border_width_title_bar_height() as well as the RECT structure it returns. | |
|
#6 | AlbrechtS 08:04 Aug 26, 2016 |
| Please see attached file decorated_debug.patch for my debug version of your patch. With this patch I see the following output when I run device.exe, click go, and close both windows. HTH.
border_width_title_bar_height[2715] RECT(l,t,r,b) = (142,137,1018,1163) border_width_title_bar_height[2724] hs = 293, hr = 1829, px = 96 border_width_title_bar_height[2727] scaling = 0.60547 border_width_title_bar_height[2729] scaling = 0.61000 border_width_title_bar_height[2740] bx = 285, by = 285, bt = 115
border_width_title_bar_height[2715] RECT(l,t,r,b) = (142,137,1018,1163) border_width_title_bar_height[2724] hs = 293, hr = 1829, px = 96 border_width_title_bar_height[2727] scaling = 0.60547 border_width_title_bar_height[2729] scaling = 0.61000 border_width_title_bar_height[2740] bx = 285, by = 285, bt = 115 C:/git/fltk/test/device.cxx copy[559] W = 1070, H = 1318
border_width_title_bar_height[2715] RECT(l,t,r,b) = (142,137,1018,1163) border_width_title_bar_height[2724] hs = 293, hr = 1829, px = 96 border_width_title_bar_height[2727] scaling = 0.60547 border_width_title_bar_height[2729] scaling = 0.61000 border_width_title_bar_height[2740] bx = 285, by = 285, bt = 115
Note the "function[line]" numbers and in device.cxx also the file name. I think I got all the variables you requested, but I don't know where to look further for what's going awry.
PS: I'm using MinGW and a CodeLite IDE for debugging purposes. If you're interested in the CodeLite settings I can send the complete IDE to you. Maybe this can work for you so you can just click 'run/debug', but maybe it's easier to install VS 2015 community and generate the IDE with CMake. This should also enable you to debug.
PPS: I'll try to do just that: use CMake to create a VS 2015 project and see what this does. We've already seen that some special window border issues behaved differently when compiled/linked with Visual Studio vs. MinGW. ... | |
|
#7 | AlbrechtS 08:17 Aug 26, 2016 |
| Done. The results with VS 2015 (generated with CMake) are very similar, although not exactly the same:
border_width_title_bar_height[2715] RECT(l,t,r,b) = (104,91,981,1126) border_width_title_bar_height[2724] hs = 293, hr = 1829, px = 96 border_width_title_bar_height[2727] scaling = 0.60547 border_width_title_bar_height[2729] scaling = 0.61000 border_width_title_bar_height[2740] bx = 286, by = 286, bt = 122
border_width_title_bar_height[2715] RECT(l,t,r,b) = (104,91,981,1126) border_width_title_bar_height[2724] hs = 293, hr = 1829, px = 96 border_width_title_bar_height[2727] scaling = 0.60547 border_width_title_bar_height[2729] scaling = 0.61000 border_width_title_bar_height[2740] bx = 286, by = 286, bt = 122 C:\git\fltk\test\device.cxx copy[559] W = 1072, H = 1332
border_width_title_bar_height[2715] RECT(l,t,r,b) = (104,91,981,1126) border_width_title_bar_height[2724] hs = 293, hr = 1829, px = 96 border_width_title_bar_height[2727] scaling = 0.60547 border_width_title_bar_height[2729] scaling = 0.61000 border_width_title_bar_height[2740] bx = 286, by = 286, bt = 122 | |
|
#8 | manolo 08:55 Aug 26, 2016 |
| Thanks for these helpful data.
Could you just try enforcing scaling = 1.75; in the source code of function border_width_title_bar_height() and report what happens.
Aren't you using a HighDPI display? | |
|
#9 | manolo 12:56 Aug 26, 2016 |
| Indeed, decorated.patch fails on a real Windows 10 box, even at 100% scaling,
but decoratedV2.patch works OK for 100% and 125%, the only values I could test.
Albrecht: please, could you try on your system? | |
|
#10 | AlbrechtS 16:54 Aug 26, 2016 |
| Yep, works. Great! Here's what I get now:
border_width_title_bar_height[2715] RECT(l,t,r,b) = (415,410,1291,1436) border_width_title_bar_height[2724] hs = 293, hr = 1829, px = 96 border_width_title_bar_height[2732] scaling = 1.74959 border_width_title_bar_height[2734] scaling = 1.75000 border_width_title_bar_height[2745] bx = 1, by = 1, bt = 44
border_width_title_bar_height[2715] RECT(l,t,r,b) = (415,410,1291,1436) border_width_title_bar_height[2724] hs = 293, hr = 1829, px = 96 border_width_title_bar_height[2732] scaling = 1.74959 border_width_title_bar_height[2734] scaling = 1.75000 border_width_title_bar_height[2745] bx = 1, by = 1, bt = 44 C:/git/fltk/test/device.cxx copy[559] W = 502, H = 587
border_width_title_bar_height[2715] RECT(l,t,r,b) = (415,410,1291,1436) border_width_title_bar_height[2724] hs = 293, hr = 1829, px = 96 border_width_title_bar_height[2732] scaling = 1.74959 border_width_title_bar_height[2734] scaling = 1.75000 border_width_title_bar_height[2745] bx = 1, by = 1, bt = 44
The Fl_Copy_Surface mode does also work much better. The total image size is 878 x 1026, but the copy of the image is about 500 x 585 pixels in the top left and is looking correct. But if I understood you correctly this was to be expected.
To your questions: > Aren't you using a HighDPI display?
If ~170 dpi is HighDPI, then yes (it's a 13.3" notebook display with native resolution 3200 x 1800). That's why I'm using the scaling factor 175%, but not all apps honor this setting. My Cygwin X server only "sees" the native resolution which results in tiny text and so on, and there are others... | |
|
#11 | AlbrechtS 17:17 Aug 26, 2016 |
| Sorry, fading memory...
The original resolution 3200 x 1800 is ~275 dpi, the scaled resolution 1829 x 1029 (factor 1.75) is still ~157 dpi. | |
|
#12 | manolo 00:06 Aug 27, 2016 |
| Fix committed at r11894 for branch-1.3 and r11895 for branch-1.3-porting.
It's still necessary to correct the size of the image produced by the Fl_Copy_Surface class, before closing this STR. | |
|
#13 | manolo 08:20 Aug 27, 2016 |
| With r.11895, Fl_Copy_Surface should work OK under Windows 10 when the display scaling factor is > 100 % | |
|
#14 | manolo 08:22 Aug 27, 2016 |
| Sorry typo above: the commit # is r.11898 | |
|
#15 | AlbrechtS 05:17 Aug 28, 2016 |
| Tested under Win10 (version 1607) with display scaling 225%, svn r11901.
Fl_Image_Surface: no issues, everything looks good.
Fl_Copy_Surface: okay, but something is odd with examples/clipboard. Please see attached file device_Fl_Copy_Surface_225_r11901.png
Fl_Printer: Pixmap and Bitmap not printed, but this may be a known issue. Used "Nitro" PDF printer. See file device_Fl_Printer_r11901.pdf. | |
|
#16 | AlbrechtS 05:23 Aug 28, 2016 |
| Notes to device_Fl_Copy_Surface_225_r11901.png:
Left side: Greg's flruler, displays Windows "scaled" pixel size.
Middle and bottom line: examples/clipboard, showing the result of clicking "Go" in ...
Right side: test/device in original size (nominal: 500 x 560, scaled by Windows 10).
Bottom line: 502x573 is too small, same as reported in fltk.coredev. | |
|
#17 | manolo 07:40 Aug 28, 2016 |
| Fl_Printer: using Microsoft print to PDF, the Windows 10 native tool, the result is accurate (see attached file). There, scaling was 125 % | |
|
#18 | manolo 08:27 Aug 28, 2016 |
| About: Fl_Copy_Surface: okay, but something is odd with examples/clipboard. Please see attached file device_Fl_Copy_Surface_225_r11901.png
Indeed, there was a slight mis-scaling, which, I believe, is repaired with r.11903 | |
|
#19 | AlbrechtS 13:40 Aug 28, 2016 |
| Yes, I can confirm that Fl_Copy_Surface is now correct WRT scaling error.
I can also confirm that Fl_Printer works well with "Microsoft Print to PDF" printer.
Everything looks good now. I also tested branch-1.3-porting, so I believe this STR can be closed.
Thank you very much, Manolo. | |
|
#20 | manolo 00:34 Aug 29, 2016 |
| Fixed in Subversion repository.
Fix is complete at r11903 for the 1.3 branch and at r11904 for the 1.3-porting branch | |
[ Return to Bugs & Features ]
|
| |