I have a bit of a problem setting up my DirectX10 (Win32/c++) application for fullscreen mode. The problem is that I want to have my app running in fullscreen right from the start. This can be done by taking the DXGISwapChain::SetFullScreenState function. This works, but i get a small notice in my Visualc++ 2008 debugger which states:
"DXGI Warning: IDXGISwapChain::Present: Fullscreen presentation inefficiencies incurred due to application not using IDXGISwapChain::ResizeBuffers appropriately, specifying a DXGI_MODE_DESC not available in IDXGIOutput::GetDisplayModeList, or not using DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH."
What this means is that DirectX will not take full ownership of the graphicscard and flip the images from front to backbuffer but instead blit them which is much slower.
Now, i do have the DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH enabled and i did try to resize my buffers but i have absolutely no idea what would be the best way to go into fullscreen mode. I have looked on MSDN but there they mostly assume you will only go into Fullscreen by pressing Alt+Enter which lest DXGI do all the work. If someone please could post a bit of code which takes DirectX10 into fullscreen mode and takes full advantage of the "flipping" it would be greatly appriciated!
For anybody interested in the code used on resize:
ReleaseCOM(m_pD3DRenderTargetView);
ReleaseCOM(m_pD3DDepthStencilView);
ReleaseCOM(m_pD3DDepthStencilBuffer);
DXGI_MODE_DESC* mod = new DXGI_MODE_DESC;
mod->Format = DXGI_FORMAT_R8G8B8A8_UNORM;
mod->Height = m_ScreenHeight;
mod->Width = m_ScreenWidth;
mod->RefreshRate.Denominator = 0;
mod->RefreshRate.Numerator = 0;
mod->ScanlineOrdering = DXGI_MODE_SCANLINE_ORDER_UNSPECIFIED;
mod->Scaling = DXGI_MODE_SCALING_UNSPECIFIED;
delete mod; mod = 0;
m_pSwapChain->ResizeTarget(mod);
HR(m_pSwapChain->ResizeBuffers(1, m_ScreenWidth, m_ScreenHeight, DXGI_FORMAT_R8G8B8A8_UNORM, DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH))
throw(Exception(GET_BUFFER_FAIL, AT));
//problem area
m_pSwapChain->SetFullscreenState(TRUE, NULL);
ID3D10Texture2D* pBackBuffer;
HR( m_pSwapChain->GetBuffer(0, __uuidof(ID3D10Texture2D), (LPVOID*)&pBackBuffer))
throw(Exception(GET_BUFFER_FAIL, AT)); //continues as usual
Is there any reason you delete your mode desc?
Have you also tried putting your mode desc through "FindClosestMatchingMode"?
Check out http://msdn.microsoft.com/en-us/library/cc627095(VS.85).aspx The "Full-Screen issues" section contains a lot of useful information.
There are some prerequisites for enabling flipping in DXGI (which is the most efficient fullscreen presentation mode):
1) You should go into fullscreen state specifying a mode that exists in the system (you could do that either by using mode from IDXGIOutput::GetDisplayModeList or finding it using IDXGIOutput::FindClosestMatchingMode). Your code just specifies screen resolution, so most likely mode is set correctly.
2) After SetFullscreenState, you should call ResizeBuffers with the right buffer size matching mode, this is where DXGI would setup flipping mode.
Typically, it should happen naturally as reaction to WM_SIZE message send by SetFullscreenState transition, so if your app doesn't call ResizeBuffers on WM_SIZE, it probably should.
You can call ResizeBuffers manually after SetFullscreenState and that should work as well.
And yeah, MSDN has a good article about DXGI practices, including fullscreen transition:
http://msdn.microsoft.com/en-us/library/cc627095(VS.85).aspx#Full_Screen_Issues
Related
Since Android 11 the correct way of displaying a fully immersive fragment is by hiding and showing StatusBar and NavigationBars via the following code which fully supports all devices with a camera notch, at any API level. Note the WindowCompat version replaces the framework version, so you don’t need to check for a particular API level as you did when using the framework version.
Hide
WindowCompat.SetDecorFitsSystemWindows(Activity.Window, false);
WindowInsetsControllerCompat windowInsetsControllerCompat = WindowCompat.GetInsetsController(Activity.Window, Activity.Window.DecorView);
windowInsetsControllerCompat.SystemBarsBehavior = WindowInsetsControllerCompat.BehaviorShowTransientBarsBySwipe;
windowInsetsControllerCompat.Hide(WindowInsetsCompat.Type.StatusBars() | WindowInsetsCompat.Type.NavigationBars());
Show
WindowCompat.SetDecorFitsSystemWindows(Activity.Window, true);
WindowInsetsControllerCompat windowInsetsControllerCompat = WindowCompat.GetInsetsController(Activity.Window, Activity.Window.DecorView);
windowInsetsControllerCompat.Show(WindowInsetsCompat.Type.StatusBars() | WindowInsetsCompat.Type.NavigationBars());
This eliminated the overly complex, very poorly documented and potentially error-prone code like below, which was used prior to Android 11.
Window.DecorView.SystemUiVisibility = (StatusBarVisibility) (SystemUiFlags.Fullscreen |
SystemUiFlags.HideNavigation |
SystemUiFlags.Immersive |
SystemUiFlags.ImmersiveSticky |
SystemUiFlags.LayoutHideNavigation |
SystemUiFlags.LayoutStable |
SystemUiFlags.LowProfile);
I was attempting to provide a choice of either displaying all fragments fully immersive or allowing some fragments to display as “letterboxed” i.e. not allowing the window to render into the DisplayCutout area. So my existing preference choice Devices with Notches/Cutouts allow full screen display would have to change to support multiple choice.
The problem I hit was that code I had used (like the WindowCompat code above since Android 11) was failing to display the fragment fullscreen when first launched. When it opened for the first time the window would attempt to go full screen, but only the NavigationBar would be removed. The StatusBar area was left as a black rectangle. You could see the animation of the time on the left and the icons on the right side of the StatusBar disappearing, (statusBar contents removed) but the window didn’t render into the StatusBar area. Immediately when rotated, the fragment became full screen and when rotated back to Portrait it corrected itself and was full screen again.
So in frustration, I went hunting on StackOverFlow looking for a solution but everything I found suggested that my ImmersiveFragment class was coded correctly. Then because this was my first attempt at using Material 3, I then started to suspect Material3, so I went backwards to my NavigationGraph6 project (Material2) and after much testing, I was able to reproduce the same problem, which eliminated Material3.
More searching on StackOverflow and I came across a Kotlin post that was the same as all the others, except that it had the following line – equivalent to this C# line.
Activity.Window.AddFlags(WindowManagerFlags.LayoutNoLimits)
So I added that line before the WindowCompat.SetDecorFitsSystemWindows(Activity.Window, false) in the HideSystemUi() and then cleared the flags before the WindowCompat.SetDecorFitsSystemWindows(Activity.Window, true) line in the ShowSystemUi with
Activity.Window.ClearFlags(WindowManagerFlags.LayoutNoLimits)
and immediately it worked.
So my question is why is this required and has anyone come across the same problem with immersive fragments?
Definition of LayoutNoLimits – Allow window to extend outside of the screen ???.
Does anyone have a clue what this definition actually means?
To test the code (comment out the new lines in ImmersiveFragment.cs). You can find the project NavigationGraph7 at https://github.com/gmck/NavigationGraph7. The immersiveFragment is the RaceResultsFragment (inherits from ImmersiveFragment) accessed by the BottomNavigationBar on the SlideShowFragment.
I referred to the official doc both Android and Microsoft too. As you said that: "Allow window to extend outside of the screen". There are few official definitions of it...
You can check Can I set FLAG_LAYOUT_NO_LIMITS only for status bar?, it talks about usage of LayoutNoLimit. Wish it could be helpful to you.
My application performs several rendering operations on the first frame (I am using Metal, although I think the same applies to GLES). For example, it renders to targets that are used in subsequent frames, but not updated after that. I am trying to debug some of draw calls from these rendering operations, and I would like to use the 'GPU Capture Frame' functionality to do so. I have used it in the past for on-demand GPU frame debugging, and it is very useful.
Unfortunately, I can't seem to find a way to capture the first frame. For example, this option is unavailable when broken in the debugger (setting a breakpoint before the first frame). The Xcode behaviors also don't seem to allow for capturing the frame once debugging starts. There also doesn't appear to even be an API for performing GPU captures, in Metal APIs or the CAMetalLayer.
Has anybody done this successfully?
I've come across this again, and figured it out properly now. I'll add this as a separate answer, since it's a completely different approach from my other answer.
First, some background. There are three components to capturing a GPU frame:
Telling Xcode that you want to capture a GPU frame. In typical documented use, you do this manually by clicking the GPU Frame Capture "camera" button in Xcode.
Indicating the start of the next frame to capture. Normally, this occurs at the next occurrence of MTLCommandBuffer presentDrawable:, which is invoked to present the framebuffer to the underlying view.
Indicating the end of the frame being captured. Normally, this occurs at the next-but-one occurrence of MTLCommandBuffer presentDrawable:.
In capturing the first frame, or activity before the first frame, only the third of these is available, so we need an alternate way to perform the first two items:
To tell Xcode to begin capturing a frame, add a breakpoint in Xcode at a line in your code somewhere before the point at which you want to start capturing a frame. Right-click the breakpoint, select Edit Breakpoint... from the pop-up menu, and add a Capture GPU Frame action to the breakpoint:
To indicate the start of the frame to capture, before the first occurrence of MTLCommandBuffer presentDrawable:, you can use the MTLCommandQueue insertDebugCaptureBoundary method. For example, you could invoke this method as soon as you instantiate the MTLCommandQueue, to immediately begin capturing everything submitted to the queue. Make sure the breakpoint in item 1 will be triggered before the point this code is invoked.
To indicate the end of the captured frame, you can either rely on the first normal occurrence of MTLCommandBuffer presentDrawable:, or you can add a second invocation of MTLCommandQueue insertDebugCaptureBoundary.
Finally, the MTLCommandQueue insertDebugCaptureBoundary method does not actually cause the frame to be captured. It just marks a boundary point, so you can leave it in your code for future debugging use. Wrap it in a DEBUG compilation conditional if you want it gone from production code.
Try...
[myMTLCommandEncoder insertDebugSignpost: #"com.apple.GPUTools.event.debug-frame"].
To be honest, I haven't tried it myself, but it's analogous to the similar
glInsertEventMarkerEXT(0, "com.apple.GPUTools.event.debug-frame")
documented for OpenGL ES, and there is some mention on the web of it working for Metal.
First, in Metal, I usually use Metal to do parallel compute, then GPU Capture frame is alway grey. So, there are two ways until now I found is Ok.
In iOS 11
you can use the [[MTLCaptureManager alloc] startCaptureWithDevice:m_Device]; to capture frame so you can profile the compute shader performance
lower than iOS 11 (MTLCaptureManager && MTLCaptureScope are new in iOS 11.0 )
you can use the breakpoint, then edit the Action.Capture GPU Frame
I'm having some issues with AirPlay. The thing is, I'm developing with the ATV3, and my TV set supports 1080p. But when I start screen mirroring and receive the new instance of UIScreen, the bounds and the applicationFrame are both giving me a 720p resolution.
But it gets weird when I actually moved the subviews to a negative value, and the whole screen gets covered. So, technically my iPhone is streaming at 1080p, but the bounds returned by the UIScreen are underscanned.
I've tried modifying the overscanCompensation before getting the bounds or the applicationFrame (tried both with all 3 overscanCompensation values available) but I'm still getting the same result.
Here is a picture of what I'm getting (sorry, it's the worst picture in the planet, I know, but I was using my phone to stream the image to the ATV :) )
Red view is the 720p reported by bounds.
It gets even weirder when I actually try this out in my ATV2 (it is supposedly limited to 720p even if it supports 1080p) and the result is exactly the same.
Anyway, if someone knows the method to get the real screen display to avoid putting a settings view in my app, I'll really appreciate it.
Thanks in advance :)
When you mentioned that you tried all 3 overscanCompensation modes, I presume you mean the 3 documented modes:
typedef enum {
UIScreenOverscanCompensationScale,
UIScreenOverscanCompensationInsetBounds,
UIScreenOverscanCompensationInsetApplicationFrame,
} UIScreenOverscanCompensation;
However, there is a fourth mode, which is not there, but should fix your problems: just set your overscanCompensation to 3.
Also, take a look at this SO question.
The answer of Ivan solved the same issue for me! But I also had the borders when using AirPlay Mirroring. I got rid of the borders without setting the overscanCompensation property by changing a setting on my Apple TV: try setting 'Settings > Audio & Video > Adjust For AirPlay Overscan' to Off (default On).
The setting that works best for most TVs is:
externalScreen.overscanCompensation = UIScreenOverscanCompensationInsetBounds | UIScreenOverscanCompensationInsetApplicationFrame; // this is the same as setting it to 3
Just setting it to UIScreenOverscanCompensationInsetApplicationFrame can cause misalignment of the UIWindow contents.
3 is a bitmask of UIScreenOverscanCompensationInsetBounds(1) and UIScreenOverscanCompensationInsetApplicationFrame(2) for those wondering where that number comes from and why it works.
So, Im using D3D in a windowed application.
I inited D3D with the following parameters:
windowed: true;
backbufferformat: D3DFMT_X8R8G8B8;
presentinterval: D3DPRESENT_INTERVAL_ONE;
swapeffect: DISCARD
Each time OnPaint is called, I render the image to the backbuffer and present it to front.
As far as I know (and so does MSDN say), once I set D3DPRESENT_INTERVAL_ONE, vsync will work.
But in this case, the image is teared when dragging horizontally.
(It seems there's a line across the image, image below the line shows on the monitor and the above part follows.)
Some sites say D3DPRESENT_INTERVAL_ONE will not work in windowed applications.
How can I enable vsync anyway?
p.s. I finally found D3D vsync is enabled, while some window settings are not right that perhaps the window itself is not sync ed. though, I haven't peek the settings out.
I assume you're using D3D9? Should add that tag. On your D3DPRESENT_PARAMS variable:
if (bVysncEnabled)
{
presentParams.PresentationInterval = D3DPRESENT_INTERVAL_ONE;
presentParams.FullScreen_RefreshRateInHz = D3DPRESENT_RATE_DEFAULT;
}
else
{
presentParams.PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE;
presentParams.FullScreen_RefreshRateInHz = 0;
}
If you've done this and you're using the old GDI stuff, it's not your vsync setting that's wrong, but the window settings. You must enable double buffering or you'll still get tearing.
You cannot vsync while in windowed, only in fullscreen. However, you could potentially ghetto it by getting info from the default display and finding the refresh rate, and then nerfing your renderer to only render at that rate...although I wouldn't suggest that route.
Windowed historically haven't been able to be vsynced for d3d, and only recently has this been possible, when aero is enabled in WinVista or Win7 and the app isn't running in presentation mode immidiate.
How often do you call ::OnPaint ? The reason I am asking is, that you must be calling ::OnPaint more often than the refresh rate of your attached monitor.
For me, I solved the refresh issue by forcing an ::OnPaint whenever the message loop is idle with invalidating the window. What will happen if you do that, is, that the RenderPresent command for D3D will WAIT until the graphic card finished rendering, which gives you a very precise timing of the ::OnPaint in sync with the actual monitor refresh rate !
I am having good success with this, and the statements above that windowed mode cannot vsync is definitely not true. Even in DirectX 9 Win XP, this just works.
Oh and last but not least, if you have more than one display attached, make sure to vsync with the actual display which presents your window. This seems a bit more tricky.
not exactly D3D, but AntiTearing.html describes how MPC-HC uses windowed EVR et al to try and avoid tearing of a windowed display. The links here: http://betterlogic.com/roger/2012/05/gdi-vsync-to-avoid-tearing/ may be useful for synchronizing, too (albeit something of a work around).
I've got an app that runs a long set of operations, and I'm trying to use a TProgressBar to keep track of what's going on. I set a number of steps, and call .StepIt to increment the progress bar.
Problem is, it doesn't keep up very well. Instead of jumping directly to the correct position, it seems to like to slide gradually up to it. That's all well and good if it's eye candy you're after, but when I'm trying to get an accurate representation of my routine's progress, this makes it appear to be constantly lagging behind the true status. How can I turn that "feature" off?
I only notice this happening under Windows Vista. Not sure if it's also going on on XP or not, because when I test it on XP, the process goes a lot faster and it's over too quickly. :P But this may or may not be Vista-specific. Either way, it's driving me nuts. Does anyone know how to fix it?
I have a quick but partial and inelegant solution, if you don't mind having the progressbar yellow instead of green:
ProgressBar1.SmoothReverse := True;
ProgressBar1.State := pbsPaused; // for yellow or pbsError for red
Or if you don't mind loosing the vista/theme look and go back to a flat blue one:
UxTheme.SetWindowTheme(ProgressBar1.Handle, ' ', ' ');
The real "problem" according to Microsoft is that you try to "pervert" a ProgressBar into a Meter which they claim it is not.
You could also try to draw it yourself ;-)
Same problem on Windows7 !!
But the answer was already in one of the older posts:
If tou make the progressbar step backwards there will NO delay !!!
So I implemented this..... (and get instant updates)
if(progress < ProgressBar.Max)
then
begin
ProgressBar.Position := progress+1;
ProgressBar.Position := progress; //This will set Progress backwards and give an instant update....
end
else
begin //cannot set position beyond max...
ProgressBar.Max := progress + 1;
ProgressBar.Position := progress + 1;
ProgressBar.Max := progress; //This will also set Progress backwards also so instant update........
end;
I ran into exactly the same problem a while ago. After searching Google for a long time, I found that it is a Vista-specific problem. It seems to boil down to this: Microsoft added fancy animations to the progress bar control in Vista (i.e., the moving 'highlight'). To make updates more smooth, they implemented some sort of 'lagging' in the repaint of the control --- and this basically screws the whole progress bar control. Rather annoying, I'd say, especially since there doesn't seem to be a decent solution.
See for more details the replies by Arvid Winkelsdorf to this Embarcadero Discussion Forum post:
It's the same for VB, C++ and C#
somehow as the problem lies in the
Vista drawing of the new animated
ProgressBars. To provide a smoother
visual feedback drawing is delayed
when moving forward. Your application
cannot be sure that 100% will be
reached at any given time.
By setting the position back to a
smaller value, the ProgressBar drawing
is forced to jump back. No delay in
getting to a position smaller than the
current. So you'll have nearly 100%
immediately. Afterwards set to the
maximum and you'll have exactly 100%.
[...]
There is a similar glitch when using
the new Vista ProgressBar Styles like
PB Paused or PB Error. If the bar is
still moving (MS part) and your app
sets the color to paused by
SendMessage (like in D2009) the
message will be ignored by the
ProgressBar.
Maybe you can try to set the position of the ProgressBar directly instead of using the StepIt procedure. I'm on XP with Delphi 7 here, so I can't test it, but looking at the code of TProgressBar it uses a different message (PBM_SETPOS instead of PBM_STEPIT). So maybe it sets the position of the progressbar without an animation.
Additionally there are several 3rd party components which provide better Progress bar implementations that still render nice on Vista. Personally, I prefer the one from Raize components which works quite well. It doesn't "lag" like the windows control does and works independent of any theming.
If you don't really want anything fancy, then you can always build one yourself using a panel and a tshape aligned left inside the panel. Resize the tshape to be a % of the panel it sets on.
I had the same problem, my solution was to switch to another control available in the VCL :
I choose to use the Range of TTrackBar to display the progression.
(with slider off and control resized to hide the range marks).
Not the same visual (particulary if themed), but it fit well my need (no lag).
Here is a simple solution:
ProgressBar.max := ProgressBar.max +1;
ProgressBar.StepBy(2);
ProgressBar.StepBy(-1);
ProgressBar.max := ProgressBar.max -1;