Board.KolibriOS.org

Official KolibriOS board
It is currently Sat May 25, 2019 12:50 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 11 posts ] 
Author Message
PostPosted: Sun Jun 03, 2012 11:58 am 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 416
Предлагаю добавить в 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: Show
Code:
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? Можно только в три младших.


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


Top
   
PostPosted: Sun Jun 03, 2012 1:10 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1328
имхо идея хорошая,
в парсере 65-й уже столько узлов навязано, что еще один режим погоды не сделает.

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

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


Top
   
PostPosted: Sun Jun 03, 2012 2:15 pm 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 416
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.


Top
   
PostPosted: Sun Jun 03, 2012 3:03 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Эх, 32 бита с альфа-каналом *вздыхает*.


Top
   
PostPosted: Sun Jun 03, 2012 3:05 pm 
Тормоза, же!


Top
   
PostPosted: Sun Jun 03, 2012 3:57 pm 
Offline

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


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


Top
   
PostPosted: Sun Jun 03, 2012 5:03 pm 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 416
Закоммитил, r2727.

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


Top
   
PostPosted: Sun Jun 03, 2012 5:07 pm 
dunkaist
Мне вот любопытно - А доки кто будет править?


Top
   
PostPosted: Sun Jun 03, 2012 5:10 pm 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 416
Спасибо за напоминание, сейчас поправлю.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 11 posts ] 

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited