Работа с большим количеством ярлыков

(Возможно, нубский вопрос, но...) Я пытаюсь написать пользовательский компонент, который по существу содержит довольно большую таблицу (максимум это должно быть 800 x 35 полей, из которых только до 20 x 10 видны на время). Мне было интересно, может ли кто-нибудь дать мне несколько советов/советов, как это сделать оптимальным образом.

Что я сейчас использую: компонент расширяет UIComponent, у меня есть настраиваемая полоса прокрутки и я использую новый spark.components.Label в качестве текстового контейнера для каждого поля в таблице. Я поместил метки внутрь другого UIComponent, чтобы скрыть края меток за пределами области отображения. Я пытался:

  1. Рисовать только те данные, которые содержатся в области отображения. Когда пользователь перемещает полосу прокрутки, данные перерисовываются, однако, поскольку Labels все еще много, компонент немного тормозит.
  2. Нарисуйте всю таблицу и используйте положение маски/контейнера, чтобы показать только часть таблицы, представленную положением ползунков. Однако рисование занимает много времени и, как я полагаю, может использовать много памяти.
  3. (Current idea) Multithreading. This is completely new for me, so I have set up a background Worker and want it to return an UIComponent with the table drawn, while the user can continue interacting with other parts of the component. So here come my questions:
    • So far I am having trouble transferring UIComponent using MessageChannel. Is such a transfer using MessageChannel possible in the first place or should I use alternative approach?
    • Есть ли альтернативный подход для подобных случаев? Может быть, мне следует использовать разные контейнеры для самого текста/таблицы?
    • Может быть, мне следует использовать фонового рабочего для рисования BMP и использовать его вместо UIComponent. Если это так, может быть, кто-нибудь может порекомендовать мне хороший учебник или руководство, как это сделать?

Спасибо за помощь и дайте мне знать, если вам нужна дополнительная информация.

-Вил


person WilyZ525    schedule 30.07.2015    source источник
comment
На самом деле проблема заключается не в том, что у вас слишком много данных для обработки, а в том, что у вас слишком много данных для отображения, отображение — это не то, с чем работник может вам помочь, поэтому это не избавит вас от проблем. Правильный способ сделать это даже не является частью того, что вы рассматриваете, поэтому переходите к тому, что вы считаете: по крайней мере, используйте событие RENDER, поле в поле зрения должно быть нарисовано, но, что не менее важно: поле не в поле зрения должно быть скрыто!   -  person BotMaster    schedule 30.07.2015
comment
Вы не можете использовать компонент List или Grid? Это именно то, для чего эти компоненты были оптимизированы. Для лучшей производительности вам необходимо виртуализировать макет, рисовать только тот макет, который находится в поле зрения, и использовать объединение/переработку элементов, чтобы избежать высокой стоимости строительства. Это вещи, которые уже встроены в компоненты на основе списков Flex. Использование Worker является распространенной идеей, но на самом деле не работает для оптимизации отображения, поскольку рабочие не могут обрабатывать объекты отображения. Это больше для тяжелых операций с данными, таких как кодирование и декодирование байтовых массивов.   -  person Aaron Beall    schedule 30.07.2015
comment
Не все компоненты Flex на самом деле оптимизированы правильно или вообще, к сожалению. Следует напомнить, что они никогда не создавались с учетом оптимизации для мобильных устройств, поэтому многие из них до сих пор довольно дороги для ЦП.   -  person BotMaster    schedule 30.07.2015
comment
@BotMaster спасибо, я проверю событие. О «правильном» подходе к этому не могли бы вы рассказать подробнее? Может быть, мне следует создать совершенно новый объект, то есть LineData для каждой из строк таблицы? Это поможет? Как вы оба видите, я новичок в AS.   -  person WilyZ525    schedule 30.07.2015
comment
Вы смотрели на FlexBlitMask и/или BlitMask в библиотеке Greensock? Существует также полная сетка на основе растровых изображений, но я не могу сейчас вспомнить ее название. Я использовал его давным-давно, и демо-версия кодеров имеет 1000 строк и столбцов, и, поскольку вы «просто» прокручивали растровое изображение, оно летало.   -  person SushiHangover    schedule 30.07.2015
comment
Правильный способ в основном заключается в том, что когда вы прокручиваете, средства визуализации, выходящие из поля зрения, отправляются обратно в пул и повторно используются (повторно заполняются данными), в то время как средства визуализации, попадающие в поле зрения, берутся из пула. В конце концов, вы (более или менее) никогда не создаете больше средства визуализации, чем вам нужно, чтобы покрыть всю область отображения. Все расчеты выполняются только с помощью математики (размер и положение рендерера) и в значительной степени виртуальны, поскольку нет объектов, которые действительно перемещаются из поля зрения или в поле зрения.   -  person BotMaster    schedule 30.07.2015


Ответы (2)


Основная проблема (на мой взгляд) заключается в том, что текст перерисовывается каждый кадр. Если у вас есть TextField из 10 000 строк и вы замаскировали все, кроме первых нескольких строк, Flash все равно отобразит все 10 000 строк до маскирования.

Как уже упоминалось, решение состоит в том, чтобы самостоятельно обрабатывать рендеринг; копирование частей, которые вы хотите видеть на экране. Пока другие компоненты остаются visible.false или просто не включены в DisplayList, они не будут растеризованы средой.

BlitMask от Greensock делает именно это.

person Atriace    schedule 30.07.2015
comment
Не используйте это, если вы ориентируетесь на мобильные устройства, так как это приведет к слишком большому снижению производительности. Отрисовка BitmapData, вероятно, где-то требуется, но кэширование всего рендерера может не понадобиться, поэтому этот движок Greensock может стоить вам больше, чем он сэкономит. - person BotMaster; 30.07.2015

Что ж, мне потребовалось некоторое время, чтобы переписать код, но в итоге я сделал то, что предложил @BotMaster (или, по крайней мере, моя работа была в этом направлении). А сейчас:

  • Для строк данных я создал отдельный объект, содержащий метки, и он также обрабатывает внутреннюю горизонтальную прокрутку. Таким образом, когда я настраиваю вертикальную полосу прокрутки, я перемещаю весь контейнер вместо того, чтобы перемещать каждый элемент по отдельности.
  • In the beginning of the program I initialize sufficient number of elements (row elements and row/column labels) and store them in separate ArrayCollection-s. Than, upon scrollbar update:
    • Calculate the new visible area.
    • Проверьте, находятся ли элементы в текущем списке отображения в новой области. Если это не так, я перемещаю их из списка отображения в соответствующие им ArrayCollection, содержащие неиспользуемые элементы.
    • Отрегулируйте положение оставшихся элементов в списке отображения.
    • Если в новой видимой области есть место, я беру элементы из соответствующих ArrayCollection, корректирую их текст и позиционирую, а затем возвращаю их в список отображения.

Прокрутка теперь намного плавнее, чем раньше.

person WilyZ525    schedule 08.08.2015