I am writing an application that can potentially have hundreds of custom user controls on a canvas. All of them can be dragged around the screen, and there are lines connecting all of then to at least one other user control. Once you reach 250 custom user controls or so performance starts to markedly decline, with frame rates going to 10 or below.
Are there any best practices or ideas on how to optimize performance in this sort of situation? The problem seems to be in the sheer number of controls on the canvas at any one time.
Thanks!
~Steve
Unfortunately no...it becomes a system resourcing issue.
One way to alleaviate this issue is using virtualization in some form or another as was done with the VirtualizingStackPanel. This boils down to removing items from the visual tree and holding a reference to the needed item once it needs to become visible. Not forcing the item to render will significantly reduce the needed system resources. If all the items need to be rendered at a given time it becomes a system resourcing issue at that point. Keep the control as small as possible and keep things such as anotmation to a minimum as they are taxing on the system.
Related
We have to work with very large models and we're hoping to use the first person camera to walk through them, and eventually do this in VR. The progressive rendering does wonders for improving perceived responsiveness, but it can be disorienting to have so many items around you disappear as you move.
Is there any way to turn progressive rendering off but only for objects closest to the camera? Maybe a number of objects up to a maximum number, or objects within a radius from the camera. Everything further away can load in later and flicker during motion, but it would be nice to keep the nearby objects rendered, especially structural objects like stairs. I've often walked towards stairs just to have them disappear in front of me, forcing me to fly to a platform with E and Q instead of walking.
So far I've only found a way to toggle progressive rendering for the entire model on or off with viewer.setProgressiveRendering(bool) but I haven't found a way to customize the rendering behavior.
Per our Engineering's recommendation can you try set rendering targets with
viewer.impl.setFPSTargets(1, 5, 15) //min, target, max
In fact we've been having similar reports from other developers requesting similar capability to fine tune rendering with large models so our Engineering is considering their options to extend on existing functions and even build them into extensions.
I am making an application in vb.net that involves listing a large number of files in a listview. However, after 30-40 000 items this gets rather slow and resource demanding. I need a better way to present a large number of items to users. I have though of using pages much like google search results showing 1000 items per page... I have also though of switching between sets of items every time the user hits min and max scrolling position.
What would be the best slution to handeling and presenting large numbers of items in listview? thanks.
Showing large amount of items in a listview is always not a good solution as it cause performance and memory issues. Also the user could not see all the items in a single scroll. So always choose to show items with less amount of data. But some requirements may force to show large number of items. VirtualizationPanel and VirtualizationStackPanel is a solution to improve the UI responsiveness and performance by recycling and loading items based on the scrolling like Windows Explorer.
Please see the below links will helps you to solve your problems
http://msdn.microsoft.com/en-us/library/system.windows.controls.virtualizingstackpanel.aspx
http://msdn.microsoft.com/en-IN/library/system.windows.controls.virtualizingpanel(v=vs.90).aspx
I have recently been developing an isometric, rendering system to map out 3D grids in Javascript. All of the items on the grid are cubes of equal dimensions, the only differences between each one is a texture to represent a value for that coordinate. My application requires large grids to be graphed, even though only a small portion is visible in the viewport at once.
Because I am using Canvas, which is slow to draw thousands of shapes per frame, I set my script to loop through each block but only draw its faces if they are 1.) next to an empty grid space and 2.) inside the viewport. This system works fine for smaller grids, but as my application will need considerably large ones (1000+x1000+x128), I will need to add some performance improvements for the final product.
Does anyone that has worked with rendering systems know any way I can further optimize my engine? One thing that I guess may be effective will be trying to not loop through each grid value, even if it is not being drawn. However, I do not know the most efficient way to know whether to loop through a grid value or not (I am currently going through EVERY value, then calculating whether it should be drawn).
If I have been too vague, please tell me and I will be happy to elaborate. Thank you for your time and expertise; I am a student and any help will greatly aid my learning.
Some pointers to you: you might want to have a look at classic culling algorithms using things like octree (or quadtrees in your case), ...
Summary
New to iPhone programming, I'm having trouble picking the right optimization strategy to filter a set of view components in a scrollview with huge content. In what area would my app gain the most performance?
Introduction
My current iPad app-in-progress let's users explore fairly large binary tree structures. The trees contain between 30 to 900 nodes, and when drawing inside a scrollview (with limited zoom) it looks like this.
The nodes' contents are stored in a SQLite backed Core Data model. It's a binary tree and if a node has children, there are always exactly two. The x and y positions are part of the model, as are the dimensions of the node connections, shown as dotted lines.
Optimization
Only about 50 nodes fit the screen at any given time. With the largest trees containing up to 900 nodes, it's not possible to put everything in a scrollview controlled and zooming UIView, that's a recipe for crashes. So I have to do per frame filtering of the nodes.
And that's where my troubles start. I don't have the experience to make a well founded decision between the possible filtering options, and in addition I probably don't know about that really fast special magic buried deep in Objective-C or Cocoa Touch. Because the backing store is close to 200 MB in size (some 90.000 nodes in hundreds of trees), it's very time consuming to test every single tree on the iPad device. Which is why I'd like to ask you guys for advice.
For all my attempts I'm putting a filter method in the scrollViewDidScroll: and scrollViewDidZoom:. I'm also blocking the main thread with the filter, because I can't show the content without the nodes anyway. But maybe someone has an idea in that area?
Because all the positioning is present in the Core Data model, I might use NSFetchRequest to do the filtering. Is that really fast though? I have the idea it's not a very optimized method.
From what I've tried, the faulted managed objects seem to fit in memory at once, but it might be tricky for the larger trees once their contents start firing faults. Is it a good idea to loop over the NSSet of nodes and see what items should be on screen?
Are there other tricks to gain performance? Would you see ways where I could use multi threading to get the display set faster, even though the model's context was created on the main thread?
Thanks for your advice,
EP.
Ironically your binary tree could be divided using Binary Space Partitioning done in 2D so rendering will be very fast performant and a number of check close to minimum necessary.
My compact framework application creates a smooth-scrolling list by rendering all the items to a large bitmap surface, then copying that bitmap to an offset position on the screen so that only the appropriate items show. Older versions only rendered the items that should appear on screen at the time, but this approach was too slow for a smooth scrolling interface.
It occasionally generates an OutOfMemoryException when initially creating the large bitmap. If the user performs a soft-reset of the device and runs the application again, it is able to perform the creation without issue.
It doesn't look like this bitmap is being generated in program memory, since the application uses approximately the same amount of program memory as it did before the new smooth-scrolling methods.
Is there some way I can prevent this exception? Is there any way I can free up the memory I need (wherever it is) before the exception is thrown?
I'd suggest going back to the old mechanism of rendering only part of the data, as the size of the fully-rendered data is obviously an issue. To help prevent rendering problems I would probably pre-render a few rows above and below the current view so they can be "scrolled" in with limited impact.
And just as soon as I posted I thought of something you can do to fix your problem with the new version. The problem you have is one of CF trying to find one block of contiguous memory available for the huge bitmap, and this is occasionally a problem.
Instead of creating one big bitmap, you can instead create a collection of smaller bitmaps, one for each item, and render each item onto its own little bitmap. During display, you then just copy over the bitmaps you need. CF will have a much easier time creating a bunch of little bitmaps than one big one, and you shouldn't have any memory problems unless this is a truly enormous bunch of items.
I should avoid expressions like "there is no fix".
One other important point: make sure you call Dispose() on each bitmap when you're finished with it.
Your bitmap definitely is being created in program memory. How much memory the bitmap needs depends on how big it is, and whether or not this required size will generate the OutOfMemoryException depends on how much is available to the PDA (which makes this a randomly-occuring error).
Sorry, but this is generally an inadvisable control rendering technique (especially on the Compact Framework) for which there is no fix short of increasing the physical memory on the PDA, which isn't usually possible (and often won't fix the problem anyway, since a CF process is limited to 32MB no matter how much the device has available).
Your best bet is to go back to the old version and improve its rendering speed. There is also a simple technique available on CF for making a control double-buffered to eliminate flicker.
Since it appears you've run into a device limitation that is restricting the total size of Bitmap space you can create (these are apparently created in video RAM rather than general program memory), one alternative is to replace the big Bitmap object used here with a plain-old block of Windows memory, accessing it for reading and writing by PInvoking the BitBlt API function.
Initially creating the memory block is tricky, and you'd probably want to ask another SO question about that (GCHandle.Alloc can be used here to create a "pinned" object, which means .NET isn't allowed to move it around in memory, which is critical here). I know how to do it, but I'm not sure I do it correctly and I'd rather have an expert's input.
Once you've created the big block, you'd iterate through your items, render each to one small bitmap that you keep re-using (using your existing .NET code), and BitBlt it to the appropriate spot in your memory block.
After creating the entire cache, your rendering code should work just like before, with the difference that instead of copying from the big bitmap to your rendering surface, you BitBlt from your cache block. The arguments for BitBlt are essentially the same as for DrawImage (destination, source, coordinates and sizes etc.).
Since you're creating the cache out of regular memory this way instead of specialized video RAM, I don't think you'll run into the same problem. However, I would definitely get the block creation code working first and test to make sure it can create a big enough block every time.
Update: actually, the ideal approach would be to have a collection of smaller memory blocks rather than one big one (like I thought was the problem with the Bitmap approach), but you already have enough to do. I've worked with CF apps that deal with 5 and 10MB objects and it's not a huge problem anyway (although it might be a bigger problem when that chunk is pinned - I dunno). BTW, I've always been surprised by the OOMEs on BitMap creation because I knew the bitmaps were much smaller than the available memory, as did you - now I know why. Sorry I thought this was an easy solve at first.