Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Вс авг 20, 2017 5:08 am

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




Начать новую тему  Ответить на тему  [ 23 сообщения ]  На страницу 1 2 След.
Автор Сообщение
 Заголовок сообщения: Новая функция: #36
СообщениеДобавлено: Вс ноя 16, 2008 8:08 pm 
Не в сети
Site Founder
Аватара пользователя

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

_________________
in code we trust


Вернуться к началу
 Заголовок сообщения: Re: Новая функция: #36
СообщениеДобавлено: Вс ноя 16, 2008 8:32 pm 
Не в сети
Kernel Developer

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


Вернуться к началу
 Заголовок сообщения: Re: Новая функция: #36
СообщениеДобавлено: Вс ноя 16, 2008 9:11 pm 
Не в сети
Site Founder
Аватара пользователя

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

_________________
in code we trust


Вернуться к началу
 Заголовок сообщения: Re: Новая функция: #36
СообщениеДобавлено: Пн ноя 17, 2008 9:19 am 
Не в сети
Kernel Optimizer
Аватара пользователя

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


Последний раз редактировалось <Lrz> Пн ноя 17, 2008 11:08 am, всего редактировалось 3 раза.

Вернуться к началу
 Заголовок сообщения: Re: Новая функция: #36
СообщениеДобавлено: Пн ноя 17, 2008 9:45 am 
Не в сети
Аватара пользователя

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

..bw


Вернуться к началу
 Заголовок сообщения: Re: Новая функция: #36
СообщениеДобавлено: Пн ноя 17, 2008 3:48 pm 
Не в сети
Designer
Аватара пользователя

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

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


Вернуться к началу
 Заголовок сообщения: Re: Новая функция: #36
СообщениеДобавлено: Пн ноя 17, 2008 9:56 pm 
Не в сети
Аватара пользователя

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

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

*****:


Вернуться к началу
 Заголовок сообщения: Re: Новая функция: #36
СообщениеДобавлено: Пн ноя 17, 2008 11:16 pm 
Не в сети
Kernel Developer

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


Вернуться к началу
 Заголовок сообщения: Re: Новая функция: #36
СообщениеДобавлено: Пн ноя 17, 2008 11:22 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
Serge писал(а):
Какой смысл конвертировать в 24bpp ? Экономия памяти небольшая, больше неудобства.

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

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


Вернуться к началу
 Заголовок сообщения: Re: Новая функция: #36
СообщениеДобавлено: Вт ноя 18, 2008 1:54 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3928
ф.36 сохраняет картинку в формате 24bpp. Для 24 bpp экрана это нормально, особенно если не тянуть всю картинку по одному пикселю. Но для 32 bpp замедляет работу.

diamond

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


Вернуться к началу
 Заголовок сообщения: Re: Новая функция: #36
СообщениеДобавлено: Вт ноя 18, 2008 2:31 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
Serge писал(а):
ф.36 сохраняет картинку в формате 24bpp. Для 24 bpp экрана это нормально, особенно если не тянуть всю картинку по одному пикселю. Но для 32 bpp замедляет работу.

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

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

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


Вернуться к началу
 Заголовок сообщения: Re: Новая функция: #36
СообщениеДобавлено: Вт ноя 18, 2008 11:57 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3928
Цитата:
обработка данных размером на четверть меньше (что запросто может занимать несколько сотен килобайт), имеет все шансы оказаться на четверть быстрее

За счёт чего если одна команда mov [edx], eax заменяется тремя
Код:
     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 лучше выделить основной цикл в отдельный код для каждого варианта. Вызывать функцию преобразования на каждом пикселе слишком затратно. Запись в видеопамять идёт очень быстро, кеш не забивается, здесь реально получить очень высокие скорости.


Вернуться к началу
 Заголовок сообщения: Re: Новая функция: #36
СообщениеДобавлено: Вт ноя 18, 2008 6:59 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пт июн 27, 2008 3:22 pm
Сообщения: 973
Привет Mario79 !

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


Вернуться к началу
 Заголовок сообщения: Re: Новая функция: #36
СообщениеДобавлено: Ср ноя 19, 2008 1:40 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
Насчёт тормознутости преобразования - убедил.
Serge писал(а):
IMHO лучше выделить основной цикл в отдельный код для каждого варианта. Вызывать функцию преобразования на каждом пикселе слишком затратно.

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


Вернуться к началу
 Заголовок сообщения: Re: Новая функция: #36
СообщениеДобавлено: Ср ноя 19, 2008 10:38 am 
Не в сети
Аватара пользователя

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

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

..bw


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 23 сообщения ]  На страницу 1 2 След.

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


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

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


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

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