Board.KolibriOS.org

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

All times are UTC+03:00




Post new topic  Reply to topic  [ 23 posts ]  Go to page 1 2 Next
Author Message
PostPosted: Sun Nov 16, 2008 8:08 pm 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 689
На форуме присутствуют как прикладники, так и ядерщики, и думаю было бы полезным обсуждать любые изменения, вносимые в API, что включает в себя изменение, добавление и удаление системных [под]функций. Начнём-с, пожалуй, со свежей ревизии под номером 921, в которой Марат добавил новую функцию.
Так как аккаунт самого Марата, по его просьбе, был удалён, хотелось бы спросить у народа, знает ли кто-нибудь, что являет собой эта замечательная функция и зачем она была добавлена (предполагаю, что кто-то знает). Вопрос не просто с потолка, а из-за подозрения, что эту функциональность можно было бы реализовать в другом - более быстром и менее ресурсоёмком - виде.

_________________
in code we trust


Top
   
PostPosted: Sun Nov 16, 2008 8:32 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Функция копирует в буфер [ebx] часть экрана с конвертацией в формат RGB24. И делает это одним из самых медленных способов.


Top
   
PostPosted: Sun Nov 16, 2008 9:11 pm 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 689
Дело в том, что "что она делает" я знаю. Хотелось бы услышать начальника транспортного цеха с объяснением того "зачем она нужна"...
Моё личное предположение - для реализации прокрутки содержимого элементов управления. Почему я подумал именно в эту сторону? Потому что есть небольшое расхождение в документации (по крайней мере на английском языке, русскую не читал): в названии упоминается "read screen area", в то время как в описании присутствует "relative to the window". Это первый недочёт. Получается, что кое-кто хочет получить часть рисунка окна (кстати, зачем делать координаты относительно окна, если получаемые пикселы размером этого окна не ограничиваются) и потом отрисовать полученный буфер в другом месте экрана (используя функцию #7). Вместо этого, можно было бы реализовать функцию прокрутки прямоугольника или же копирования заданного прямоугольника с одного места экрана на другое (которую, вроде как, даже графические ускорители поддерживают).
Ждём комментариев просвещённых.

_________________
in code we trust


Top
   
PostPosted: Mon Nov 17, 2008 9:19 am 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
Mario79
Во-первых, здравствуйте!
Чтобы отписать все буду выдавать по пунктам:
1.Да, функция работает не самым быстрым образом, но делать 35 функцией аналогичное вообще убийственно. Если же делать через селектор gs, то получается неслабая портянка кода в каждой программе. Зато у функции есть определенный плюс — она всегда будет работать, при любой битовой глубине пиксела.
2.Функция нужна мне лично, чтобы реализовать элемент управления MENU, а возможно со временем и другие функции. Главный принцип — удобство использования, при минимуме кода.
3.Если кто-либо может оформить эту функцию лучше меня, то я никогда не возражал против усовершенствования моего кода в ядре. За все время пока я учавствую в проекте такого не было ни разу!
P/S Я несколько ошибался в описании функции, так как брал описание у седьмой функции. Функция работает с экранными а не оконными координатами.
Ревизия 923 - описание исправлено.
4.Если собрание правящих кругов решит, что: - «А ну нах нам это говно!», то я также не возражаю. Единственное замечание — в этом случае больше моих наработок по Колибри на именно этом SVN вы не увидите.
5.Если со стороны Мишы, это так выражается недовольство лицензией моего скролбара, чтож, видимо рассчитывать на дальнейшее сотрудничество тяжело. Кстати, планы есть немалые, но при таком подходе и придирках мне проще всего забить совсем на Колибри (за остальных ребят из нашей команды я не отвечаю — каждый решает сам за себя и в этом сохраняется преемственность духа разработчиков Колибри какой он был в свое время — разумная анархия) и заниматься исключительно другими разработками.
6.Я помню когда внедрялся внутренний формат 70 функции относительно возвращаемого списка элементов директории — ох и сколько желчи было по поводу «Да я, да мы, да круче, да ктож так обзывает, на саксе обзывать тру!!!», однако формат прижился и успешно используется. Никаких особычх сложностей в его исопльзовании не наблюдается. Отсюда следует, что не такой уж я дурак, также как и остальные 5-6 человек которые участвовали в обсуждении. Кстати, обсуждение было абсолютно открытым — каждый мог высказывать свое мнение и его мнение учитывалось, однако некоторые участники сообщества предпочли «тихо поржать в сторонке». Такой подход не то что не красив, он деструктивен.
7.Ребята поймите — несмотря на то что я не присутствую на форуме, Колибри все еще и моя ОС ,также как она и ваша ОС, также как она родная ОС для любого желающего делать дело разработчика.


Last edited by <Lrz> on Mon Nov 17, 2008 11:08 am, edited 3 times in total.

Top
   
PostPosted: Mon Nov 17, 2008 9:45 am 
Offline
User avatar

Joined: Thu Mar 01, 2007 4:16 pm
Posts: 426
> Вместо этого, можно было бы реализовать функцию прокрутки прямоугольника или же копирования заданного прямоугольника с одного места экрана на другое (которую, вроде как, даже графические ускорители поддерживают).
Поддерживаю. И не вроде как, а точно. И только такая функция (копирования участка видеопамяти) даст прирост производительности с появлением поддержки железного ускорения. Копирование в оперативную память, в таком случае, плохая идея. Хотя меня не травмирует наличие в ядре функции, предложенной Маратом.

..bw


Top
   
PostPosted: Mon Nov 17, 2008 3:48 pm 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 5047
Идея функции - гениальная. Реализацию я отценить, конечно, не смогу, потому поддерживаю. В любом случае ведь её всегда можно изменить в будующем. А пока что пусть будет так.
Ах да, привет, Марат! :)

