Просмотр полной версии : Большое количество текстовых полей - оптимизация
Добрый вечер! Всех с праздником!
Посоветуйте пожалуйста. Вот у меня во флешке создаётся несколько сотен объектов Sprite, в каждом из которых до двадцати текстовых полей. В данный момент используется TextField, и это очень сильно сжирает производительность. Я поставил каждому такому спрайту кеширование cacheAsBitmap, и в целом, когда я перемещаю общий спрайт с сотнями таких объектов, производительность стабильна, на уровне примерно 55-60 fps. Но при изменении масштаба - во время увеличения, производительность падает до 10 fps. Я понимаю, что тут заново кешируются подложки под спрайты. Но проблема в том, что без кеширования я получаю при перемещении холста 25 fps, а при зуме те же 10.
Я выяснил, что проблема именно с текстовыми полями. Кеширование с ними не даёт никакого результата. Преобразование в Bitmap даёт говёное качество. И ещё заметил, что при изменении масштаба, ширина текстовых полей сильно меняется, и бывает так, что текст выходит за границы нарисованных рамок спрайта при большом отдалении. Вот сижу тут и не знаю уже, что делать, и чем заменить текстовые поля. Поделитесь опытом, плиз.
ZackMercury
09.05.2015, 22:16
Преобразование в Bitmap даёт говёное качество
А программное преобразование + smoothing=true?
Подробнее, что именно вы делаете?
caseyryan
09.05.2015, 22:47
Информация в текстовых полях должна меняться? Или остается та же, которая добавлена изначально?
Если не должна, то самый лучший способ - это врисовать их в подложку через bitmapData#draw(), после чего просто удалить.
Но это если подложка представляет из себя растровую картинку
Я делаю просмотрщик схем для визуального языка программирования.
Текст всегда статичен, в том-то и проблема. А текстовые поля весьма тяжёлые. Если через BitmapData.Draw, получается хрень с низким качеством.
Zebestov
10.05.2015, 10:01
1. включил схему (текст, картинки, вектор, вот это всё), сделал BitmapData#draw() видимой части схемы, выключил схему
2. масштабируешь этот битмап, в процессе — пофиг на качество или пустые поля вокруг
3. после завершения масштабирования — п.1
Таким образом ты всегда имеешь на экране качественное легкое изображение схемы, которое лишь во время масштабирования слегка ухудшается (при увеличении) или обрезается (при уменьшении вокруг появляются пустые поля, которые тут же заполнятся, когда масштабирование завершится).
P.S.
И да, если таки сильно не нравятся поля при масштабе/перетаскивании, можно растрировать "с запасом". Размер запаса — дело вкуса, ограниченное расходом памятью.
Меня ещё пугает скорость этого прорисовывания в Bitmap. Подвисает почище, чем просто при отрисовке векторов и масштабировании.
Zebestov
11.05.2015, 00:10
Для начала попробуй сделать отрисовку только видимой части. Уже должно быть побыстрее.
Я так понимаю, что нужно использовать систему событий для оповещения каждого такого блока в схеме, что он был перемещён.
Попробую конечно, но ИМХО каждое растрирование сотни таких объектов будет лагать сильнее. Я заметил, что текст при масштабировании перестраивается, и именно это и жрёт всю память - происходит здоровенный лаг в момент применения зума. Эх, вот если бы как-то графикой отрисовать тексты, что-то вроде LineTo и так далее.
Добавлено через 3 часа 18 минут
1. включил схему (текст, картинки, вектор, вот это всё), сделал BitmapData#draw() видимой части схемы, выключил схему
2. масштабируешь этот битмап, в процессе — пофиг на качество или пустые поля вокруг
3. после завершения масштабирования — п.1
Таким образом ты всегда имеешь на экране качественное легкое изображение схемы, которое лишь во время масштабирования слегка ухудшается (при увеличении) или обрезается (при уменьшении вокруг появляются пустые поля, которые тут же заполнятся, когда масштабирование завершится).
P.S.
И да, если таки сильно не нравятся поля при масштабе/перетаскивании, можно растрировать "с запасом". Размер запаса — дело вкуса, ограниченное расходом памятью.
Кажется стал понимать. Мне в данном, описанном случае, выгоднее всего делать снимок именно спрайта, в который вложены эти сотни других блоков. Скажите, как определить видимые поля?
Zebestov
11.05.2015, 11:53
Ну, масштабировать саму схему не нужно. При растеризации используй матрицу, которая натянет нужный кусочек в нужном масштабе на битмапу размером с экран.
Я уже проще сделал, скриншот всей схемы целиком. Знаете, хорошо получается. При прокрутке мышкой (зум назначен на колесо) я убираю child'ы настоящих векторов из главного спрайта и добавляю туда child скриншота (Bitmap). А через секунду после окончания прокрутки снова добавляются элементы векторов и убирается битмап. Так вот 60 fps!
Но вот в чём загвоздка. У меня схема интерактивна. Можно перетаскивать блоки мышкой, при этом обновляются все связи в цепочках данных. И вот после перетаскивания нужно каждый раз обновлять скриншот всей схемы, чтобы во время прокрутки изображение соответствовало оригиналу. Но скриншот всей области делается с подлагиванием. Вот я и думаю, как бы всё это сделать "непрерывным".
Если вместо скриншота всей области, делать скриншот для каждого перетаскиваемого блока, то, боюсь, выйдет черезчур сложно и систему придётся переделывать.
заметил, что при изменении масштаба, ширина текстовых полей сильно меняется, и бывает так, что текст выходит за границы нарисованных рамок спрайта при большом отдалении.
В общем, если кому интересно - проблема решается оптимизацией кода (ну это разумеется) и обязательным внедрением шрифтов. Внедрение просто-напросто решило все проблемы с дерьмовым внешним видом текстовых полей и с лагами при изменении масштаба. Получается, что с системными шрифтами текстовые поля постоянно перестраиваются под масштаб, но при внедрении они именно ведут себя так как надо - установил ширину один раз, и после этого ничего никуда не выползает, текстовое поле становится фиксированного размера. Ну и сглаживание можно применить. Если не выбирать ADVANCED, то с производительностью будет всё в порядке.
Работает на vBulletin ® версия 3.7.3. Copyright ©2000-2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 1999-2008 Flasher.ru. All rights reserved.