Сотни пользовательских UserControls создают тысячи Пользовательских объектов
Я создаю приложение панели инструментов, которое показывает сотни "объектов" на a FlowLayoutPanel.
Каждый "объект" является a UserControl это составлено из 12 текстовых полей или маркировок.
Мое приложение запрашивает базу данных и затем создает экземпляр "объекта" для каждой записи, заполняя маркировки и текстовые поля с данными прежде, чем добавить его к FlowLayoutPanel.
После добавления приблизительно 560 объектов к панели я заметил что USER Objects количество в моем Диспетчере задач подошло приблизительно к 7 300, который был намного намного больше, чем какое-либо другое приложение на моей машине.
Я полагал, что 560 * 13 (12 маркировок плюс сам UserControl) 7280. Так, чтобы внезапно отдал, куда все объекты прибывали из...
Знание, что существует 10 000 пределов Пользовательского объекта перед окнами, признает себя побежденным, я пытаюсь изобразить лучшие способы потянуть эти "объекты" на FlowLayoutPanel.
Мои идеи до сих пор следующие:
Потяните пользователь "объект", с помощью
graphics.DrawTextиDrawImageвместо многих маркировок. Я надеюсь, что это будет означать 1 объект = 1USER Object, не 13.Имейте 1 экземпляр "объекта", затем для каждой записи, заполните экземпляр и используйте
Control.DrawToBitmap()метод, чтобы захватить изображение и затем использовать это вFlowLayoutPanel(или подобный)
Так... У кого-либо есть какие-либо другие предложения???
P.S. Это - zoomable интерфейс, таким образом, я уже исключил "подкачку страниц", поскольку существует требование для наблюдения всех объектов сразу
3 ответа
Как минимум, я бы начал с вашей идеи №1. Это действительно сократит количество окон, поглощаемых вашим приложением, в 13 раз.
Что касается вашей идеи №2, это вам вообще не поможет, если вы затем поместите Bitmap в PictureBox (или что-то еще). и, следовательно, иметь большое количество элементов управления PictureBox в вашей форме (это может быть даже хуже , поскольку растровые изображения иногда состоят из более ограниченного ресурса, чем обычная оперативная память, что представляет собой совершенно другую проблему, чем использование слишком большого количества окон ). Это было бы хорошей идеей только в том случае, если бы вы взяли полученные растровые изображения и скопировали их в один более крупный элемент управления (а затем удалили растровые изображения).
Если вы воспользуетесь этим последним подходом, тогда действительно нет необходимости использовать промежуточный этап рендеринга в элемент управления, получения копии Bitmap элемента управления и последующего рисования этого Bitmap на конечном элементе управления. Было бы разумнее взять код / логику, которые вы используете для рендеринга элемента управления, и вместо этого выполнить рендеринг непосредственно в окончательный (многоэлементный) элемент управления.
Я бы порекомендовал вашу идею №2. Именно так элементы управления списком и сеткой, предназначенные для отображения тысяч записей, могут выполнять редактирование на месте . Вы начинаете с одного элемента управления и перемещаете его туда, где вам нужно.
Если вам нужно отображать несколько экземпляров одновременно, это немного сложнее - как вы упомянули, вам, скорее всего, придется использовать DrawToBitmap и отображать «фантомное изображение» элемента управления.
В качестве альтернативы, я предполагаю, что здесь происходит некоторая прокрутка (на самом деле никто не может сразу посмотреть на 7280 UI-объектов, не так ли?), Поэтому вы могли бы также динамически создавать только те экземпляры, которые на самом деле будут экран одновременно. Вам нужно будет рассчитать видимую область и сравнить ее со списком отображаемых элементов управления и просто отобразить заполнители, если пользовательский интерфейс слишком сильно увеличен, чтобы на самом деле разглядеть какие-либо детали. Я полагаю, что, если бы вы сделали это, прокрутка / масштабирование стали бы операцией, сильно нагружающей процессор; лучше просто их не создавать.
Я реализовал #1 с хорошими результатами.
В 13 раз меньше пользовательских объектов, и это также чувствуется быстрее и отзывчивее.
Спасибо за предложения - я удивлен, что это не более распространенная проблема!