_________________
Через тернии к звездам


Top
   
PostPosted: Mon Nov 17, 2008 9:56 pm 
Offline
User avatar

Joined: Thu Mar 29, 2007 3:02 am
Posts: 249
... функция должна быть... реализовани она не так уж и плохо, и в случае желания, никто не будет против, ели её препишут ради производительности... (ИМХО, конечно)... а вообще, критиковать чужие разработки - не гуд, никто никого не заставляет использовать эту функцию, и она никому не мешает... ... ;)

_________________
*****:
;дух машины, мой бубен сильнее твоей тупости

*****:


Top
   
PostPosted: Mon Nov 17, 2008 11:16 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Какой смысл конвертировать в 24bpp ? Экономия памяти небольшая, больше неудобства. И ф.65 сильно перегружена.


Top
   
PostPosted: Mon Nov 17, 2008 11:22 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Serge wrote:
Какой смысл конвертировать в 24bpp ? Экономия памяти небольшая, больше неудобства.

В смысле? Кто и откуда конвертирует?
Serge wrote:
И ф.65 сильно перегружена.

И чем же она перегружена? Все её параметры необходимы и используются, например, kfar'ом.


Top
   
PostPosted: Tue Nov 18, 2008 1:54 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
ф.36 сохраняет картинку в формате 24bpp. Для 24 bpp экрана это нормально, особенно если не тянуть всю картинку по одному пикселю. Но для 32 bpp замедляет работу.

diamond

Ещё бы они не использовались, если функция писалась под kfar.
Я не о параметрах, а о реализации. Вся эта связка из ф.65 и vesa20_putimage с вызовом вспомогательных функций на каждый пиксель стала просто монстроподобной.


Top
   
PostPosted: Tue Nov 18, 2008 2:31 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Serge wrote:
ф.36 сохраняет картинку в формате 24bpp. Для 24 bpp экрана это нормально, особенно если не тянуть всю картинку по одному пикселю. Но для 32 bpp замедляет работу.

Безусловно, тянуть всю картинку по одному пикселю тормозно. Но вот насчёт замедления работы при преобразовании 32->24 - далеко не факт: конечно, это требует некоторое количество дополнительного кода, зато расходует меньше памяти, а обработка данных размером на четверть меньше (что запросто может занимать несколько сотен килобайт), имеет все шансы оказаться на четверть быстрее. (Кроме того, кэши вовсе не резиновые, а вылет из кэша чреват ещё большей потерей производительности.)
Serge wrote:
Я не о параметрах, а о реализации. Вся эта связка из ф.65 и vesa20_putimage с вызовом вспомогательных функций на каждый пиксель стала просто монстроподобной.

А что там такого монстроподобного? vesa20_putimage фактически не изменилась, только выбор очередного пикселя заменился на косвенный вызов функции.

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
PostPosted: Tue Nov 18, 2008 11:57 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Quote:
обработка данных размером на четверть меньше (что запросто может занимать несколько сотен килобайт), имеет все шансы оказаться на четверть быстрее

За счёт чего если одна команда mov [edx], eax заменяется тремя
Code:
     mov   [edx],ax
     shr   eax,16
     mov   [edx+2],al
