Bugzilla – Full Text Bug Listing
| Summary: | [Win32][HiDPI] SWT Toolbar not Visible with Certain Scaling Factors | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Thomas Rohwer <trohwer85> | ||||||
| Component: | SWT | Assignee: | Thomas Rohwer <trohwer85> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | Niraj Modi <niraj.modi> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | lshanmug, niraj.modi | ||||||
| Version: | 4.12 | ||||||||
| Target Milestone: | 4.16 M3 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows All | ||||||||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=562099 https://git.eclipse.org/r/161089 https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=e3ca8a2557df8760e2bc47f43bc3b81a5280b29d |
||||||||
| Whiteboard: | m2 | ||||||||
| Attachments: |
|
||||||||
Created attachment 282442 [details]
Screenshot of toolbar with width = computeSize width -1
Note that https://bugs.eclipse.org/bugs/show_bug.cgi?id=511188 could be the same problem, as for a scaling factor of 300% pixel sizes of 1 modulo 3 would be affected. Note that not all scaling factors are affected. I think, this can't happen for 125% and 150% and 200% (you only have to check sizes modulo the numerator of the integer quotient, i.e. 5 for 125%, 3 for 150% and 2 for 200%). But e.g. 175%, 250% and 300% can show the issue for certain sizes. I think, that bug 562099 is not related to this; someone put this in the related field. Here a toolbar is not displayed at all. In 562099 a text field is not scaled. Investigating the "not displaying behaviour" of the toolbar, I found that this is deliberately set with TBSTYLE_EX_HIDECLIPPEDBUTTONS in createHandle(): int bits = OS.TBSTYLE_EX_DRAWDDARROWS | OS.TBSTYLE_EX_MIXEDBUTTONS | OS.TBSTYLE_EX_HIDECLIPPEDBUTTONS | OS.TBSTYLE_EX_DOUBLEBUFFER; Removing the option fixes the problems for me. I will propose a patch, but it would be good to understand the rationale behind adding the option. New Gerrit change created: https://git.eclipse.org/r/161089 (In reply to Thomas Rohwer from comment #0) > Created attachment 282441 [details] > Screenshot of toolbar with default size > > On certain scaling factors and toolbar sizes, the toolbar does not render. > > The cause related to two issues: > > 1) On (my) Windows 7 on 100% scaling, if a toolbar is sized slightly too > small, it does not render at all (instead of being truncated). Example code: Issue also reproducible on Win10 and suggest gerrit fixes the issue. Gerrit change https://git.eclipse.org/r/161089 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=e3ca8a2557df8760e2bc47f43bc3b81a5280b29d (In reply to Eclipse Genie from comment #7) > Gerrit change https://git.eclipse.org/r/161089 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=e3ca8a2557df8760e2bc47f43bc3b81a5280b29d Thanks Thomas for the test snippet and bug fix, resolving now. Verified in Build id: I20200520-1800 on Win10. |
Created attachment 282441 [details] Screenshot of toolbar with default size On certain scaling factors and toolbar sizes, the toolbar does not render. The cause related to two issues: 1) On (my) Windows 7 on 100% scaling, if a toolbar is sized slightly too small, it does not render at all (instead of being truncated). Example code: Display display = new Display(); Shell shell = new Shell(display); ToolBar toolBar = new ToolBar(shell, SWT.DEFAULT); ToolItem itemPush = new ToolItem(toolBar, SWT.PUSH); itemPush.setText("PUSH item"); Point p= toolBar.computeSize(-1,-1); toolBar.setSize(p.x,p.y); shell.pack(); shell.open(); yields screenshot size_normal.png Changing toolBar.setSize(p.x,p.y); to toolBar.setSize(p.x-1,p.y); yields screenshot size_too_small.png 2) When using certain scaling factors, a typical combination of computeSize and setSize can yield a smaller size in pixels than the one computed internally by computeSizeInPixels originally. E.g. for a scaling factor of 175% and a computeSizeInPixels width of say 6 pixels (other widths of 6 modulo 7 would also work), computeSize will yield a size of round(6*4/7.0)=3 points (see DPIUtils), but scaling up 3 points to pixels in setSize will give round(3*7/4.0)=5, which triggers the effect described in 1). I could fix my problems by patching ToolBar to not have a pixel size smaller than the one computed in computeSizeInPixels. Alternativly, one could probably change computeSizeInPixels to ensure, that the scaled down value scaled up again is greater or equal than the original. But if this problem only occurs on certain Windows versions, this might not be the proper fix.