FLTK logo

STR #3322

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

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:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 manolo
07:30 Aug 25, 2016
decorated.patch
4k
 
 
#2 AlbrechtS
03:47 Aug 26, 2016
device_Fl_Copy_Surface.png
0.4M
 
 
#4 manolo
04:08 Aug 26, 2016
Win10-175.png
0.3M
 
 
#5 AlbrechtS
08:04 Aug 26, 2016
decorated_debug.patch
6k
 
 
#6 manolo
12:54 Aug 26, 2016
decoratedV2.patch
5k
 
 
#7 AlbrechtS
05:17 Aug 28, 2016
device_Fl_Copy_Surface_225_r11901.png
0.4M
 
 
#8 AlbrechtS
05:17 Aug 28, 2016
device_Fl_Printer_r11901.pdf
57k
 
 
#9 manolo
07:37 Aug 28, 2016
MS Print to PDF.pdf
197k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#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 ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.