Board.KolibriOS.org

Предлагаю добавить в 65-ю функцию ещё один тип изображений: grayscale (оттенки серого).

Во всех нормальных форматах изображений и графических редакторах grayscale и indexed -- две разные сущности. К ним по-разному применяются фильтры, они по-разному интерполируются и т.д.

Сейчас при декодировании grayscale изображения подставляется костылик в виде искусственной палитры, которая заполняется оттенками серого. При этом тратится килобайт памяти на палитру и лишнее процессорное время на её заполнение программой/библиотекой и затем обращение к ней ядром при выводе изображения.

Ещё интереснее ситуация возникает при кодировании/сохранении изображений. Для того, чтобы определить тип картинки (grayscale/indexed), нужно пробежать всю палитру и проверить, а не совпадает ли она случайно с палитрой в оттенках серого? В этом месте можно подставить второй костыль в виде разделения типов grayscale/indexed на уровне приложения (каждого), но зачем?

Что предлагаю: добавить к списку допустимых значений esi (1,2,4,8,15,16,24 или 32 сейчас) ещё один -- 9. Он, конечно, не имеет "физического смысла" девяти битов на пиксель; это следует понимать как "почти восемь, только без палитры". При таком обозначении не нарушается логика функции: палитра присутствует у всех типов <= 8. Кроме того, 65-я функция поддерживает всякие экзотические 2, 15 и 16 бит на пиксель, почему там не должно найтись места для grayscale?

Естественно, я написал эти несколько строчек кода:

Spoiler:

Code: Select all

Index: kernel.asm
===================================================================
--- kernel.asm	(revision 2725)
+++ kernel.asm	(working copy)
@@ -4111,6 +4111,14 @@
 ;--------------------------------------
 align 4
 @@:
+        cmp     esi, 9
+        jnz     @f
+        mov     ebp, putimage_get9bpp
+        mov     esi, putimage_init9bpp
+        jmp     sys_putimage_bpp
+;--------------------------------------
+align 4
+@@:
         cmp     esi, 15
         jnz     @f
         mov     ebp, putimage_get15bpp
@@ -4171,6 +4179,7 @@
 putimage_init24bpp:
         lea     eax, [eax*3]
 putimage_init8bpp:
+putimage_init9bpp:
         ret
 ;-----------------------------------------------------------------------------
 align 16
@@ -4191,6 +4200,14 @@
         inc     esi
         ret     4
 ;-----------------------------------------------------------------------------
+align 16
+putimage_get9bpp:
+        lodsb
+        mov     ah, al
+        shl     eax, 8
+        mov     al, ah
+        ret     4
+;-----------------------------------------------------------------------------
 align 4
 putimage_init1bpp:
         add     eax, ecx

В ядро я ещё ничего не коммитил, поэтому прошу знающих людей посмотреть, всё ли в порядке. Модифицированное ядро тестировал в qemu в 24-х и 32-х битных режимах.

Если будут возражения или я вдруг что-то упустил, обсудим.

Ах, да. Может, кто-то знает, как в функции putimage_get9bpp под спойлером можно лучше сделать броадкаст byte[esi] в байты eax? Можно только в три младших.

Если не теряется обратная совместимость, то я не против. В свое время разрешения менее 8 бит были сделаны diamond'ом по моей просьбе, но потом выяснилось что проще сконвертировать такие изображения в 8 бит и уже работать с ним. По идее их можно даже и убрать - они избыточны и насколько я знаю никто их не использует.

имхо идея хорошая,
в парсере 65-й уже столько узлов навязано, что еще один режим погоды не сделает.

Код красивый, только там же основной код заливки в vesa20.inc - ты всё ядро с новой фичей собирал, накладок нет?

Еще нужен вывод 10-битных изображений (вроде шкалы высот и глубин на географических картах) - от синего через зеленый и желтый к красно-коричневому.

Mario wrote:Если не теряется обратная совместимость, то я не против.

Не теряется, это ведь как новый маршрут автобуса без отмены старых.

Mario wrote:По идее их можно даже и убрать - они избыточны и насколько я знаю никто их не использует.

Может, и так. Я сейчас не буду трогать, пока работает.

art_zh wrote:там же основной код заливки в vesa20.inc

В vesa20.inc правок не вносил. Как я понял, там функции, определённые в kernel.asm по указателям из esi и ebp вызываются.

art_zh wrote:ты всё ядро с новой фичей собирал, накладок нет?

А разве можно не всё ядро собрать? Я делал make из /data/eng. А для приложений изменилось лишь то, что теперь появился ещё один допустимый параметр. Кто не в курсе, работает как раньше. Или я неправильно понял?

art_zh wrote:Еще нужен вывод 10-битных изображений (вроде шкалы высот и глубин на географических картах) - от синего через зеленый и желтый к красно-коричневому.

Мне кажется, это вряд ли в ядро, довольно специфическая штука. Тот же grayscale с альфа каналом намного чаще встречается. Уже для двух форматов делал костыль с перепаковыванием в обычный grayscale.

Эх, 32 бита с альфа-каналом *вздыхает*.

Тормоза, же!

Мы это кажется уже обсуждали. Тормоза-тормозами, а человеческий вывод масштабируемых шрифтов без этого не сделать.

Думается мне нужно делать другую функцию - 65 уже предельно перегружена. Есть вероятность что внедрение кода работы с альфа-каналом может затормозить всю функцию. А может и нет - все зависит от реализации.

Закоммитил, r2727.

В аргументах этой функции нет зарезервированных полей. Если 32-битные изображения вдруг начнут выводиться с прозрачностью, это нарушит обратную совместимость.

dunkaist
Мне вот любопытно - А доки кто будет править?

Спасибо за напоминание, сейчас поправлю.