Сотни пользовательских UserControls создают тысячи объектов USER.

Question

Я создаю приложение для панели мониторинга, которое отображает сотни «элементов» на FlowLayoutPanel.

Каждый «элемент» представляет собой UserControl, который состоит из 12 текстовых полей или меток.

Мое приложение запрашивает базу данных, а затем создает экземпляр "item" для каждой записи, заполняя метки и текстовые поля данными, прежде чем добавить их в FlowLayoutPanel.

После добавления около 560 элементов на панель я заметил, что число USER Objects в моем диспетчере задач возросло до 7300, что намного больше, чем у любого другого приложения на моей машине.

Я полагал, что 560 * 13 (12 ярлыков плюс сам UserControl) - это 7280. Так что внезапно выяснилось, откуда все объекты ...

Зная, что до того, как окна выбрасывают полотенце, существует ограничение в 10000 ПОЛЬЗОВАТЕЛЕЙ, я пытаюсь найти более эффективные способы нанесения этих "предметов" на FlowLayoutPanel.

Мои идеи на данный момент таковы:

1. Нарисуйте «элемент», используя graphics.DrawText и DrawImage вместо многих меток. Я надеюсь, что это будет означать 1 элемент = 1 USER Object, а не 13.

2. Имейте 1 экземпляр «элемента», затем для каждой записи заполняйте экземпляр и используйте метод Control.DrawToBitmap(), чтобы получить изображение, а затем используйте его в FlowLayoutPanel (или аналогичном)

Итак ... У кого-нибудь есть другие предложения ???

P.S. Это масштабируемый интерфейс, поэтому я уже исключил «пейджинг», так как есть требование видеть все элементы одновременно

Answer 1

Как минимум, я бы начал с вашей идеи # 1.Это действительно уменьшит количество окон, которые ваше приложение сожирает в 13 раз.

Что касается вашей идеи №2, это не очень поможет вам, если вы поместите растровое изображение в PictureBox (или что-то еще) и, таким образом, иметь большое количество элементов управления PictureBox в вашей форме (это может быть даже хуже , поскольку растровые изображения иногда состоят из более ограниченного ресурса, чем общая ОЗУ, что представляет собой проблему, совершенно отличную от потребленияслишком много окон).Это было бы хорошей идеей, если бы вы взяли получившиеся растровые изображения и скопировали их в один больший элемент управления (а затем удалили растровые изображения).

Если вы воспользуетесь этим последним подходом, то в действительности нет необходимости использоватьпромежуточный этап рендеринга в элемент управления, получение растровой копии элемента управления и затем рисование этого растрового изображения в конечном элементе управления.Было бы более разумно взять код / ​​логику, которые вы используете для визуализации элемента управления, и вместо этого визуализировать непосредственно в конечный (многоэлементный) элемент управления.

Answer 2

Я реализовал # 1 с хорошими результатами.

В 13 раз меньше пользовательских объектов, и он также чувствует себя быстрее и более отзывчивым.

Спасибо за предложения - я удивлен, что этоне более распространенная проблема!

Answer 3

Я бы порекомендовал вашу идею №2. Именно так элементы управления списками и сетками, предназначенные для отображения тысяч записей, могут выполнять редактирование на месте . Вы начинаете с одного элемента управления и перемещаете его туда, куда вам нужно.

Если вам нужно отобразить несколько экземпляров одновременно, то это немного сложнее - как вы упоминаете, вам, скорее всего, придется использовать DrawToBitmap и отображать «призрачное изображение» элемента управления.

В качестве альтернативы, я предполагаю, что здесь происходит некоторая прокрутка (на самом деле никто не может одновременно взглянуть на 7280 объектов пользовательского интерфейса, верно?), Так что другая вещь, которую вы могли бы сделать, это динамически создавать только экземпляры, которые на самом деле будут включены. экран в то же время. Вам нужно будет вычислить видимую область и сравнить ее со списком элементов управления, которые будут отображаться, и просто отобразить заполнители, если пользовательский интерфейс слишком сильно уменьшен, чтобы на самом деле разобрать какие-либо детали. Я полагаю, что если вы это сделаете, прокрутка / масштабирование станет довольно трудоемкой операцией; лучше просто не создавать их вообще.