Background: I am currently using custom controls within my C# project (basic controls just drawing a custom look and feel (using gdi+?)). The majoritiy of these controls have transparent segments for irregular shapes etc.
Problem: I am looking to overlay a semi-transparent (irregularly shaped) panel over a group of controls. Currently I Clip the covering panel to the region of the controls involved. This works fine and the results look good, however the process is so slow.
Question: Is there some manner I can speed up the rendering process by mixing in a little OpenGL/DirectX and getting the video card to perform all the necessary rendering rather than relying on the rather slow CPU?
AFAIK you can't really mix GDI+ and OpenGL/DX.
If you're getting slow performance and are absolutely sure that it's a bottleneck in GDI+ rather than in your code, than it could make sense to ditch GDI+ and replace it with DX/OGL. (You would have to write your own controls, though, which would be a major pain in the #$$)
Or, for a simpler approach, try WPF/Silverlight! It's customizable and skinnable by default and it's based on DX.
Look at WPF and Silverlight. you would sleep better at night.
Did you try turning on DoubleBuferring on your controls to see if that gives you a performance boost?
http://www.codeproject.com/KB/graphics/DoubleBuffering.aspx
Related
If I'm looking to create a game that doesn't necessarily run full screen, but simply needs to feature 2D/3D graphics somewhere in a portion of the screen, what's my best approach?
Some specific questions could be:
What component would the rendered area use?
Are there any game libraries I could leverage for the rendered area?
What would be the most "pure" or "canonical" stack according to Microsoft to use here?
Omega --
Visual Studio 2010 and 2012 are Both WPF apps. WinRT is for Tablets / Mobile. WPF is certainly NOT outdated.
If I were you I wouldn't render everything out the way canvas forces you to, it might be a better approach to have the center item be a UI element named Frame, which is the base element for all UI related content in WPF.
In this way you would be able to leverage all of the possible types of controls in the Frame whether you decided that An ImageSourceType or Canvas is more applicable to a particular features of the game.
Depending on how you want to draw graphics, you could use (but are by no means limited to):
Canvas - which would be totally appropriate for slow moving games. This way you get the benefit of the various WPF layout routines and can define objects inside the scene in XAML/vectors as well.
WPF supports 3D graphics (using Direct3D on the backend) so you could probably set up an orthogonal projection matrix and treat it like a Direct3D context (with the WPF API). I don't have enough experience to know how slow this is compared to D3D, but it's certainly easier (built-in "scene graph" like support from the XAML architecture, for instance).
If you want to go whole-hog with Direct3D you could use SlimDX, which has a WPF shim that I've used in the past, as well as another third party control. There may be other libraries available as well.
Direct blitting to/from a Bitmap using WriteableBitmap (see WriteableBitmapEx for a third-party version with a much friendlier API) or similar.
There are probably a lot of other options too. My preference would be for using Canvas initially if it's a slow-paced game that doesn't need super-fast frame rates (the layout work does incur a fairly substantial overhead, but it's less work and may be easier to get looking exactly the way you want).
If you want absolute control and speed, use D3D through SlimDX, but this is a pretty hefty learning curve if you're new to it.
Is it good practise to build my UI with minimal images and define things like shapes/paths etc in the XAML?
If so, what are the advantages of this approach and/or other approaches?
In my opinion, having been creating UIs in WPF for the past 7 years, yes it is good practice in general. However, it depends entirely on the aesthetic you want to provide. Static images add to your application size but can be easily cached making them performant. They're a little inflexible as an image will distort the second you try to stretch it's dimensions. Images are fine if you don't need it to be dynamically sized.
However, you'll find that defining your UI entirely with markup can be a lot more complicated and can stray from your pixel-perfect mockups at various sizes. Gradients produced in WPF are inferior quality, you'll see visible banding if the gradient spans too far.
Performance doesn't play much of a role unless you intend to use a lot of DropShadowEffects (do not use legacy BitmapEffects). Stick to the lightweight elements (such as FrameworkElement) when templating controls.
By the way, there's a fantastic and recently free icon studio called Syncfusion Metro Studio 1 which is a fairly extensive icon pack that allows you to customize the size, background, foreground, & padding, then it lets you choose if you'd like to save it as an image or export it as a XAML path. The benefit of using XAML paths are that they will be perfectly scalable and you can dynamically change the fill color, could be set by the user even. Something that is possible with images using a custom color overlay shader but very resource intensive.
I need to write a complete diffrent looking textbox than the original winforms textbox. In fact I need a different background, how can I achieve this? I tried owner drawing with SetStyle(ControlStyles.UserPaint, true); but this caused a lot of flickers and the text was completly wrong drawn, wrong font, size etc.
Wrtiting a textbox from scratch would be overkill, I think.
This is not possible. The TextBox class is a wrapper around a native Windows control that has been around since Windows version 2. It had to run on some seriously sucky hardware, they had to break a few rules to make this work. One of which is that it draws parts of itself without using the standard Windows paint cycle. Invalidate() and OnPaint() in Winforms terms. Fixing this behavior wasn't possible due to app-compat problems. Way too much code out there that hacked the control in creative but unpredictable ways.
Accordingly, it isn't possible to intercept the drawing to prevent it from erasing parts of your background image. There is no workaround for this, creating your own is a lot of work. Consider WPF.
If you specifically need a different background on a text box, one work-around is offered here.
I am doing a small project of my own - A Fractal Generator.
Would th einbuilt graphics of C# be adequate or would WPF be preferable? I've never had a look at WPF, is it complicated and is it worthwhile learning?
Yes, WPF is
perfectly
fine
for
this task.
WPF was designed to replace GDI+/System.Drawing, so it contains most of the low level bitmap stuff you would expect (only this time with hardware accelleration) which can mostly be found in the namespace System.Windows.Media.Imaging.
The only API that might be superior in terms of functionality and performance (but not necessarily ease of use) could be the new Direct2D.
WPF is more about creating the overall UI for the application, with rich integration between the data and the visualization. For the purpose of actually generating your fractal, it won't matter whether you use WPF, although the way you display the result in the UI will differ in WPF vs. WinForms. In either case, you're probably going to want to output directly to a locked Bitmap buffer.
If you have more experience with WinForms, I'd recommend using that for now, so that you can focus on the application code. WPF is worth learning, but it definitely has a learning curve.
WPF is a GUI framework, not a graphic framework.
For a fractal generator, all you need is a way to display or write on disk an array of pixels. System.Drawing is more than enought.
Now, if you need advanced graphical interface to surround that, by all means, go for WPF.
I am developing an application using WPF. The app runs full screen, and I need it to resize nicely no matter the monitor resolution. The graphic designer has designed beautiful images for the UI buttons, backgrounds, etc. Using an Illustrator plug-in, all the images have been converted to xaml files. I've added all these images into the application, and they look great. I am also using a lot of Grid layouts so that the screen can resize while still maintain the layout. All of this is displaying as desired, nothing looks stretched when run at a different resolution. However, screen transitions and UI interaction are slow.
I am wondering, is this is due to the heavy use of graphics? Am I using too many Grid layouts? But, I need the Grids so that I can have resolution independence.
The application runs fine on my development machine, but is very noticeably slower on machine with lower performance capabilities. Yeah, this is to be expected, but not to the degree that I'm seeing. My employer insists the application runs smoothly on these lower performance machines.
I've done some profiling of the application and it seem that what takes the most time is the display stuff (though I'm not sure I fully understand how effectively to use a profiler).
If it is the WPF that is causing the slowdown, what can I do to improve this?
You can drill into which WPF activities are using up time using the Performance Profiling Tools for WPF. Assuming a heavy graphical load is causing the slowdown, this should give you some help as to what might need to be simplified (e.g. layouts) or removed (e.g. bitmap effects (these are a classic perf killer, though I don't want to prejudice your profiling!)).
If it is the WPF that is causing the slowdown
Probably not ;)
It is much more likely that it is your code that causes the slowdown. WPF is powerful, but you have to understand the core concepts to make it work well... You should have a look at this video from a PDC session, it provides lots of advice on how to make your WPF application faster
Convert your XAML Vector Images of buttons into Transparent PNG Images. Path and Shapes are very heavy to render, calculate and resize. Mostly after deployment, the images never change its better to have them as raster then vector, unless you want to perform smooth animation of changing shape, size or other attributes.
Grids are very costly layout managers as compared to Canvas, DockPanel. You can certainly think of replacing certain grids with DockPanel sometimes, but yes its not an easy fix it requires lot of brainstorming.
Avoid Panel with Single Child. Try to reduce Visual Hierarchy.
Use more of fixed size for buttons and such small elements, if you specify fixed sizes of children, it becomes easy for Panels to do layout processing.
In general, WPF is perfoming much worse in drawing performance than Windows Forms, and native GDI or DirectX.
Yes, WPF is powerful in the sense you might make some neat stuff that is not supported in GDI, but it is more sluggish.
If you are having much drawing to do, and you want to support it on slow hardware, then WPF is not a good choice.
WPF performance depends heavily on the quality of the video card in the machine more that the processor/memory. Bad video card = bad WPF performance.
Well, this is a long shot: when I installed VSTS 2010 (and it uses WPF) it was very slow on a Windows 2008 server with enough CPU/memory, and very fast in a more modest notebook. We managed to disable hardware acceleration and it became notably fast into that machine.
Maybe you do want to try this configuration, as it is very simple: Visual Studio 2010 Beta 2 editor performance fix running on a virtual machine