Force windows to use the best graphic card available - c#

I have a WPF application which has a small 3D Engine on some specific pages (integrated via WindowsFormsHost).
I've seen that on many laptops with several graphic cards (dedicated and integrated) Windows would by default use the integrated one which in many cases will not be good enough to run my 3D Engine.
For example all my games are automatically executed with the dedicated GPU. Is there a way to show windows this WPF application needs the best GPU available ?
I understand that you can change that choice in your graphic card's settings but it's a complicated manipulation for most of the final users.

These two threads might be helpful:
- https://gamedev.stackexchange.com/questions/58546/how-can-i-set-my-application-to-run-on-the-high-performance-gpu-by-default
- https://stackoverflow.com/questions/16823372/forcing-machine-to-use-dedicated-graphics-card Christopher Oezbek's answer may be of interest
- https://stackoverflow.com/questions/29504891/laptop-dual-video-cards-how-to-programatically-detect-and-or-choose-which-one
The solution posted by axon seems promising

Related

How to forward output of a directshow app(C++) to a C# app?

I am making a C# app to capture graphic from an avermedia pcie capture card.
But it seems that there are no out of box tools to do so.
So I made a C++ directshow app to do the capture, which is a console app and opens a capture window when running.
How can I redirect the output to a C# app? for example, to a CaptureElement?
So you want to have XAML CaptureElement connected to AverMedia PCIe capture card. This sounds like a well-understood challenge overall, however every other piece of technology you mentioned is eventually a bad choice: DirectShow, multiple apps with piping, redirection and fitting of cutsom code to XAML CaptureElement control.
Microsoft has intentionally been limited ways you can integrate different APIs and so there are not so many ways to get everything together.
Let us go over the supposed integration path. The capture card is supposed to be shipped with a compatible driver:
Video capture devices are supported through the UVC class driver and must be compatible with UVC 1.1
When this is the case, such devices are visible to Media Foundation API handling video capture among tasks. XAML CaptureElement would be able to see a video capture device through this API and this way everything is supposed to work without need to fit anything from your end.
If this is not happening, it suggests you are dealing with an unsupported device coming without suitable or compatible driver.
Previous media API in Windows was DirectShow but its days are gone. It remains perfectly working as a legacy framework, a lot of applications out there are still relying on it. Specifically it will not integrate with new technology like XAML and UWP. More to that, even Media Foundation itself, the current media API, in its public offering is lagging behind when it comes to fitting with most recent technology. Having said that it is a good idea to stay well clear of DirectShow here if this is at all possible.
I see no need for cross-process design with video travelling between process through piping. There is no good reason for such design and even though this can work efficiently (Windows itself proves it can work great in terms of performance by having so called Frame Server service in it), this is not to be built on piping. In your case it is unlikely to be have to be built on multiple processes either. Instead you can develop a native code DLL project that takes care of video acquisition and connects to managed code via suitable glue layer: C++/CLI, COM, C++/WinRT and such.
Then next thing is fitting to XAML CaptureElement. The control is designed to work with Windows.Media.Capture.MediaCapture class that talks to hardware and you don't have suitable hardware as you plan to implement your own acquisition layer. Long story short you are not supposed to forward external data to CaptureElement and you would have hard time doing this. Your best strategy is to upload externally obtained data to Windows.Graphics.Imaging.SoftwareBitmap or alike and take involved performance impact as acceptable. That is, you will be dealing with video frames as images.
An alternative way is to upload acquired video frames into Direct 3D 11 textures and it would open you a more performant way of integration with video related controls, such as Windows.UI.Xaml.Controls.SwapChainPanel however it would also require that you put much more development effort in there.

Building a poker game with shareable c# code base for Windows, Windows RT and Windows Phone

What are my options if I want to target Windows XP and above desktop OS, Windows RT and Windows Phone 8 for a Poker app which includes both a substantial amount of GUI as well as graphics/animations. Would prefer the whole drawing to be hardware accelerated for a smooth experience.
We already have a C# & WPF based code base that we would like to use as the starting point for a shareable code base. I want suggestions that would allow us to utilize the existing code base which is already modular to a considerable extent. Moving to an entirely different platform is not an option at the moment.
I understand that Windows Phone 8 also supports C# + XAML for development. But is the drawing hardware accelerated?
If I plan to use MonoGame, would it be too tedious to build up the GUI bits?
Monogame is great engine. You can easily achieve resolution independent rendering with it so you can have solid coordinate system for your GUI textures which will nicely fit into virtualy any resolution. It is also quite flexible and cheap (android, iOs) comparing to other engines. The code is highly reusable across the different platforms. The most code differences are in input handling and file management which are usualy specific for different platforms.
The downside of it is that it lacks any editors and handy tools like in Unity engine. It is pure engine and you have to build/gather your own instruments for all the tasks you want to acomplish. So the task of creating the GUI can be tricky if you need to implement some complex stuff such as physics or some effects. But simple animated GUI is not a problem. There are also several GUI libraries with controls for Monogame:
https://nuclearwinter.codeplex.com/
https://xnagui.codeplex.com/
PS: For windows you can merge Monogame with WPF but i doubt you can successfuly use XAML interface in monogame for windows. It will likely be pure WPF or pure Monogame.
If you decide to stick with monogame feel free to look for my samples and tools collection at: http://panthernet.ru/forum/index.php?/topic/17-monogamexna-examples-v18/

Wpf performance hungry test app to test if Citrix is using GPU for rendering and if it makes any difference

