I develop a test application with directx 11 und fl 10.1.
Everything is working as expected and fine, but when I maximize the window with my graphics in it, the time per frame increases drastically. like 1ms to 40ms.
NVS 300 graphics card
Windows 7 32-bit
Application that draws few sinuses with direct3d, c# via sharpdx
Windows forms with a control and sharpdx initialized swapchain, programmed to change backbuffer on resize event (would occur without that too though)
I used a System.Stopwatch to find the issue at the code line:
mSwapChain.Present(1, PresentFlags.None);
where the time it needs when maximized increases by a lot suddenly.
any clues?
In my specific case, switching to windows classic theme with aero disabled solved the issue. Because the frame performance got worse if the windows start button started to lay over the resized window.
Related
I have a DPI Aware application(via manifest file) and on 1 monitor system all the the following methods are returning wrong desktop resolution:
GetSystemMetrics
GetMonitorInfo
GetWindowRect(GetDesktopWindow(), &desktop)
EnumDisplaySettingsExA/ENUM_CURRENT_SETTINGS
IDXGIOutput::GetDesc
My monitor is 4k but I set desktop size to 1920x1080 with 100% scale. When in windowed mode the reported resolution via all the methods is correct. However when switched to full-screen they all return 1600x1200. If it was DPI Aware problem it should at least keep the aspect ratio, e.g. 1600x900.
I noticed that the wrong results are after a call to IDXGISwapChain::SetFullscreenState(true, output_device) where the swap chain object is created with the flag DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH as per MSDN.
The app is using DirectX 11.
Any suggestions what my cause this?
Thank you
So I found the issue - the IDXGISwapChain::ResizeTarget(mode) which need to be resized before going to fullscreen was with wrong resolution(due to previous windowed mode with custom size). This caused IDXGISwapChain::SetFullscreenState(true, output_device)to switch to different strange desktop resolutions depending on what happened to be the size of the DX targets. Setting the targets with the proper desktop resolution(taken via EnumDisplaySettingsExA/ENUM_CURRENT_SETTINGS) before changing the state solved it.
I presume dwm holds bitmap data of each rendered window in the GPU. Can I access this data? I want to use it as a texture in D3D (or preferably OpenGL). Screenshotting each window to RAM and back to GPU is too slow.
Ive seen other posts like : obtaining full desktop screenshot from the GPU
so Im doubtful, but maybe something has changed in the last 3 years.
Edit
So do all applications use Direct3D to draw all components? Would, say, this chrome browser's content, or file explorer's, or anything exist as an image in the graphics card or are only borders and such rendered through Direct3D/2D? Want to make sure before pursuing. BTW: my idea is a desktop for the Rift without running an alternate shell.
How can I change the resolution of the phone representing the code when in xaml view in a project?
The phone serves as a drag and drop for the controls, does it have a setting somewhere to set it's resolution. Windows Phone 8 currently have three resolutions; 800x480, 1280x720 and 1280x768.
I'm aware the emulator can be started up with different resolution, but my situation is that my CPU does not support this, im debugging straight on my Lumia 920 (1280x768).
I've got no clue on how the application looks like in 800x480.
But it is a simple application, a preview would be good enough.
You need to open the Device Window: Design -> Device Window
There under the display section you can select the display size (3 available).
Additionally you can test any other resolution by disabling the 'Chrome' option in the device window and setting d:DesignHeight and d:DesignWidth of your page to the desired resolution.
I had the problem and after much time searching google and stackoverflow, I don't think that it is possible to change the resolution of the designer window. However, maybe this link can help you, it helped me back a while ago when I had that problem:
WP8 Emulator screen size
It refers to the emulator, but explains how the app UI will be scaled to match different device resolutions. Hope it helps!
I have a large legacy application which is showing up with a perpetually grey border on every Windows 8 machine we run it on, while the other windows for other apps accurately use a color derived from the desktop background. For the life of me I can't find out why.
I've tried my best google-fu to crawl MSDN for APIs to control this but came up empty. The app looks like all others in Windows XP, Vista, and 7...just Windows 8 is grey in color. We definitely haven't added Win8 specific code to treat this otherwise.
It's just an MFC window on the outside, but inside it embeds a .NET/WPF component and a Direct3D 9-enabled visual area.
My best guess is it could somehow be related to having a Direct3D surface in the window, but I couldn't validate that anywhere.
Any help would be greatly appreciated!
Thanks
Edit: The grey matches the effect of not having focus, and we definitely do play games with window focus...so that could be it.
The problem was a developer overloaded OnNcActivate() and returned TRUE at the end. They needed to call up to the baseclass's (CWnd) OnNcActivate instead.
This was visible on Windows 7 as well if you looked close enough.
The Desktop in Windows 8 does not use transparency in window borders like Windows 7 and Vista did with the Aero Themes. If you are move the focus to another top window in your app, this could explain why your seeing the grey border. Try changing the colors for windows without the focus to something discernable from grey to verify that is what you are seeing.
The client for the MMO I work on uses two contexts, one for a window view and one fullscreen. I'm wondering if I just use a window sized to the display I can simply resize it if the user wants a smaller window so they can access their desktop.
Is their a performance penalty for running opengl in a window vs fullscreen assuming the same dimensions etc?
The client shell is written in cocoa; the game code itself is cross-platform.
We only support OSX 10.5 and 10.6 for the next release.
Before 10.6, if your context did not have the full screen flag in it's creation, then you had a small performance difference. Now, with 10.6, this has changed.
Have a look at:
http://lists.apple.com/archives/Cocoa-dev/2009/Sep/msg01054.html
if there is a cost associated with clipping each frame, then yes.