I've got a problem with vsync on Direct3D 10 in window mode with DWM disabled.
We have an application, that render and present some output. It have to work in window mode and it have to produce stable 60 fps minimum.
One version of application is using Direct3D 9 and another Direct3D 10. When we are working in window mode, sometimes we have fps decrease (it's not "stable" decrease. For most of time we are producing stable 60 fps, sometimes it suddenly decrease for several seconds and then getting back to 60 fps). On both version of application fps decrease is ~10-20 fps. It's unacceptable.
In Windows Vista and Windows 7 there are new graphic system, called "desktop composition", that changed the way applications display pixels on the screen. Desktop composition is performed by the Desktop Window Manager (DWM). You know, when DWM is enabled, applications draw into off-screen surfaces in video memory, than it rendered by DWM and presented onto display in some time. So, we noticed, when dwm.exe in Task manager don't do anything (have ~0% process time), we have fps decrease and when dwm.exe takes 1-3% process time there are stable 60 fps and all is ok.
We can't influence on it. So, we have to turn DWM off in order to have high stable fps. When we turn it off, all is ok. There are stable 60 fps on both versions of application. But DWM do the vsync in window mode, so when we turn it off, we have to do vsync by ourselves.
But when we turn DWM off, there is a problem with vsync in Direct3D 10 in window mode. There are image tearing in top of a monitor. Direc3D 9 keeps working well.
So, we have a monitor with 60 Hz refresh rate.
While creating swapchain, we set such params:
swapChainDesc.BufferDesc.RefreshRate.Numerator = 60;
swapChainDesc.BufferDesc.RefreshRate.Denominator = 1;
And while presenting we set a flag to turn vsync on:
m_pSwapChain->Present( 1, 0 );
And have the next vsync problem. There are vertical lines, that are moving fast from left side to right. And there is image tearing in the top of a monitor.
http://bit.ly/POQoFq
At first we think, that we are doing something wrong. So I installed Microsoft's sample "Tutorial 07: Texture Mapping and Constant Buffers" with rotating cube. Made cube bigger, placed it higher, made it to rotate faster and got the same problem (see pictures).
http://bit.ly/SevNqw
http://bit.ly/RSoEhc
http://bit.ly/UjaNPu
So, on Direct3D 10 in fullscreen mode all is ok. Vsync works perfectly. On Direct3D 9 it's all ok too, with DWM disabled or enabled, vsync works good. On Direct3D 10 in window mode with DWM disabled there are problems.
It was tested on different computers, different videocards (Nvidia 8600 GT, Nvidia 9500 GT, ATI Radeon HD 5870 Eyefinity 6) and different versions of drivers. Problem stably reproduced. We are using Windows 7.
So, why there is such problem? How to solve it and what to do next?
UPD1. If images above are unavailable, there are some mirrors.
https://dl.dropbox.com/u/20468014/DSC_2287.JPG
https://dl.dropbox.com/u/20468014/DSC_2308.JPG
https://dl.dropbox.com/u/20468014/DSC_2313.JPG
https://dl.dropbox.com/u/20468014/DSC_2319.JPG
UDP2. I want also to notice, that I'm creating window with the flag WS_POPUP in order to hide title bar (it has to be hidden). Image tearing appears in different places. It's always in the top of a screen, but it can be on 20 px, and can be on 50 px. So, while creating window with title bar, image tearing sometimes can be simply not visible with the top part of image.
Related
I have two questions about the iOS Simulator in Xcode for my Unity game:
I am using latest version of all the software involved.
1) Why is it so slow? (I have tried the Cmd+T solution and it does
nothing. Note: The game runs smooth even on a real iPhone 4)
2) Why is the size of the iPad simulator screen bigger than my laptop screen? (I know you can
scale it, but just curious why Apple always tries to make our life
difficult)
When you run game on iOS simulator then your game image runs not completely running on your mobile hardware actually runs in compression mode so seems to be slow.
Having high resolutions Apple deceives have bigger number of pixels on their screen, so its not Screen size but it Screen pixels what we need to concern. And it is for creating more smooth effects on visuals for animation, it is to provide user better quality graphics, not to make your life difficult
I have a Delphi 3 app which has been distributed far and wide for at least a decade. Today I received a report that the app is not functioning properly on an Asus Transformer T100TA-C1-GR(S) Windows 8 tablet. Specifically, the app is refusing to run because it detects a screen resolution too small for the app to properly display itself. In the app, I have the following conditional check:
if (Screen.Width < 800) or (Screen.Height < 600) then begin
// display a message reporting screen resolution too low
ShowMessage('blah blah...');
Application.Terminate;
When I compiled a special version of my app to help debug the problem, and gave the app to the complaining user, they report back the following numbers:
Width: 980
Height: 550
Here is the extra code I added the special compilation that I then gave to the user:
ShowMessage('Width: ' + IntToStr(Screen.Width) + #13#10 +
'Height: ' + IntToStr(Screen.Height));
The user, however, swears that their tablet is configured to 1368x768. They even switched to 1024x768 and the same incorrect numbers are being reported by Delphi.
All TForm.Scaled properties are set to False.
One clue that might help... The screen width and height detection code (above) is run within the following procedure:
procedure TForm1.WMDisaplayChange(var m: TWMDisplayChange);
Any idea what might be going on?
Your application is subject to DPI virtualization. Your app has not indicated to the system that it is aware of and supports high DPI display devices. The machine in question uses a font scaling of greater than 125%. That's the high DPI cut off point. Beyond that scaling, the system virtualizes the font scaling for non DPI aware apps. From the documentation:
Windows Vista introduced a feature called DPI virtualization, which provides a level of automatic scaling support to applications that are not DPI–aware. With this feature, Windows scales the size of the text and UI elements of applications that are not DPI-aware so that they are appropriately sized on high DPI settings without changes in the application. This prevents potential usability and readability issues that occur when applications render too small on high DPI screens.
In Windows Vista through Windows 8, this feature provides "virtualized" system metrics and UI elements to not DPI–aware applications, as if they are running at 96 DPI. The application then renders to a 96 DPI off-screen surface and DWM scales the resulting application window to match the DPI setting. For example, if the DPI display setting is 144, DWM scales the application's window by 150%, or 144/96.
A consequence of this is that the system fakes the screen dimensions. When your application is DPI virtualized the system reports the virtualized dimensions rather than the true dimensions.
Best practice is to declare your application to be high DPI aware, and scale the UI according to the user's font scaling preferences. Of course, this is going to be quite a change for you. Possibly not one that you wish to take one.
Another option is to ask the user to use a reduced font scaling. They probably won't be very keen on that either.
Yet another option would be to manifest your app to be high DPI aware and continue not to scale it. Then it would certainly run, but it would fail to respect the user's font scaling preferences. Again, I imagine that the user would be non-plussed.
If you don't currently manifest your app, then doing so now will result in it not being virtualized. And by that I mean app virtualization rather than DPI virtualization. Whilst you really should not still be running virtualized, you may run into trouble if you disable virtualization.
And Sertac suggests another option. Get the user to apply compatibility settings for your app to disable DPI virtualization. You could apply that to the app as it is today, without re-compiling and at least your user would be able to make progress.
Fundamentally, there is a problem with your user's machine setup. If it has 768 vertical pixels and around 140% scaling, that really is a 100% scaled equivalent of 550 pixels. That's not very many pixels. Your application is objecting because the screen is too small and, well, perhaps that really is the case.
This various answers here may be useful to you: How do I make my GUI behave well when Windows font scaling is greater than 100%
I've been experimenting with createjs to convert some flash as3 animations to HTML5. everything works fine in desktop browsers, but on an i-pad the animation are considerably slower. Where there are complex vector objects they are so slow as to be unusable. I can speed things up by caching the objects, but the quality of the resulting graphics is poor. Are there any solutions to this problem?
Thanks in advance
Pete
take a look on canvas size. after a centain size the mobile vídeo boards cannot accelerate the graphics like pc does.
Tip #4. Watch The Size of Your Canvas
Obviously, the larger the canvas the more costly the drawing
operation, but if you’re targeting mobile devices, there are some size
limits you must keep in mind.
From Safari Web Content Guide:
The maximum size for a canvas element is 3 megapixels for devices with
less than 256 MB RAM and 5 megapixels for devices with greater or
equal than 256 MB RAM
So if you want to support Apple’s older hardware, the size of your
canvas cannot exceed 2048×1464.
But that’s not all! Even with smaller sizes, you have to keep your
canvas’s aspect ratio between ~3/4 and ~4/3. If you step outside those
boundaries, webkit seems to switch to a totally different rendering
mode splitting the canvas into multiple fixed-size areas and rendering
them separately with a noticeable delay between them.
There doesn’t seem to be any documentation on this but I have
confirmed this happens on both Chrome and Safari on iOS versions 6.0.1
and 5.1.1.
source http://blog.toggl.com/2013/05/6-performance-tips-for-html-canvas-and-createjs/
I have an app that works on iPad 1st gen. This is a game, made using cocos2d framework.
The first iPad does have 256mb ram and using instruments(the memory monitor tool) i was able to determine that the app works at around ~90-110mb ram on the device (well lets just trust "Physical Memory Used" chart though the "Physical Memory Free" at the very beginning shows it is ~128mb free and then gets to ~3-4mb free after playing several levels and never gets higher)
So while it does have enough memory it caches the assets and when it runs out of ram the cached assets get released.
What i did is added the high res graphics to it. Almost all of the assets are loaded as 4bit assets so say if i have an asset 100x100 pix it will consume 100x100x4 = 40000 bytes ram; the same hd image will be 200x200 pix and will consume 200x200x4 = 16000 bytes ram; which is 4 times bigger!
So the question is - will it work fine on iPad 2 hd screen which has 512mb ram?
See if i multiply ~110mb*4 it will be ~440mb, what means it will be 512 - ~440 = ~72mb left for system. So i do not know if that is enough for system and it won't close the app. I am not sure but i think the 1st gen iPad may give around ~120-130mb ram for the app and then will close it. So that makes me think this won't work on the iPad2. Am i likely correct?
ps: i've tested the app on the 3d gen iPad which has 1gb ram and it runs just fine
The iPad 2 has the same screen resolution as the original iPad, so it will not use the new retina artwork that you are adding to the app. This means it should run fine on the iPad 2 if its already running original iPad.
The iPad 2 does not have a retina screen, so the physical resolution of the iPad 2 is the same as on the iPad 1. Only do the retina style images on a device that supports it, this way you keep memory low on device that can't handle the retina resolution.
When i maximize an air window that has no chrome (no system chrome, no flex chrome but i think it's the same even if only flex chrome is used) a few pixels on all sides go offscreen.
Anyone has a solution for this or knows why it happens?
It's actually easiest to set the air window to the size of the monitor, then set your custom UI to the size of the monitor minus a few pixels. That's the only workaround that I've come up with.
The only downside to this approach may be a small rendering performance loss, since the AIR window has to take alpha transparent pictures of everything behind the window, but this likely so minimal that it won't make a difference (I invite someone to benchmark this).