Win 10 DPI strangeness
Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Controls
Forum Description: Topics Related to Codejock Controls
URL: http://forum.codejock.com/forum_posts.asp?TID=23634
Printed Date: 24 November 2024 at 8:20am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: Win 10 DPI strangeness
Posted By: rdhd
Subject: Win 10 DPI strangeness
Date Posted: 30 April 2018 at 6:43pm
Hello world,
I could really use a strong dose of Oleg! This one has me vexed. We have CJ 18.2. Our app is set to be HighDPI aware. We are having issues with 4k monitors on Win10.
For background: We provide both 16x16 and 32x32 images for most of our ribbon buttons. For some of our buttons, we only provide 32x32 images. With normal monitors or with Win 7, our ribbon will have some images that are large and some that are small. That is based on the button style. On a non-scaled desktop, our buttons with the icon and caption below draw "big" and the other buttons draw "small".
I have stepped thru a lot of CJ code. I found code that spins thru the icon set for a given ID and I see CJ picking the 32x32 button size when my 4k monitor is scaled to 200%. For some icons, we have only provided 32x32 (we use the icon and caption below style). Again, the icon set search uses the 32x32 image which is the only one in the icon set.
I have two monitors connected to my Win10 box (Win 10 Enterprise with Fall Creators Update). One is a normal monitor set to 100% and one is the 4k monitor set to 200%.
I have logged in with the above configuration.
I run our application on the 4k monitor. The images draw as we want. The images which we only provide a 32x32 bit image SCALE up. So, just like with Win 7, we have "large" and "small" buttons on the ribbon. The large images are roughly 64x64 as measured with paint. The small ones are 32x32 (again with paint.exe).
Now comes the wierdness. I unplug the non-4k monitor. I log out and back in. I run the app. I expected to see some big and some small images. But that isn't what I see. Instead, all the images are drawing the same size - 32x32 (as measured by paint). The buttons that we use the icon and caption below style have the button size set correctly but the icon drawing code draws a 32x32 icon. So we have a big button area but a small icon.
I have stepped thru all the drawing code looking for some difference when running with the two monitor configurations but I have found no changes. For our 32x32 (only) images, the icons get split out as 32x32 in both cases. The button size at draw time is the same. The icon size is the same. Both code paths go thru the resource case with alpha and the GDI AlphaBlend function is used to operate on the DIBS. I went thru the code that copies the icon handle and see the DIBs getting allocated for each case (32x32). Basically, I found nothing that was different.
Our command bar options are the same (no scaling, no gallery scaling) too. The only difference is having two monitors attached to the box with one being a normal monitor and one being a 4k monitor.
I am told, but have yet to verify it, that our previous version of the product that uses CJ 17.? does not have the issue.
So, Oleg, if you read this ... Can you explain how the icons are scaling when both monitors are attached? We are not providing anything bigger than a 32x32 image. If this was independent of the monitors, I would say we need to use the command bar option to scale the buttons. Or, I would say we need to provide a set of larger icons (so the code I saw spinning thru the icon set to pick an icon would get a bigger image). I simply have been unable to figure out how the 64x64 images are appearing. I set breaks in CJ calls to StretchBLT (none tripped). Nothing I have stepped thru tell me how this scaling is occurring. If I didn't see the results with my own eyes, I wouldn't believe it!
|
Replies:
Posted By: Marco1
Date Posted: 30 April 2018 at 7:14pm
Can you create and post a simple test/demo app which we (and CJ) can test so that the behavior is reproducible?
-------------
Product: XTP 18.3.0 on VS 2017
Platform: VS 2017 / Windows 10 (64bit)
|
Posted By: rdhd
Date Posted: 01 May 2018 at 9:31am
Hi Marco1,
Actually, I can. Sort of. The CJ ribbon samples have images of sizes greater than 32. So I wend into the RibbonMDISample mainfrm.cpp file and commented out the calls to SetIcons for "Office" 40/48/64 (six lines commented out).
That lets me reproduce the problem.
I also put our previous release that uses CJ 17 on the box and built the same sample. It only has 16x16 and 32x32 icons so I didn't change the sample. It runs fine with either monitor configuration.
Your samples, like are app use HighDPI in the manifest. So I think the issue is the same.
One other note. I have configured the two monitor system such that the 4k monitor is the primary monitor and I have configured it so that the 4k monitor is the secondary monitor. Results are the same.
I don't know when this started exactly. It has been around a good while but I just was assigned the task to look into it. So I don't know if the issue showed up with the MS "fall creators update" to Win 10 (that is version 1709). I would not be surprised if it is a FCU introduced issue.
|
Posted By: rdhd
Date Posted: 11 May 2018 at 11:28am
Are my comments on how to duplicate this in a CJ sample app sufficient?
|
Posted By: olebed
Date Posted: 12 May 2018 at 1:49pm
Hello rdhd,
Please wait for new version of CommandBars/Ribbon. We have fixed many issues with icons scaling.
If we will not find any new critical bugs in new build then next version will be released next week.
Regards,
Oleksandr Lebed
|
Posted By: rdhd
Date Posted: 14 May 2018 at 9:33am
Hi Oleksandr,
I assume this means you modified the sample as I outlined and the issue doesn't show up.
|
Posted By: olebed
Date Posted: 15 May 2018 at 9:26am
|
no, we postpone changes in samples for future release. I have fixed some issues with icons scaling and other drawing issues of CommandBar/Ribbon buttons, comboboxes, edits.
|
Posted By: rdhd
Date Posted: 24 May 2018 at 4:13pm
Sorry for the apparent confusion. I wasn't asking for an actual change to the sample that gets pushed to the toolkit release code. Just a change in a local copy of the sample to duplicate the issue!
|
|