Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Пн май 29, 2017 11:46 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 11 сообщений ] 
Автор Сообщение
СообщениеДобавлено: Вс июн 03, 2012 11:58 am 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Пн окт 19, 2009 10:58 am
Сообщения: 328
Предлагаю добавить в 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?

Естественно, я написал эти несколько строчек кода:
Спойлер: Показать
Код:
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? Можно только в три младших.


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


Вернуться к началу
   
СообщениеДобавлено: Вс июн 03, 2012 1:10 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
имхо идея хорошая,
в парсере 65-й уже столько узлов навязано, что еще один режим погоды не сделает.

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

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


Вернуться к началу
СообщениеДобавлено: Вс июн 03, 2012 2:15 pm 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Пн окт 19, 2009 10:58 am
Сообщения: 328
Mario писал(а):
Если не теряется обратная совместимость, то я не против.
Не теряется, это ведь как новый маршрут автобуса без отмены старых.

Mario писал(а):
По идее их можно даже и убрать - они избыточны и насколько я знаю никто их не использует.
Может, и так. Я сейчас не буду трогать, пока работает.

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

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

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


Вернуться к началу
СообщениеДобавлено: Вс июн 03, 2012 3:03 pm 
Не в сети

Зарегистрирован: Пн сен 24, 2007 11:11 am
Сообщения: 2814
Эх, 32 бита с альфа-каналом *вздыхает*.


Вернуться к началу
СообщениеДобавлено: Вс июн 03, 2012 3:05 pm 
Тормоза, же!


Вернуться к началу
   
СообщениеДобавлено: Вс июн 03, 2012 3:57 pm 
Не в сети

Зарегистрирован: Пн сен 24, 2007 11:11 am
Сообщения: 2814
Мы это кажется уже обсуждали. Тормоза-тормозами, а человеческий вывод масштабируемых шрифтов без этого не сделать.


Вернуться к началу
СообщениеДобавлено: Вс июн 03, 2012 4:03 pm 
Думается мне нужно делать другую функцию - 65 уже предельно перегружена. Есть вероятность что внедрение кода работы с альфа-каналом может затормозить всю функцию. А может и нет - все зависит от реализации.


Вернуться к началу
   
СообщениеДобавлено: Вс июн 03, 2012 5:03 pm 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Пн окт 19, 2009 10:58 am
Сообщения: 328
Закоммитил, r2727.

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


Вернуться к началу
СообщениеДобавлено: Вс июн 03, 2012 5:07 pm 
dunkaist
Мне вот любопытно - А доки кто будет править?


Вернуться к началу
   
СообщениеДобавлено: Вс июн 03, 2012 5:10 pm 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Пн окт 19, 2009 10:58 am
Сообщения: 328
Спасибо за напоминание, сейчас поправлю.


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 11 сообщений ] 

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB