sergionn
Full Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
deks
трудно быть оракулом не видя кода, но по аналогии с виндой:
1) долгая загрузка:
компилятся все стандартные шейдеры: shadow, glow и тп.,
на вин-osx они уже скомпилированы, на ios идут в виде текста и компилятся на лету,
2) Много памяти: если отталкиваться от исходников в xe3 - то это просто мрак: в память грузятся одни и те же переменные по нескольку раз, те же шейдеры в виде строк передаются из функции в функцию, битмапы-текстуры сидят как в оперативной памяти, так и дублируются в видео память, причем в некоторых местах по многу раз.
Также возможно, это конечно глупо но, в память могут грузиться и шейдеры от dx9-10, как это сделано на windows, см файлы: FMX.Filter.Standard.pas, FMX.Materials.pas, FMX.Filter.Custom.pas, FMX.Filter.Effects.pas - под виндой грузятся в память шейдеры для osx и ios - видимо просто было лень сделать отдельные файлы?
Также постоянно в fmx нарушается золотое правило - повторяющиеся блоки оформлять в виде функций - имеет место быть многократные повторения кода.
3) Медленная работа: все анимации, биндинги и т.п. устанавливаются через rtti по имени property, т.е. обезьяна не хранит ссылку на конкретное свойство, а ищет их каждый раз его по ИМЕНИ! Мало того что установка через rtti медленна сама по себе, так тут еще и постоянный поиск имен!
Функции вызываются по нескольку раз вложенно, даже там где можно сократить. Идут постоянные копирования в переменные, которые тут же, ниже по коду переписываются другими данными - т.е. оптимизацией как таковой не пахнет вообще!
Еще есть работа со стилями, я так понял автор ее делал на подобии того как это реализовано во флеше, но реализовал он ее через жопу - я даже не стал в них разбираться - мне хреново стало, там тоже идет постоянный поиск по строкам и другие ужасы........
Классы до отказа забиты полями на все случаи жизни, к примеру TControl, который несет в себе контекст для отображения, используется как основа для всех элементов на экране, даже тех которые вообще не требует возможностей этого класса! Каретка перед тем как прорисоваться на экране ищется по ИМЕНИ в списке анимаций среди стилей - этакая пирамида. Отрисовка дочерних элементов - это просто жуть, складывается такое ощущение, что автор потерял целостное видение иерархии отображения, и везде где что то не отрисовывалось - понавставлял кодовых костылей, в итоге получилось что некоторые элементы отрисовываются по нескольку раз, и даже тогда года их вообще не задевают!
Это так все на вскидку - если разбирать все подробно то просто мрак.
Но если если потратить месяц-другой на оптимизацию, то из обезьяны получился бы толковый фреймворк, но я так понял, что не срослось у них что-то и они погнали в другом направлении - за цифрами.......... |
Всего записей: 472 | Зарегистр. 02-11-2011 | Отправлено: 17:59 25-03-2013 | Исправлено: sergionn, 18:28 25-03-2013 |
|
).