Для формирования изображения окна запускающего приложения SkyLA использует внутренний софтварный рендер, в том числе и шрифтов. Далее уже сформированное во внутреннем буфере изображение передаётся операционной системе для вывода на экран. Такое решение позволяет полностью не зависеть от операционной системы в вопросе подготовки изображения, в том числе от наличия шрифтов и кодировки символов. Однако в работе SkyLA есть один неприятный момент – SkyLA осуществляет рендеринг в классическом RGBA8 формате, а вот операционные системы (Windows и Linux) почему-то хотят изображение в формате BGRX8 (т.е. даже не задом наперёд, а с перестановкой местами нечётных каналов).
Т.к. в Linux других вариантов не было, то сразу была написана функция для перестановки каналов (благо там ничего сложного – прогон массива байтов через PSHUFB с заранее подготовленной маской). А вот в Windows оказалась возможность передавать изображение операционной системе в формате RGBX8 (через указание в поле compression структуры BitmapInfoHeader значения BI_BITFIELDS с последующей задачей битовыми масками расположения каналов R, G, B). Как мне показалось, если ОС принимает изображение в указанном формате, то и заморачиваться не стоит. Сделал и забыл. Но тут что-то понесло меня проверить быстродействие этого вывода и оно меня слегка шокировало. Вывод картинки 1024*576 занимал 26 миллионов тактов. ДВАДЦАТЬ ШЕСТЬ МИЛЛИОНОВ!!! Там всего 2,25МБ данных, куда столько вычислений?! И тут у меня начали закрадываться нехорошие мысли по поводу реализации работы с флагом BI_BITFIELDS, и я проверил скорость вывода BGRX8 изображений (конвертирует моя программа). Результат – 2,6 миллиона тактов, включая конвертацию. В 10 раз меньше. Как говорится, без комментариев.
P.S. После таких приколов, желание полагаться в чём-либо на “стандартную реализацию” убивается начисто.
1 пинг
Oliver
19.08.2014 в 15:11 (UTC 2) Ссылка на этот комментарий
thanks for information!