Почему мой текст QML CJK отображается с поврежденными глифами?

Мое приложение позволяет пользователю переключать языки на лету. Я вижу, что примерно в 10% случаев, когда пользователь переключается на китайский или японский языки, глифы для текста пользовательского интерфейса отображаются неправильно.

Это приложение работает под Linux на платформе iMX6. Используется Qt 5.5.0. QML используется для визуализации пользовательского интерфейса. Поврежденный текст визуализируется с помощью элемента управления QML Text.

Пример отображения поврежденного шрифта

Речь идет о шрифте Source Hans Sans Regular. Я попытался загрузить это с помощью QML FontLoader и загрузив его на стороне С++ в базу данных шрифтов приложения (оба метода выявили проблему). Я пытался использовать (по общему признанию, очень сильно связанные) шрифты Noto; та же проблема.

Я никогда не видел искажения рендеринга текста при использовании Roboto для текста, отличного от CJK, и, как уже упоминалось, это чаще всего работает для CJK/Source Hans Sans.

Повреждение интересно, потому что оно выглядит так, как будто оно находится на уровне визуализированного растрового изображения, а не на уровне определения глифа (обратите внимание, как у некоторых глифов правильная нижняя половина, но верхняя половина повреждена).

Коррупция иногда прогрессирует. Это наводит меня на мысль, что кэш-память растрового изображения глифа перезаписывается дальше (просто теория, поскольку я не уверен, как Qt выполняет рендеринг шрифтов). Я думал, что сборщик мусора QML делает что-то странное, но загрузка шрифта на стороне C++ не имела значения.

Далее я собираюсь попробовать использовать «собственный рендеринг» для элементов управления QML Text.

Кто-нибудь видел это раньше? Кто-нибудь может подтвердить, что FreeType используется для управления/рендеринга шрифтов в Qt 5.5.0? Существуют ли способы повлиять на управление кэшем растровых изображений шрифтов?

Спасибо!

Обновление: использование 'renderType: Text.NativeRendering' не устранило проблему (хотя повреждение проявлялось несколько иначе). И, учитывая ограничения этого режима, просто в итоге получился плохо отрисованный текст (мягкий, плохое масштабирование и т. д. - как задокументировано).

Обновление 2: я собрал Qt с отключенными (насколько мне известно) всеми кешами глифов -- shouldDrawCachedGlyphs() возвращает false в моей локальной сборке для четырех экземпляров этого вызова, которые мне удалось найти -- но по-прежнему сталкивался с повреждением глифов.

Обновление 3. Попытка переключения на использование программного (не OpenGL) средства визуализации Qt Quick 2 путем установки QMLSCENE_DEVICE=softwarecontext по документам; повреждение глифов все еще имело место.


person Matthew Reynolds    schedule 20.10.2015    source источник


Ответы (1)


В данном конкретном случае в драйвере OpenGL на платформе, с которой я работаю, есть ошибка. Это влияет на считывание FBO. Установка QML_USE_GLYPHCACHE_WORKAROUND=1 в среде заставляет Qt сохранять дополнительную копию кэша глифов в ОЗУ (поскольку он не может быть считан с графического оборудования при добавлении новых глифов).

Следствием этого является то, что хотя рендеринг будет правильным (поскольку мы используем второй кэш, который не поврежден), производительность будет немного снижена, поскольку на ЦП есть дополнительная копия, а кеш глифов будет использовать вдвое больше памяти. . Качество рендеринга не пострадало.

Служба поддержки Qt смогла указать мне правильное направление и уточнить последствия, связанные с QML_USE_GLYPHCACHE_WORKAROUND.

person Matthew Reynolds    schedule 20.01.2016
comment
производительность будет немного снижена. Я чувствую, что это похоже на улучшение производительности, при рендеринге разного текста каждые 50 миллисекунд он иногда останавливался без GLYPCHACHE_WORKAROUND, с ним рендеринг текста, кажется, выполняется более последовательно. - person SketchBookGames; 05.05.2016
comment
Качество рендеринга остается неизменным, в результате метрики рендеринга также немного меняются. в одном примере мой Text contentWidth был 500 и теперь равен 502, а contentHeight был 40 и теперь равен 46 - person SketchBookGames; 05.05.2016