Board.KolibriOS.org

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

Функция копирует в буфер [ebx] часть экрана с конвертацией в формат RGB24. И делает это одним из самых медленных способов.

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

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

> Вместо этого, можно было бы реализовать функцию прокрутки прямоугольника или же копирования заданного прямоугольника с одного места экрана на другое (которую, вроде как, даже графические ускорители поддерживают).
Поддерживаю. И не вроде как, а точно. И только такая функция (копирования участка видеопамяти) даст прирост производительности с появлением поддержки железного ускорения. Копирование в оперативную память, в таком случае, плохая идея. Хотя меня не травмирует наличие в ядре функции, предложенной Маратом.

..bw

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

... функция должна быть... реализовани она не так уж и плохо, и в случае желания, никто не будет против, ели её препишут ради производительности... (ИМХО, конечно)... а вообще, критиковать чужие разработки - не гуд, никто никого не заставляет использовать эту функцию, и она никому не мешает... ...

Какой смысл конвертировать в 24bpp ? Экономия памяти небольшая, больше неудобства. И ф.65 сильно перегружена.

Serge wrote:Какой смысл конвертировать в 24bpp ? Экономия памяти небольшая, больше неудобства.

В смысле? Кто и откуда конвертирует?

Serge wrote:И ф.65 сильно перегружена.

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

ф.36 сохраняет картинку в формате 24bpp. Для 24 bpp экрана это нормально, особенно если не тянуть всю картинку по одному пикселю. Но для 32 bpp замедляет работу.

diamond

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

Serge wrote:ф.36 сохраняет картинку в формате 24bpp. Для 24 bpp экрана это нормально, особенно если не тянуть всю картинку по одному пикселю. Но для 32 bpp замедляет работу.

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

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

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

обработка данных размером на четверть меньше (что запросто может занимать несколько сотен килобайт), имеет все шансы оказаться на четверть быстрее

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

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

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

vesa20_putimage.

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

Насчёт тормознутости преобразования - убедил.

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

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

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

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

..bw