We have a Wpf app hosted by a single Citrix Server used by up to 8 remote users. The WPF app is usually used with a high resolution and multiple monitors at the same time so we want to make sure the GPU is used for rendering instead of CPU.
We are using grids, canvases, checkboxes and all kind of WPF controls.
I want to test if it adds any value to use 3D acceleration hardware on the Citrix servers because we are about to order new hardware and I am not sure if it is worth spending the extra money.
Some info is given away by Citrix on link below so I think of writing WPF "hungry" test app but I am not sure what it should look like.
http://support.citrix.com/proddocs/topic/xendesktop-7/hd-3d-gpu-acceleration-win-server-os.html
EDIT
Any idea what this WPF app should look like so I can make sure it uses GPU or is there a better way to test this? Which wpf controls should I use in the test app or is there similar test app written already?
Many Thanks
As a general rule, the composition of your WPF app will not affect whether the CPU (software rendering) or the GPU (hardware rendering) is used. WPF will always use hardware rendering when it is available on the machine, and will fallback to software rendering if it can't find hardware support.
Having said that, there are some things that WPF will always render using software rendering. E.g. the legacy effects derived from BitmapEffect.
You can use the WPF perf tools to see whether software rendering is being used:
http://msdn.microsoft.com/en-us/library/aa969767%28v=vs.110%29.aspx
The Perforator tool has an option to highlight sections of the app rendered in software with a purple tint.
So to answer your question, pretty much any WPF app you can create will use hardware rendering, just don't use anything derived from BitmapEffect. You can double check that software rendering isn't used by running the app on your desktop first and using Perforator to profile it. Once you've confirmed it doesn't use any software rendering you can test it in your Citrix environment with/with-out 3D hardware installed to see what kind of performance improvements you get.

How to make a winform open like Mac OS animation?

Could any one tell how can I open a form with an animation similar to the one used by Mac-OS launcher. I have seen a few other software doing the same thing. For eg: This youtube video also shows a demo of it (#Time: 20 sec and #Time: 28 sec).
I know of animateWindow API, but I think this is not possible with animateWindow.
Any idea on how to do this?
AnimateWindow won't fit the bill.
In my opinion these programs work by
Creating a transparent window when needed, while computing icons to display
Creating the animation and displaying it on the transparent window device context
Handling everything on the window via custom events.
What you need is
a comprehensive knowledge of GDI32
an equally comprehensive knowledge of those dirty tricks used to create animations programmatically.
I'm sorry, but I think that this is not the kind of topic that can briefly explained on a single answer :-(
Eventually, you need something that augments and extends Windows's native graphic capabilities. There are companies that did this before: IIRC Serif.com did write their own GDI replacement for their DTP programs, and I think that all of these companies that make desktop enhancements did the same (or at least, they know how to squeeze GDI32 capabilities)
You could try WPF or SilverLight or mixure of above to meet your requirements.
You can check Good WPF or silverlight windows gadget examples and let me know.

Desktop Version of Google's Annotated Time Line Component?

I've been using Google's Annotated Time Line Visualization component for the last couple of weeks and I love it! I've been able to make plots with about 10k points without much trouble.
Do you know of a desktop component I could plug into my application that delivers the same WOW factor that Google's component does? I don't care what the language/toolkit is. I prefer C#,Java,Ruby,C++ or Python... (in that order) however any other's would apply. I also prefer it to be free and open source, but if it's not that's OK as well.
Thanks for your time!
Note: This doesn't have to be cross-platform. Windows is fine.
Edit (2009-08-07):
Even if I can only plot 10k points, I am fine with that. I would just like a desktop control that delivers the same "wow" factor and works in a similar manner (zooming, scrolling, annotations, etc) that the Google component does.
Edit (2009-09-03):
I really prefer the language to be C#. I started a bounty to see if anyone can find some good ones. I want it to be almost identical to Google's Annotated Timeline Component. I would use Google's Component, but I want a desktop component... and I don't want to run into performance limitations because of the browser. Using Adobe Air is out of the question.
Edit (2009-09-03):
Do not recommend Visifire. I have evaluated it, and it doesn't support zooming. Remember, it must be very close to Google's component in terms of functionality and "wow" factor.
This WPF-based chart control at codeproject may put you in the right direction. It's got smooth panning/zooming/scrolling :
WPF Chart Control With Pan, Zoom and More By John Stewien
If you're needing to plot millions of points, you're going to run into performance issues quickly if the control doesn't have a mechanism for loading/sampling only what it needs to display. Even then, that's a very large number of data point to want to access in one control.
Hm i am not sure if this is what you are looking for, but for java there is the very good library JFreeChart which is not exactly as interactive as the one you mentioned but it is really easy to use and pretty flexible for you to subclass and tweak to your preference.
Perhaps you could take a look at matplotlib. It's a python based library, however it's very flexible in that it can take it's input from a variety of sources.
An alternative is to embed a web browser control in you wpf application. You'll probably need access to the DOM, so you might have to use the WebBrowser in a WinForm. A good article descibing how this is done can be found here.
Microsoft also has free chart control you can get at http://www.microsoft.com/downloads/details.aspx?FamilyId=130F7986-BF49-4FE5-9CA8-910AE6EA442C&displaylang=en. It's pretty good--especially for being free.
I have used Dundas charts in the past. They are excellent but pricey. There are several other vendors with good chart controls including DotNetCharting, Telerik, Component Art, and Infragistics.

Categories

Resources