Новая функция: #36

Kernel-side graphics support
  • Функция копирует в буфер [ebx] часть экрана с конвертацией в формат RGB24. И делает это одним из самых медленных способов.
  • Дело в том, что "что она делает" я знаю. Хотелось бы услышать начальника транспортного цеха с объяснением того "зачем она нужна"...
    Моё личное предположение - для реализации прокрутки содержимого элементов управления. Почему я подумал именно в эту сторону? Потому что есть небольшое расхождение в документации (по крайней мере на английском языке, русскую не читал): в названии упоминается "read screen area", в то время как в описании присутствует "relative to the window". Это первый недочёт. Получается, что кое-кто хочет получить часть рисунка окна (кстати, зачем делать координаты относительно окна, если получаемые пикселы размером этого окна не ограничиваются) и потом отрисовать полученный буфер в другом месте экрана (используя функцию #7). Вместо этого, можно было бы реализовать функцию прокрутки прямоугольника или же копирования заданного прямоугольника с одного места экрана на другое (которую, вроде как, даже графические ускорители поддерживают).
    Ждём комментариев просвещённых.
    in code we trust
  • 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.
  • > Вместо этого, можно было бы реализовать функцию прокрутки прямоугольника или же копирования заданного прямоугольника с одного места экрана на другое (которую, вроде как, даже графические ускорители поддерживают).
    Поддерживаю. И не вроде как, а точно. И только такая функция (копирования участка видеопамяти) даст прирост производительности с появлением поддержки железного ускорения. Копирование в оперативную память, в таком случае, плохая идея. Хотя меня не травмирует наличие в ядре функции, предложенной Маратом.

    ..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 заменяется тремя

    Code: Select all

         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 лучше выделить основной цикл в отдельный код для каждого варианта. Вызывать функцию преобразования на каждом пикселе слишком затратно. Запись в видеопамять идёт очень быстро, кеш не забивается, здесь реально получить очень высокие скорости.
  • Привет Mario79 !

    А можно узнать чем тебя не устраивает форум или я чего-то не так понял?
    Функция твоя, очень даже хорошая вещь, а Майк по-моему предложил всего лишь обсудить как её можно улучшить, как до этого обсуждали и другие функции. Я например всегда рад разумной критике, т.к. она позволяет мне делать мои программы лучше. А как же иначе? Ведь хотя у Колибри на мой взгляд есть немало пользователей, но большинство из них по каким-то причинам не пишут, о найденных багах, и способах улучшения программ, так что приходится разработчикам самим, становится ещё и тестерами программ других разработчиков. Если здесь кто-то говорит, что некоторые сделанные вещи можно улучшить, то предполагается, что он может сделать эти улучшения, но хотел бы обсудить это с другими людьми. Майк потому тебя лично и попросил уточнить назначение твой функции, потому как сам только предполагал её предназначение (причём ошибочно). А представь, если бы он взял бы и молча изменил её так как предложил в посте, по-твоему это было бы лучше? Потому у Колибри и есть команда, что все сообща работают над её улучшением, и помогают друг другу, в этом и заключается одно из основных преимуществ её перед другими дискеточными ОСями, которые хоть и не плохи, но не имеют большого сообщества. Посмотри хотя бы на SolarOS, мне просто стало жалко её автора Богдана Отану, когда я зашёл на её форум.
    Так что твоя реакция в 4, 5 и 6 мне не понятна. Пора забыть уже все старые споры и браться наконец за дело, и так уже почти полгода ядерщики не развивали trunk. Я рад был узнать, что ты снова занялся им :) Вместе с Даймондом, Майком, Сержем и другими ядерщиками дела снова пойдут. Так что заходи на форум почаще, лично мне приятно будет с тобой пообщаться :) .
  • Насчёт тормознутости преобразования - убедил.
    Serge wrote:IMHO лучше выделить основной цикл в отдельный код для каждого варианта. Вызывать функцию преобразования на каждом пикселе слишком затратно.
    Ммм... так ведь в любом случае само по себе преобразование нужно, а создание отдельного кода уже сейчас приведёт к четырёхкратному дублированию всех процедур (vesa20/vesa12 + 24bpp/32bpp), а в общем случае - к ещё большему раздуванию. Не слишком ли затратно для избавления от одного call?
  • > Вызывать функцию преобразования на каждом пикселе слишком затратно.
    Её можно вызывать не для одного пикселя, а для n-пикселей. Это может быть как строка, так и целый буфер с изображением.
    Или эта функция может получать в качестве параметров - (1) указатель на начало буфера (на первую точку, подлежащую обработке), (2) количество (точек подлежащих обработке) и (3) шаг в точках (1 - для нормальной ситуации, это преобразование строки или всего буфера, а width - для преобразование столбца). А так же (4) указатель для результата и (5) шаг для результата.
    Я такой подход использовал. Только не для преобразования, а для вывода графики в буфер и без 4 и 5, соответственно. В таком случае все функции вывода сводились к одной. Где и могло выполняться автоматическое конвертирование формата точки.

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

    ..bw
  • Who is online

    Users browsing this forum: No registered users and 3 guests