I have been tasked with developing a game for an embedded device developed by a 3rd party.
The device runs Windows XP - win monitors. The game MUST use DirectX9 (D3D9Ex is forbidden).
The 3rd party replaces the directX9 DLL's with their own in-house developed D9D libraries. The reason being that they sometimes need to display notifications into our scene. I believe the Games Library 'Steam' does something similar. Behind the scenes, i suspect that they forward calls into the real D3D libraries, and Hijack the Present() call for extra rendering.
My problem is - One of the unrelated background applications developed by the 3rd party keeps crashing. This pops up the familiar 'Whatever.exe has encounter a problem and needs to close, sorry for the inconvenience.'
When this happens, my fullscreen application loses focus, and the d3ddevice enters the lost device state.
The game then does the usual lost device recovery dance. This works perfectly when linking directly against the Microsoft D3D libraries. HOWEVER, when linked against the modified 3rd party libraries - And the device becomes lost whilst the modified DLL's are rendering notifications to our window, the d3ddevice->Reset() fails. Not all D3DPOOL_DEFAULT textures have been released. The 3rd party has confirmed that the modified DLL's will fail on a lost device. Furthermore, they don't consider this a bug in their modified DLL's.
The 3rd party consider this a bug in my code. They say that the bug is that my game lost focus in the first place.
I have claimed that the bug is not on my side. The bug is:
modified DLL make a lost device recovery impossible.
3rd party background application crashes, causing Dr.Watson to gain focus.
The 3rd party claim that other developers don't share my problem, And other developers are creating games in fullscreen exclusive mode. TLDR: What more can be done !?
Windows are created with CreateWindowEx with dwExStyle WS_EX_TOPMOST.
A single D3DDevice is created for both windows with the D3DCREATE_ADAPTERGROUP_DEVICE flag (Different SwapChain per Window).
Is it really my fault for losing focus!?
Is there anything more I can do?
Thanks in advance for any advice.
Related
After entering into phonebook or gmail or playing YouTube through the testing application, I am losing all the controls to test or query. As soon as it comes into play I lose control. Then I have to manually deal with it. On writing tree on Repl mode I am not able to see anything.
This is because you are leaving the application. Xamarin UITest works by running a client-side server next to or inside the mobile application. the client-side server is what enables us to interact with controls and query for things on the screen.
If you are on iOS, you have to have the Calabash agent installed in the application to make things work. Once you leave the application (switching to YouTube or other app), the client-side server is backgrounded and won't be able to do anything because of how iOS operating system is designed.
On Android, it depends on what version of Android you are using. Older Android versions don't sand box apps the same. Android 6.0 and above have more security controls and I wouldn't expect this behavior to work.
If you are trying to test if those things work, You should be testing that the Intent you are sending is correct. You are really testing the operating system at this point because you are verifying that YouTube or whatever did what you expected. Really we should have a base assumption that when we provide the phonebook with the proper intent, the operating system should behave accordingly. If you test that the video actually opens in the YouTube app, you are now testing if YouTube can open their links/intents successfully. Some people decide to test these things, many find that it is redundant and increases their teams cycle time.
I hope this helps!
Disclosure: I work at Xamarin/Microsoft
I have a bit of a predicament in which I am seeking some advice and I currently have limited knowledge with regards to whole Universal applications.
I currently have a Winforms application that needs to call the CameraCaptureUI control; however, it turns out that this control is native to Windows 8.1 and Universal applications.
At first I was going to convert the application to a Universal; however, this isn't a possibility since it relies on some third party software that isn't available as portable library targetting the .Net Core fraemwork, and is unable to be converted to one at the time.
I thought I might go with a portable library, but this was a deal breaker b/c I couldn't reference the CameraCaptureUI control.
My next logical step was that since this class is unavailable via a regular Winforms project, I thought I could add a Universal project to the solution and use it as a wrapper to call the CameraCaptureUI. I could then perform the processing I needed from within the other executable by seting up a ProcessStartInfo pointing to the executable of the Universal application and wait for it to complete. This would be fine; however, you cannot run a Universal application without the context of an app container.
That brings me to my current predicament. What would you recommend as the best approach to tackling this? I really need to call the executable from the Universal app, or at the very least the CameraCaptureUI, from within the Winforms application. Calling the Camera straight up isn't an option because I need to be able to retrieve the photo(s)/video(s) the user took. I'd also like to keep it to a single installation instance. We do currently use ClickOnce as our deployment method.
Has anyone else ran across this before or could offer some suggestions?
Any advice is greatly appreciated!
Thanks,
Nathan
I'm running my SL5 application (that has been working well so far) on Windows 8, and it is not going well. I have a background picture which usually does not render correctly, almost everytime I navigate my background (including the controls over it) just goes white till I resize IE, then it re-paints (what makes it stranger is that the parts that goes white is outside of the navigation frame, why is it getting repainted). (Chrome renders fine)
When I run my application out-of-browser my login screen pops up and works correctly but after the login screen closes it looks like the gray background of the login screen remains behind and I cannot click on anything, resizing makes no difference, it looks like every control has been disabled.
I have updated my NVidia Drivers to the latest, don't think its a display driver issue though.
Anyone else had these issues? Anyone else running SL5 fine on windows 8?
(Looks like I'll be downgrading back to windows 7 soon)
Silverlight should run great on any desktop browser in Windows 8, just like it does on Windows 7, Vista, and Mac. The underlying runtime is 100% the same. That does not mean you may not find a glitch with a graphics driver, but it means you shouldn't - and likely won't.
I did want to make a clarifying point, however, that Silverlight is not part of the Modern Internet Explorer (the Metro Internet Explorer). Only a subset of Flash is supported and that is only supported on white-listed sites.
This means Silverlight solutions that you might have expected to run on the Surface RT (running Windows RT - or Windows on Arm) will not run (as there is no SL runtime). And, I think we can all have a collective moan and ask, together, "Why not?" To which there is no acceptable answer.
The theoretical goal, of course, is to write native Windows 8 apps. If you want to write something web based you should write it in HTML5. That's the official word. I think we all know that HTML5 has a ways to go in order to catch Silverlight, but it is what it is. Can't change some things.
I have had no issues with any of my Silverlight 5 apps running on Windows 8 - I focus mainly on line of business apps but have some graphical and otherwise apps that run fine as well.
I'm only marking this as the answer to close the case, what the actual answer was to the problem we will never know. The solution: automatic updates. After much hassles with getting automatic updates to actually go through, my machine is now working well.
I have been playing a bit with Silverlight and try to port my Silverlight 3.0 application to Silverlight 4.0.
My application loads different XAP files and upon a user request create an instance of a Xaml user control and adds it to the main container, in a sort of MEF approach in order I can have an extensible and pluggable application.
The application is pretty huge and to keep acceptable the performances and the initial loading I have built up some helper classes to load in the background all pages and user controls that might be used later on.
On Silverlight 3.0 everything was running smoothly without any problem so far.
Switching to SL 4.0 I have noticed that when the process approaches to create the instances of the user controls the layout freezes unexpectedly for a minute and sometimes for more. Looking at the task manager the memory usage of IE jumps from 50MB to 400MB and sometimes up to 1.5 GB.
If the process won't take that much the layout is rendered properly even though the memory usage is still extremely high. Otherwise everything crashes due to out of memory exception.
Running the same application compiled in SL3, the memory used is about 200MB when all the usercontrols are loaded. Time spent to load the application in SL3 is about 10 seconds, while it takes up to 3 mins in SL4 There are no transparencies, no opacities set, no effects and animations in the layout.
User controls are instantied on the fly and added or removed in the visual tree on purpose when the user switches from one screen to another. The resources are all cleaned properly when a usercontrol is removed from the visual tree to allow the GC to operate in the background.
I may do something wrong but I could not figure out where exactly nail out the source of this problem. As far as I know there is no memory profiler in SL4 that can help me out to find where to look at. But again I could not be updated on new debugging tools available.
UPDATE:
Silverlight 4 Service Release to fix Memory Leaks: http://timheuer.com/blog/archive/2010/09/01/silverlight-service-release-september-2010-gdr1.aspx
Silverlight 4 has known memory leaks and the fix is currently being tested.
Here is a Microsoft Thread about it:
The user "heuertk" is a Microsoft Silverlight Developer....he explains the issues and the status of the fix...
http://forums.silverlight.net/forums/t/171739.aspx
To be honest despite your assertion "The resources are all cleaned properly when a usercontrol is removed from the visual tree" this where I'd start looking. It really does smell of elements of UserControls not being released properly.
This typically occurs when there are long lived (for example static) objects that raise events that more transient objects attach to. If these event handlers aren't detached it leaves these objects hanging around in memory.
I am keep testing and would like to share what I discovered so far.
It might be helpful to understand the behaviors of SL4.
Since it sounded pretty weird the UIThread can take so long to render a bunch of graphic components and considering Microsoft has improved the render pipeline, I have reverted my solution to SL3 but I have kept SL4 installed on my localhost.
The application uses RIA Services and moving back and forth to SL4 means that I have to do some changes in the code as per released documentation.
The application runs extremely smooth more than it was if it is tested with Visual Studio 2008. The memory usage is lower than it was before when SL4 wasn't installed.
As soon as I switch to VS2010 it is a completely different scenario. Memory grows undefinitely, the layout is slow to catch the user interaction and sometimes it freezes as before explained.
I have disabled RIA Services, by using standard Rest service and the process hasn't changed in quality.
In conclusion, considering I will keep testing in order I can finally understand what is really preventing to get the application running in an acceptable mode, I believe the memory issue is due to the debug process of VS 2010 or a combination of VS 2010 and SL4
Just for your info: there is a memory leak when using Silverlight Toolkit Charts in Silverlight 4.0. This is a known bug and Microsoft is working on it.
Silverlight 4 is Leaking everywhere. It Doesn't release memory properly.
I'm maintaing a Windows Forms application which draws map data with overlays. I've been considering a move to WPF for the drawing layer, to take advantage of the graphics card rendering. In the last couple of weeks, however, I've started to have some doubts:
The new release of Evernote uses WPF, and doesn't run on Nvidia Quadro cards.
A WPF transitions demo from WindowsClient.net stopped rendering part-way through the animations on one of our test portables with Intel graphics (and yes, we had the latest Intel drivers).
Stack Overflow questions like this.
With the current Windows Forms codebase I can expect the application to run identically at every installation. WPF is much more dependent on the quality of the graphics card drivers, and I don't have the testing resources for comprehensive coverage.
I'm particularly interested to hear from people who've delivered a WPF application outside their own company or to a mixed population of machines - did hardware and driver specific bugs cause you a significant support burden?
We are facing some issues with the drivers of a specific graphic card vendor. Blue screens, a diagonal pixel displacement and application crashes have been observed. It is possible, however, to turn off the Hardware Acceleration on a per-application basis. Sad but true, this is the current workaround.
As already stated, I hope that the VS2010 release will help to improve the stability. Perhaps one day we'll see lists of WPF related fixes in the release notes of graphic card drivers. Along with the latest fixes for the game engine XYZ.
Our WPF application is running on Windows XP SP2 (minimum) and is ok apart from on some machines, if the application is running and the PC goes into screensave mode it blue screens and crashes the machine. This seems to be graphics card driver version related - some of our users run dual monitors.
We haven't cracked this issue yet.
WPF uses Direct3D for its rendering, falling over to software if necessary. My best guess is that some drivers say that they support something in hardware but really don't handle it properly, and that is when we see these incompatibility issues.
The answer to your question depends on how willing you are to have less compatibility with machines than your current codebase has. If you've ever visited support forums for PC games you see all sorts of threads about graphics problems. As most PC's are going to be more and more compatible with Vista/Win7 and therefore support D3D9/10, the issues should lessen. The real question is if the tradeoff for you is worth it.
My own experience deploying a WPF app, I had issues with the mediaelement not working the same on two very similar PC's. But the video subsystem is a different can of worms anyway. Otherwise it was fine but I wasn't doing anything special graphically, just standard xaml.