So I have multiple controls I want to render scenes to.
I have a Device instance for each control as well as several other objects like shaders I need to compile for each control and so on.
I wonder if this is a good approach to have multiple devices and all the objects for each control?
I get pretty good performance from it though. It's just I want to save memory and setup time. Because for example the shaders are the same for each instance and need to be loaded and compiled each time. I can't have them statically because they are restricted to the same device when I tried. I tried to make the Device static and so I can have the shader objects static too, but I seem to run in a problem where the context gets corrupted, even if only one thread executes them. Maybe it is because I can't rely that the GUI thread will always finish the context (which is statically used by all controls) state and render before going to the next and this corrupts my state.
So my issue and concern is more about the memory it needs and time to load (feels pretty slow and heavy), than the performance of drawing (which is pretty good and satisying). I read there are no "best practices" in general but maybe some of you have some hints what I could improve.
Thanks for any help
Instead of creating a different device for each control, I think it is better to create a different swap chain for each control and all controls/swapchains to share/be created by the same device.
Related
I have Windows Form that I use for a trading application, which, of necessity, has to display a large amount of information updating very rapidly (4 times per second).
The Windows Form I'm using has lots of controls (over 150 buttons and textboxes), and 6 datagridviews with multiple rows to display the information.
I have using different threads to perform the time-consuming operations (HTTPRequests, and various mathematical operations), but I am still finding that the GUI feels sluggish. I've noticed, in particular, that when I add more controls to the Form, things slow down, even though these extra controls are really 'doing' anything.
Can anyone explain why the mere presence of extra controls should make the GUI less responsive and/or recommend a completely different approach? Maybe I shouldn't be using Windows Forms?
Thanks.
It is hard to say something concrete without knowing your code.
A few generic ideas:
From your description, it sounds to me, like your application is very busy with repainting all the controls. Try experimenting with SuspendLayout() and ResumeLayout() and Invalidate() only those Controls that really need repainting.
Check if DoubleBuffering is enabled on both the Form(s) and ChildControls, it should be activated for most controls by default. But make sure you have it on.
Depending on your used .NET Frameworkversion check if you can use async/ await features for keeping the responiveness up.
See article MSDN Magazine article "Give Your .NET-based Application a Fast and Responsive UI with Multiple Threads". This one is a few days old, but still absolutely valid.
Some events are fired more often than you expect or need. Check those events that cause repainting of controls (i.e. this will be where you add values to be displayed to the user) if these fire too often.
Your controls take a lot of memory and I wonder why you have so many, have you considered creating controls on the fly as and when needed. Double Buffering is a must but will not help if you are clogging up memory as it is for graphic display. You need to profile your program using performance counters to find out where the problem lies, are you disposing correctly for instance?
Also are you using too many threads? Are you using the thread pool, if not you should be!
Are your controls loaded with data?
I will think some more but profiling is what you need to do next.
I have a lighting system in my xna game that loops through each light, and adds these lights to a final light map, which contains all the lights.
The process to create these lights involves many functions that have to do with the graphics device, such as using effects / shaders and drawing to render targets, and using graphics.device.clear to clear the render target, etc
So my question is, would it be possible to multi thread each light? Or would this not be possible because there is only 1 graphics device, and only 1 thread can use it at a time? If it is possible, would it improve performance?
Basically no. The GraphicsDevice in XNA is single-threaded for rendering. You can send resources (textures, vertex buffers, etc) to the GPU from multiple threads. But you can only call Draw (and other rendering functions like Present) from your main thread.
I have heard of people having success doing rendering-type-things from multiple threads with the appropriate locking in place. But that seems like "bad voodoo". As the linked post says: "the XNA Framework documentation doesn’t make any promises here". Not to mention: even getting the locking right is tricky.
I'm not really sure about making multiple graphics devices - I've not tried it myself. I think that it is possible, but that you can't share resources between the devices - making it fairly useless. Probably not worth the effort.
As jalf mentioned in a comment on your question - once you get to the GPU everything is handled in parallel already. So this would only be useful if you are CPU limited due to hitting the batch limit (because almost everything that isn't your batches can be moved to another thread). And in that case there are many optimisations to consider first to reduce the number of batches - before trying a crazy scheme like this. (And you have measured your performance, right?)
It sounds like what you might be trying to do is render a fairly complicated scene to a render target in the background, and spreading the load across many frames. In that case - if performance requirements dictate it - you could perhaps render across multiple frames, on the main thread, scheduling it manually. Don't forget to set RenderTargetUsage.PreserveContents so it doesn't get cleared each time you put it on the graphics device.
I currently use DevExpress controls heavily in an application. The controls are great and speed-up development time dramatically (and hence, I wouldn't want to ditch them) however, I have a few issues with their performance.
My application is a Shell/Modules/Views&ViewModels application (it follows a lot of the design patterns you would find in Prism).
When a view is first loaded it takes an extremely long time to display (on some of my users PCs with slow machines we're talking 5+ seconds of just hanging there). The time it takes apparently depends on the usage of DX controls (how many ones are on there that haven't been seen before by the application).
When you destroy the view and re-open it, it opens in less than a second. The ViewModel in my test cases/performance profiles has been made to re-create each time - so there is no shared state within my code between invocations of the view (no singleton injected objects).
After a bit of discussion and research I appear to have narrowed down the problem to on-demand loading of the template files for the DX controls.
There is a thread here about that:
http://www.devexpress.com/Support/Center/Issues/ViewIssue.aspx?issueid=Q382256
which references:
http://www.devexpress.com/Support/Center/p/B201967.aspx & DevExpress controls for WPF load time
The solution described in these threads is to either display a loading indicator or to use a hidden window with controls on it at start-up. Neither of these options are something I'd like to do (and the hidden window option didn't appear to gain much performance when I tried a simple example, interestingly - which also suggests that I might be missing something).
What I am hoping to do is to pre-load template files that I know I'm going to need on a background thread. Is there any way I can do this in WPF? (I'm thinking this is more a general WPF thing rather than a DevExpress thing - even if it's something that needs to be implemented in the DX libraries themselves).
Any ideas for either me or the guys at DevExpress?
What you can do in the background thread is to preload all the required assemblies. Also make sure they are nged-ed. The UI controls need to be initialized from the UI thread.
I'm making a loading screen for a game in c#. Do I need to create a thread for drawing the spinning animation as well as a thread for loading the level?
I'm a bit confused as to how it works. I've spent quite a few hours messing with it to no avail. Any help would be appreciated.
Short of anything that XNA may provide for you, anytime you require doing multiple units of work at once, multiple threads are usually required - and almost certainly if you want to benefit from multiple CPUs. Depending upon exactly what you're looking to do, you're already in one thread (for your main method / program execution) - so you don't likely need to create 2 additional threads - but just one additional for either the loading of your level, or for the animation.
Alternatively, as was probably more common-place in older development when developers weren't concerned with multi-core CPUs, etc., you could use tricks such as doing both the level loading and the animation in the same thread - but at the expense of additional complexity for combining both concerns into the same unit of processing. (In every x # of lines of processing for loading the level, add code to update the loading animation.) However, given today's technology, you are almost certainly better off using multiple threads for this.
Loading takes time because it makes long calculations and long calculations are usually done in a different thread so that the program woun't freeze.
So the answer is yes.
I develop a utility that behaves like "Adobe photoshop". user can draw rectangle,circle,... with mouse pointer and then move or resize it. for this functionality, I assume each shape is a object that stored in a generic collection in a container object. when user wants to change anything I recognise that where he clicked and in behind of scence I select the target object and so on...
this way have a problem when objects in screen is lot or user loads a picture with high resolution.
What's your opinion?
How can I solve it?
This makes sense because the larger the data set, the more RAM and CPU will be required to handle it.
While performance issues are important to solve, a lot of it may be perceieved performance so something like a threading issue - where you have one thread trying to process the information and you block the UI thread which makes it look like the system is freezing.
There is a lot of information on StackOverflow that you may want to look at
C# Performance Optimization
C# Performance Best Practices
C# Performance Multi threading
C# Performance Collections (Since you said you were using a collection)
Use a profiler such as dotTrace and find out which method is the one most called and the one that takes the most amount of time to process. Those are the ones you want to try to optimize. Other than that, you may have to go down to the GPU to try to speed things up.
About these kind of problem, think about parallel extensions :
http://msdn.microsoft.com/en-us/concurrency/default.aspx
The more cpu you have, the faster your program is running.
The thing is that in hi resolution the computer needs to use more the processor, then this occurs, remember that this also occurs in The Gimp, even in Adobe Photoshop.
Regards.
Look into using a performance analyzing tool (such as ANTS Profiler) to help you pinpoint exactly where the bottle necks are occurring. True graphical computations on a high res photo require alot of resources, but I would assume the logic you are using to manage and find your objects require some tuning up as well.
I high-resolution image takes up a lot of memory (more bits-per-pixel). As such, any operation that you do to it means more bits to manipulate.
Does your program utilise "layers"?
If not, then I'm guessing you are adding components directly to the image - which means each operation has to manipulate the bits. So if you aren't using layers, then you should definitely start. Layers will allow you to draw operations to the screen but only merge them into the base high-resolution image once - when you save!
What library from Windows are you using to open the image?
If you are using System.Drawing then you are actually using GDI+ as it is a wrapper on top of it. GDI+ is nice for a lot of things because it simplies tons of operations, however it isn't the fastest in the world. For example using the [Get|Set]Pixel methods are MUCH slower than working directly on the BitmapData. As there are tons of articles on speeding up operations on top of GDI+ I will not re-iterate them here.
I hope the information I've provided answer some of your questions causes new ones. Good luck!