Пенальти на за невыровненный доступ к памяти на каждом втором пикселе и пересечение границы линейки кеша на каждом шестом.

Кеши конечно не резиновые, поэтому есть разные movnt*. Ещё есть очень полезное руководство Using Block Prefetch for Optimized Memory Performance если кто-то думает что быстрее rep movsd ничего нет.

Вообще чтение из видеопамяти очень тормозная вещь. Tungsten Graphics приводит 10Mb/с в качестве среднего значения из-за отсутствия предвыборки. Так что чтение по 8 или 16 байт дадут прирост в два - четыре раза.

vesa20_putimage.

IMHO лучше выделить основной цикл в отдельный код для каждого варианта. Вызывать функцию преобразования на каждом пикселе слишком затратно. Запись в видеопамять идёт очень быстро, кеш не забивается, здесь реально получить очень высокие скорости.


Top
   
PostPosted: Tue Nov 18, 2008 6:59 pm 
Offline
User avatar

Joined: Fri Jun 27, 2008 3:22 pm
Posts: 988
Привет Mario79 !

А можно узнать чем тебя не устраивает форум или я чего-то не так понял?
Функция твоя, очень даже хорошая вещь, а Майк по-моему предложил всего лишь обсудить как её можно улучшить, как до этого обсуждали и другие функции. Я например всегда рад разумной критике, т.к. она позволяет мне делать мои программы лучше. А как же иначе? Ведь хотя у Колибри на мой взгляд есть немало пользователей, но большинство из них по каким-то причинам не пишут, о найденных багах, и способах улучшения программ, так что приходится разработчикам самим, становится ещё и тестерами программ других разработчиков. Если здесь кто-то говорит, что некоторые сделанные вещи можно улучшить, то предполагается, что он может сделать эти улучшения, но хотел бы обсудить это с другими людьми. Майк потому тебя лично и попросил уточнить назначение твой функции, потому как сам только предполагал её предназначение (причём ошибочно). А представь, если бы он взял бы и молча изменил её так как предложил в посте, по-твоему это было бы лучше? Потому у Колибри и есть команда, что все сообща работают над её улучшением, и помогают друг другу, в этом и заключается одно из основных преимуществ её перед другими дискеточными ОСями, которые хоть и не плохи, но не имеют большого сообщества. Посмотри хотя бы на SolarOS, мне просто стало жалко её автора Богдана Отану, когда я зашёл на её форум.
Так что твоя реакция в 4, 5 и 6 мне не понятна. Пора забыть уже все старые споры и браться наконец за дело, и так уже почти полгода ядерщики не развивали trunk. Я рад был узнать, что ты снова занялся им :) Вместе с Даймондом, Майком, Сержем и другими ядерщиками дела снова пойдут. Так что заходи на форум почаще, лично мне приятно будет с тобой пообщаться :) .


Top
   
PostPosted: Wed Nov 19, 2008 1:40 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Насчёт тормознутости преобразования - убедил.
Serge wrote:
IMHO лучше выделить основной цикл в отдельный код для каждого варианта. Вызывать функцию преобразования на каждом пикселе слишком затратно.

Ммм... так ведь в любом случае само по себе преобразование нужно, а создание отдельного кода уже сейчас приведёт к четырёхкратному дублированию всех процедур (vesa20/vesa12 + 24bpp/32bpp), а в общем случае - к ещё большему раздуванию. Не слишком ли затратно для избавления от одного call?


Top
   
PostPosted: Wed Nov 19, 2008 10:38 am 
Offline
User avatar

Joined: Thu Mar 01, 2007 4:16 pm
Posts: 426
> Вызывать функцию преобразования на каждом пикселе слишком затратно.
Её можно вызывать не для одного пикселя, а для n-пикселей. Это может быть как строка, так и целый буфер с изображением.
Или эта функция может получать в качестве параметров - (1) указатель на начало буфера (на первую точку, подлежащую обработке), (2) количество (точек подлежащих обработке) и (3) шаг в точках (1 - для нормальной ситуации, это преобразование строки или всего буфера, а width - для преобразование столбца). А так же (4) указатель для результата и (5) шаг для результата.
Я такой подход использовал. Только не для преобразования, а для вывода графики в буфер и без 4 и 5, соответственно. В таком случае все функции вывода сводились к одной. Где и могло выполняться автоматическое конвертирование формата точки.

А с другой стороны:
> Не слишком ли затратно для избавления от одного call?
Считаю, что в данной ситуации - нет.

..bw


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 23 posts ]  Go to page 1 2 Next

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