Search code examples
c#.netwinformsuser-controlsresource-leak

Hundreds of custom UserControls create thousands of USER Objects

I'm creating a dashboard application that shows hundreds of "items" on a FlowLayoutPanel.

Each "item" is a UserControl that is made up of 12 textboxes or labels.

My app queries a database and then creates an "item" instance for each record, populating the labels and textboxes with data before adding it to the FlowLayoutPanel.

After adding about 560 items to the panel, I noticed that the USER Objects count in my Task Manager had gone up to about 7300, which was much much larger than any other app on my machine.

I figured that 560 * 13 (12 labels plus the UserControl itself) is 7280. So that suddenly gave away where all the objects were coming from...

Knowing that there is a 10,000 USER object limit before windows throws in the towel, I'm trying to figure better ways of drawing these "items" onto the FlowLayoutPanel.

My ideas so far are as follows:

  1. User-draw the "item", using graphics.DrawText and DrawImage in place of many of the labels. I'm hoping that this will mean 1 item = 1 USER Object, not 13.

  2. Have 1 instance of the "item", then for each record, populate the instance and use the Control.DrawToBitmap() method to grab an image and then use that in the FlowLayoutPanel (or similar)

So... Does anyone have any other suggestions ???

P.S. It's a zoomable interface, so I have already ruled out "paging" as there is a requirement to see all items at once

Solution

  • At a minimum, I would start with your idea #1. This will indeed reduce the number of windows your application is gobbling up by a factor of 13.

    Regarding your idea #2, that won't really help you at all if you then put the Bitmap into a PictureBox (or whatever) and thus have a large number of PictureBox controls on your form (this could even be worse, since Bitmaps sometimes are composed of a more limited resource than general RAM, which is an entirely different problem from consuming too many windows). This would only be a good idea if you were taking the resulting Bitmaps and copying them onto a single larger control (and then Disposing the Bitmaps).

    If you take this latter approach, then there's really no need to utilize the intermediate step of rendering to a control, getting a Bitmap copy of the control and then drawing that Bitmap onto a final control. It would make more sense to take the code/logic that you use to render the control, and instead render directly to the final (multi-element) control.