Не сказал бы что так уж плохо все. В моей практике очень часто встречалась задача удалить некоторый набор данных из вектора а потом вставить в конец что-то новое. Если бы std::remove() сразу выполнял операцию erase то на один realloc могло быть больше в этом случае…
Если в вашем кастомном шрифте много глифов возможно проблема в поиске нужного глифа при подготовке текста к рендерингу.
Проверить что именно в этом проблема — замерять сколько времени работает CTLineCreateWithAttributedString с соответствующей строкой.
Если в глиф плохо оптимизирован (дизайнер натыкал 100500 точек) — то тоже может быть проблема в расчетах границ глифа (примерно чекнуть можно юзая CTLineGetImageBounds) + сама прорисовка может быть не быстрая (CTFontDrawGlyphs)…
Есть такая замечательная библиотека под именем Common Graphics Algorithms (CGAL). А в библиотеке есть функция bounded_side_2
Если полистать исходники — то можно понять как обрабатывать все граничные ситуации первого алгоритма.
В принципе да. Производительность критична. Пишу прилаги для мобильных устройсв под управлением iOS. В принципе С++ тоже юзаю но гораздо реже. Всетаки Obj-C + С гораздо удобнее юзать чем Obj-C + C++.
Есть же стандартный макрос для сего дела: offsetof (http://www.cplusplus.com/reference/clibrary/cstddef/offsetof/).
Делает тоже самое кстати. Но не хочется плодить лишние сущьности )
Хм либо запрограмился либо не понимаю как «лучше чтобы сие предоставляла ОС» конфликтует с «реализовано на разных платформах».
Смысл того что я сказал — желательно чтобы реализация thread-safe очередей и прочего подобного было на уровне ОС, которая точно знает как это сделать наиболее эффективным способом…
В староглиненные времена написал набросал побыстрому скрипт для фотошопа который аталасы генерировал)
Правда как правило получается удобнее генерировать атлас в рантайме. Особенно когда нужно рисовать буковки.
Получается что-то типа вот такого:
Весь профит в том что фонт может быть кастомный. И в атлас можно добавлять только используемые буквы.
Работает сие дело относительно быстро. Для расположения картинок — используется простейший BSP алгоритм (вроде так зовется).
Вообщето если в IB написать «имя@2x.png» то будет грузится именно эта картинка.
Таким образом для iPhone и iPhone Retina — интерфейс можно нарисовать в одном xib, а для iPad — в файлике с постфиксом ~ipad.
Неверно.
Локализуется также как и любой другой ресурс в iOS (достаточно разложить файлики по [locale id].lproj папочкам).
И обязательно удалить из билда исходный Default.png и с девайса снести приложение и поставить заново. Ибо оно там остается в корне висеть…
У меня подобные проблемы были когда я напортачил в методе viewDidUnload. Не релизил созданную кодом вьюшку (только в dealloc релизил). В итоге когда приходил memory warning — начинались чудеса )
Правильно заданный вопрос — не нуждается в ответе )
Очень часто когда возникает дурацкая ситуация — при попытке сформулировать вопрос коллеге ответ сразу находится…
Те что слеплены по идеологии iOS — это скорее всего порты.
Если уже есть нарисованный дизайн — врятли кто-то согласится сильно его переделывать (особенно если только выходиш на рынок андроида)
Проверить что именно в этом проблема — замерять сколько времени работает CTLineCreateWithAttributedString с соответствующей строкой.
Если в глиф плохо оптимизирован (дизайнер натыкал 100500 точек) — то тоже может быть проблема в расчетах границ глифа (примерно чекнуть можно юзая CTLineGetImageBounds) + сама прорисовка может быть не быстрая (CTFontDrawGlyphs)…
Если полистать исходники — то можно понять как обрабатывать все граничные ситуации первого алгоритма.
Делает тоже самое кстати. Но не хочется плодить лишние сущьности )
Смысл того что я сказал — желательно чтобы реализация thread-safe очередей и прочего подобного было на уровне ОС, которая точно знает как это сделать наиболее эффективным способом…
Но всетаки лучше чтобы сие предоставляла ОС (например ru.wikipedia.org/wiki/Grand_Central_Dispatch)
Правда как правило получается удобнее генерировать атлас в рантайме. Особенно когда нужно рисовать буковки.
Получается что-то типа вот такого:
GLAtlasGenerator *gen = [[GLAtlasGenerator alloc] init];
[gen addImageNamed:@"name.png" withKey:@"name"];
[gen addImageNamed:@"name2.jpeg" withAlphaImageNamed:@"name2_alpha.jpeg" withKey:@"name2"];
[gen addCharsFromString:numbers fontPrefix:@"numbers" font:fontNumbers];
...
fontsTexture = [gen buildTextureWithFormat:GL_RGBA];
[gen release];
Весь профит в том что фонт может быть кастомный. И в атлас можно добавлять только используемые буквы.
Работает сие дело относительно быстро. Для расположения картинок — используется простейший BSP алгоритм (вроде так зовется).
Таким образом для iPhone и iPhone Retina — интерфейс можно нарисовать в одном xib, а для iPad — в файлике с постфиксом ~ipad.
Локализуется также как и любой другой ресурс в iOS (достаточно разложить файлики по [locale id].lproj папочкам).
И обязательно удалить из билда исходный Default.png и с девайса снести приложение и поставить заново. Ибо оно там остается в корне висеть…
Точно не помню, но что-то про кеширование данных мозгом и прочий подобный бред )
Точно не помню, но что-то про кеширование данных мозгом и прочий подобный бред )
Очень часто когда возникает дурацкая ситуация — при попытке сформулировать вопрос коллеге ответ сразу находится…
Если уже есть нарисованный дизайн — врятли кто-то согласится сильно его переделывать (особенно если только выходиш на рынок андроида)