Edge browser opens windows in full screen, after certain height limit.I had tried in the screen resolution of 1280*1024 if we set the height>899 open the window in full screen.
Any one facing the same issue? If yes, are there any workarounds?
I have seen there are few issues reported on edge related to height and width. Can some one help
Related
I made a responsive doughnut in chartjs. On mobile devices the size fills out the screen nicely and is as I'd like it but when I switch to desktop it also fills out the entire screen and is too big for my liking. Is there a way to set the relative size to for example, half screen when viewing on desktop and then reverting to full-screen if being viewed on mobile?
I tried the different settings on the chartjs site but can't find anything helpful.
I am rendering text with ID2D1HwndRenderTarget.
When there is a change of the UI window size, I want to prevent the stretch of the text being rendered - so it will be unchanged until I will directly make a rendering command.
On Direct2D documentation the behavior is described:
If EndDraw presents the buffer, this bitmap is stretched to cover the
surface where it is presented: the entire client area of the window
I know the ID2D1HwndRenderTarget::Resize method but I don't want to update the size immediately, just going to use it later on according to my program needs.
How can I ignore windows events to prevent this visual stretch?
You are already ignoring size change messages, and that's why surface size does not match client area size when presenting. You can try to offset this effect by setting target resolution according to "client area / current target size" factor, right before doing EndDraw(). I have no idea if that will help, or what will happen to uncovered window area outside of current target rectangle.
I am using multiple monitors on my PC. One of them is a TV. When I launch my application on my regular monitors, the application gets scaled properly.
However, when I run the application in fullscreen on my TV, the resolution will be too large and the output shows partially on another screen (see the blue colored output in my screenshot).
The TV is connected via HDMI and uses the same resolution as the other screens (1920x1080). It seems to be a software issue, because the output is partially visible on another screen.
I am using the following code to toggle fullscreen mode:
SDL_SetWindowFullscreen( m_Window, SDL_WINDOW_FULLSCREEN );
Any ideas on how to solve this issue?
UPDATE
When I make the TV my main display in Windows, it seems to fit properly on the TV. However, it still shows partially on the other screen (but this time it shows twice) and the mouse positioning is incorrect on the TV. Maybe the resolution is changed differently?
UPDATE 2
Windows 10 allows font sizes to be changed on a monitor. This is why my resolution detection in SDL2 identified a different resolution for my TV. Now I need to find a way to work around this.
I have an MFC app that is high dpi aware. The app displays a CTreeCtrl, which properly draws the expand/collapse (e.g. +/-) glyphs properly at different dpi settings. Here is a snippet at 200%.
In order to present a more modern appearance, I've set the tree control's theme to that of Windows Explorer by adding this to the tree control's PreSubclassWindow overide:
SetWindowTheme(m_hWnd, L"Explorer", NULL);
The tree control now draws the expand/collapse glyphs just like Windows Explorer, which is cool. But, the glyphs do not scale at high dpi settings. Here is another snippet at 200%
The theme part size at 200%, - GetThemePartSize(td, NULL, TVP_GLYPH, GLPS_OPENED, NULL, TS_DRAW, &size) - is 32 pixels. Clearly the Explorer themed glyphs are not growing in size as the dpi increases.
Has anyone else run int to this and, if so, did you find a resolution (other than owner/custom drawing the tree control?
Visual C++ 2015.
Thanks in advance...
I figured out that the high dpi issue has nothing to do with setting the Windows theme. CTreeCtrl has a high dpi bug in that the expand/collapse (e.g. +/-) glyphs are not being properly scaled with or without setting a Windows them.
If you call CTreeCtrl::GetItemPartRect at different dpi scales, you will see the returned rectangle's height is scaled (due to the scaled font), but the width isn't. Thus, what I thought was an issue with the theme was only an illusion, because the themed expand/collapse glyphs have more transparent pixels.
Sorry for wasting everyone's time...
I am making my app dpi-aware per monitor by setting <dpiAware>True/PM</dpiAware> in the manifest file. I can verify with process explorer that this is indeed working or by calling GetProcessDpiAwareness.
This is all working fine and I can scale anything in the client area fine in my code. However, my only problem is that if I drag my app from a system-dpi monitor to a non-system dpi monitor, the title bar and any system menu would either become too big or too small. This isn't the case for most built-in apps (e.g. calc, edge browser, etc..) so there must be away to scale it properly. Does anyone how the devs at MS did this?
The screenshot below should explain my problem better. Also notice, that the padding between the close, min, and max button is different when it's scaled (96dpi).
Sample app I'm attaching a very simple app that is per-monitor dpi aware.
The Windows 10 Anniversary Update (v1607) has added a new API you must call to enable DPI scaling of the non-client areas: EnableNonClientDpiScaling. This function should be called, when WM_NCCREATE is received. The message is sent to the window's procedure callback during window creation.
Example:
case WM_NCCREATE:
{
if (!EnableNonClientDpiScaling(hWnd))
{
// Error handling
return FALSE;
}
return DefWindowProcW(...);
}
If the application's DPI-awareness context is DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2, then calling EnableNonClientDpiScaling should be omitted, as it won't have any effect, although the function will still return successfully.
From the documentation:
Non-client scaling for top-level windows is not enabled by default. You must call this API to enable it for each individual top-level window for which you wish to have the non-client area scale automatically. Once you do, there is no way to disable it. Enabling non-client scaling means that all the areas drawn by the system for the window will automatically scale in response to DPI changes on the window. That includes areas like the caption bar, the scrollbars, and the menu bar. You want to call EnableNonClientDpiScaling when you want the operating system to be responsible for rendering these areas automatically at the correct size based on the API of the monitor.
See this blog post for additional information about DPI scaling changes in Windows 10 AU.
Does anyone how the devs at MS did this?
This has a pretty disappointing answer. Using Alin Constantin's WinCheat and inspecting the top-level window of Calculator, I see a window size of 320x576, and a client size that is also 320x576.
In other words, Microsoft entirely avoids the problem by suppressing the non-client area of the window, putting everything in the client area instead. Making this work well for you may involve custom drawing of the title bar.
Something worth noting is that Calculator and e.g. Windows Explorer don't use the same colour for the title bars. Calculator doing custom drawing of the title bar would explain that perfectly.
UPDATE:
It is enough to add new <dpiAwarness> declaration to manifest to solve all this mess. Example is here.
Remnants of former investigations (obsolete):
More investigations on the subject.
System setup: two monitors, one is 96 dpi another one is 267 dpi (Microsoft Surface 4).
Testing window is moved to secondary 96 dpi monitor:
Here is rendering (wrong, IMO) with <dpiAware>true/pm</dpiAware> in manifest:
Note huge size of caption bar and wrong sizes of window icons.
And here is correct rendering using <dpiAware>true</dpiAware>
And I suspect that MSDN documentation is plainly misleading about values of PROCESS_DPI_AWARENESS. I do not see any differences in messages and styles between <dpiAware>true</dpiAware> and <dpiAware>true/pm</dpiAware>. The later one just makes caption larger. In both case application receives WM_DPICHANGED message while moving between monitors with different DPI.
Sigh.
The documentation says:
Note that the non-client area of a per monitor–DPI aware application is not scaled by Windows, and will appear proportionately smaller on a high DPI display.
The Microsoft apps that you link to deal with this by removing the non-client area and making the client area cover the entire window.