I am working with a VB window that seems to want to resize depending on the resolution of the monitor.
Right now, I have VS2010 open on a monitor that is 1366 x 768. I have the form set to the following dimensions:
MaximumSize, MinimumSize and Size are all set to 948x580.
When I run the app, it looks fine.
Now, I have another monitor that has the resolution set to 1680x1050.
When I run the app, the window is 1263x705.
I was under the impression, that forcing the Max and Min sizes would lock the size of the window. Is this correct? Is there some other setting I am possibly missing?
take care,
lee
This is just a guess but what is your Form.AutoScaleMode set to? It is defaulting to the AutoScaleMode.Font Enumeration on my system even though the documentation says it defaults to AutoScaleMode.None. You may want to look at this MSDN link on AutoScaling also.
None - Automatic scaling is disabled.
Font - Controls scale relative to the dimensions of the font the classes are using, which is typically the system font.
Dpi - Controls scale relative to the display resolution. Common resolutions are 96 and 120 DPI.
Inherit - Controls scale according to the classes' parent's scaling mode. If there is no parent, automatic scaling is disabled.
Related
I have one desktop and one laptop (windows 10).
The size of the monitor installed on the desktop is 24 inches.
They are same resolution(1920 by 1080) and i set same zoom ratio in Windows 10.
I do not use Movewindow function or other things to fix the size, however, the dialog size in the laptop and the desktop is different.
It causes that the controls in my software are overlapping each other.
please let me know if i notify other settings!!
Thank you.
Sorry, my question is not specific, i add two pictures.
In laptop, the setting of Windows is overlapped with the setting of DICOM.
Of course, i can make the controls not overlapping when i directly use 'movewindow' on dialog, but i want to know why the two dialogs have different size.(same resolution(1920 x 1080), same zoom ratio on windows 10)
In Desktop, the print dialog has 791 x 632 size, in latop, the print dialog has 911 x 816 size.
I will check DPI-Awareness. Thank you for your comments!
I'm getting to know about this phenomenon.
In laptop, The resolution is 1920 X 1080, However, the ratio value which Windows 10 recommend is 125%.
I Change the ratio to 100% then, It worked at a higher resolution i think.
I use this code to get a resoltion.
MONITORINFO mi;
::ZeroMemory(&mi, sizeof MONITORINFO );
mi.cbSize = sizeof MONITORINFO;
if( ::GetMonitorInfo(hMonitor, &mi))
In laptop,
When i use 100% the size of text, apps, and other items in Scale and layout,
then The mi.rcMonitor's width = 2400
if i change the ratio value to 125%(which windows recommend), then The mi.rcMonitor's width = 1920
I don't know how to represent 2400 * 1350 in 1920 * 1080 monitor, so i will study this!
I'm working on a fullscreen Windows desktop application that's moderately graphics-intensive, it uses OpenGL but only renders 2D content. Nothing fancy, mostly pushing pixels to the screen (up to 4K, single monitor) and uploading textures. We're using VSync to control the rendering framerate, ie. calling SwapBuffers() at the end of rendering to block until the next VBlank.
The main requirement we have is that the app runs at a solid 60FPS as it's used with a touchscreen, and interactions need to be as fluid as possible.
Because it's pretty basic, the app runs just fine on a 8th gen Intel i7 CPU with integrated Intel HD Graphics 630 GPU. Neither the CPU or GPU are anywhere near peak usage, and we can see that we're hitting a comfortable 60FPS through our in-app FPS meter. I also have it running with similar results on my Surface Book 2 with Intel i7 and integrated Intel UHD Graphics 620 GPU.
However, what I've recently started noticing is that the app sometimes starts dropping to 30FPS, then staying there either for long periods of time or sometimes even permanently. Through our FPS meter, I can tell that we're not actually spending any time rendering, it's just our SwapBuffers() call that blocks arbitrarily for 2 frames, capping us at 30FPS. The only way to get back to 60FPS is to alt-tab with another app and back to ours, or simply bringing the Windows menu up then going back to the app.
Because of the app going back to 60FPS afterwards, I'm positive that this is an intended behavior of the Intel driver, probably meant for gaming (gamers prefer a stable 30FPS rather than irregular/occasional dropped frames which make the game look choppy).
However in our case, dropping an occasional frame isn't a big deal, however being capped at 30FPS makes our UI and interactions far less pleasing to the eye, especially when it could easily render at a smooth 60FPS instead.
Is there any way to switch the driver behavior to prefer pushing 60FPS with occasional drops rather than capping at 30FPS?
OK so I was able to figure this out with a little bit of tweaking and reverse-engineering: The answer is that yes this is an intended but unfortunate default behavior of the Intel driver, and it can be fixed via the Intel HD Graphics Control Panel app if available, or directly in the registry otherwise (which is the only way to fix the issue on the Surface Book and other Surface devices, where the custom Intel driver doesn't expose the Intel HD Graphics Control Panel app anymore).
Starting with the simple solution: In the Intel HD Graphics Control Panel app, go to "3D", then "Application Settings". You'll first need to create an application profile, by selecting the file on disk for the process that creates the OpenGL window. Once that's done, the setting you want to adjust is "Vertical Sync". By default, "Use Application Default Settings" is selected. This is the setting that causes the capping at 30FPS. Select "Use Driver Settings" instead to disable that behavior and always target 60FPS:
This should've been pretty obvious, if it wasn't for Intel's horrible choice of terms and incomprehensible documentation. To me it looks like the choices for the settings are inverted: I would expect the capping to happen when I select "Use Driver Settings", which then implies the driver is free to adjust buffer swapping as it sees fit. Similarly, "Use Application Default Settings" implies that the app decides when to push frames, which is precisely the opposite of what the setting does. Even the little help bubbles in the app seem to contradict what these settings do...
ps: I'll post the registry-based solution in a separate answer to keep it short
Here is the registry-based answer, if your driver does not expose the Intel HD control panel (such as the driver used on the Surface Book and possibly other Surface laptops), or if you want to make that fix programmatically via regedit.exe or the Win32 API:
The application profiles created by the Intel HD control panel are saved in the registry under HKCU\Software\Intel\Display\igfxcui\3D using a key with the process file name (e.g. my_game.exe) and a REG_BINARY value with a 536-byte data blob divided like this:
Byte 0-3: Anisotropic Filtering (0 = use app default, 2-10 = multiplier setting)
Byte 4-7: Vertical Sync (0 = use app default, 1 = use driver setting)
Byte 8-11: MSAA (0 = use app default, 1 = force off)
Byte 12-15: CMAA (0 = use app default, 1 = override, 2 = enhance)
Byte 16-535: Application Display Name (wide-chars, for use in the control panel's application list)
Note: all values are stored in little-endian
In addition, you need to make sure that the Global value under the same key has its first byte set to 1, which is a sort of global toggle.(the control panel sets it to 1 when one or more entries are added to the applications list, then back to zero when the last entry is deleted from the list).
The format of value is also a REG_BINARY value with 8 bytes encoded like this:
Byte 0-3: Global toggle for application entries (0 = no entries, 1 = entries)
Byte 4-7: Application Optimal mode (0 = enabled, 1 = disabled)
For example:
I expect xrandr --dpi 180 to change the dpi from 90 to 180 on the fly per-session and thus downscale resolution, but nothing happens. Am I missing something? I was able to change the dpi with the silly hack of adding fonts.fontconfig.dpi=180 to /etc/nixos/configuration.nix then nixos-rebuild test, which is less than ideal.
To be very clear, here's my situation:
1. the default resolution is too low for my laptop screen and everything (fonts) looks painfully small.
2. I learned adding fonts.fontconfig.dpi=180 to /etc/nixos/configuration.nix on nixos can set the dpi to 180 from the default 96 so that everything has normal size (fonts).
3. However, I now sometimes open the vm on a monitor which has lower resolution than my laptop, and I'd like to change the dpi on the fly when switching between using the laptop screen and the monitor.
After changing the DPI via that setting, programs won't necessarily immediately react to it.
You may need to re-open certain applications to see the change.
I am writing a custom control which inherits from FrameworkElement. I use DrawingVisual to render to the screen. Therefore, I have to calculate myself the optimal size of the Visuals I draw. If HorizontalAlignment is set to Stretch, I would like to use all available space. Only WPF doesn't tell how much space is really available :-(
In MeasureOverride, the constraint.Width is Infinity. I need to return a desired size which is less than Infinity, otherwise I get the exception "InvalidOperationException: Layout measurement override of element 'xyz' should not return PositiveInfinity as its DesiredSize, even if Infinity is passed in as available size."
I tried to return 0 in the hope that Arrange would pass all the available space this time, since in MeasureOverride it said Infinity width is available. But ArrangeOverride says the arrangeBounds.Width is 0.
I tried to return an arbitrary width (well, actually I returned the Monitor width to MeasureOverride), but then ArrangeOverride tells me I can use the complete monitor, which is, of course, not true :-(
So which width do I return in MeasureOverride to get the maximum space really available ?
Update 23.1.23
My control is in a library and has no idea who is the container holding it. I inherit from that control to make many different controls, for example a line graph that can contain millions of measurements. So if there is unlimited space, the graph gets millions of pixel wide. If the space is limited, let's say 1000 pixels, then the graph displays in 1 pixel the average of thousands of measurements.
After using WPF now for nearly 20 years, I think the proper solution is to raise an exception when the available width is Infinity, but my control cannot deal with that. The exception demands that the control is put into a container which gives limited width to its children.
For example a ScrollViewer gives unlimited space to its children. But since my line graph, or any other control I design that can not deal with unlimited space, gets unreasonably big, it is better to alert the developer using the control immediately that the control needs to be hosted in a container like a Grid, where the Grid tells the child the exact size available. Of course, also the Grid might give unlimited space when the column width is set to auto, but in this case my Control should raise an exception, so that the column width can get changed to a number of pixels or *.
I'm looking into rendering frames at a high rate (ideally next to the max monitor rate) and I was wondering if anyone had any idea at what level I should start looking into: kernel/driver level (OS space) ? X11 level ? svgalib (userspace) ?
On a modern computer, you can do it using the ordinary tools and APIs for graphics. If you have full frames full of random pixels, a simple bit blit from an in-memory buffer will perform more than adequately. Without any optimization work, I found that I could generate more than 500 frames per second on Windows XP using 2008 PCs.