Помогите новичку

Applications development, KoOS API questions
  • Mario
    Накладные расходы 4Кб. Если приложение работает в несколько потоков выигрыш будет точно. А для прикладника выигрыш в простоте.
  • art_zh wrote:Rock_maniak_forever
    36-я кривая, там всё закручено через медленный call dword [GETPIXEL], да еще и с преобразованием в 24bpp.
    С той же скоростью ты можешь закрутить и 35-ю в цикле - главное сформировать (один раз) битмап исходного экрана. Все равно пока ты двигаешь скроллбар - эта область меняться не будет.
    Отдельно нарисовать скроллбар и уже на него накладывать исходный битмап.
    Потом вывести то что получилось обратно функцией 65 - мерцать не должно.

    .....Надо бы сделать новую 32bpp-функцию с прямым копированием экрана в битмап.
    art_zh Спасибо попробую. :D

    Ещё вопрос. :roll: А можно ли сделать снимок ф.61 или она только для записи в в.б.? Если да, то будет ли она быстрее, чем выше превидённые функции?
  • Rock_maniak_forever
    Есть прямой доступ к видеопамяти по адресу 0xFE000000. Только надо учитывать ширину строки в байтах.
  • Ну да, через фреймбуфер оно конечно быстрее всего, и тогда 61-я нужна (от геморроя).
  • Serge wrote:Rock_maniak_forever
    Есть прямой доступ к видеопамяти по адресу 0xFE000000.
    Немного не догнал! Как с этого адреса, считать цвет пикселя?

    Code: Select all

    mov eax,61               ; <-|
    mov ebx, [gs:0xFE000000] ; <- так, что ли? 
    int 0x40                 ; <-|
    Serge wrote:Только надо учитывать ширину строки в байтах.
    Ну, эта не проблема, лишь бы работала быстро.
  • 36 функция удобна тем, что:
    1) Она универсальна - всегда получаешь 24 бита изображения. Результат ожидаем и не нужны дополнительные телодвижения со стороны приложения. Удобно.
    2) 24 бит против 32 бит это экономия 25% памяти. Я конечно понимаю, что в век когда космические корабли бороздят просторы Большого память типичного ПК измеряется в гигабайтах это не столь актуально, но лично мне не нравится наметившаяся тенденция к разбуханию как программ, так и областей с данными.

    Прозрачность она вообще требует существенных накладных расходов и ее реализация для VESA в качестве массового явления это путь тупик. Это съест все те доли процентов, которые я выжимал оптимизируя код VESA в течении нескольких десятков ревизий, чтобы скомпенсировать последствия внедрения кода с не отключающимся курсором. Впрочем дело хозяйское - можно и трусы через голову надевать в личных целях.
  • Rock_maniak_forever

    Намного проще.
    mov eax, [0xFE000000] - первый пиксель
    mov eax, [0xFE000004] - второй пиксель
    и т.д. если 32 bpp

    посмотри исходники pixlib svn://kolibrios.org/programs/develop/libraries/pixlib
  • Это что - очередная недокументированная возможность?
  • FireWall
    Этой возможности лет 6. Упоминалась время от времени в разных темах.
  • Mario wrote:36 функция удобна тем, что:
    1) Она универсальна - всегда получаешь 24 бита изображения. Результат ожидаем и не нужны дополнительные телодвижения со стороны приложения. Удобно.
    Да, удобно, если не учитывать, что она очень сильно тормозит. Ради скорости, я готов пожертвовать лишней 100-ей байт и своим удобством, потому что меня очень достали тормоза, в Wыньдос и Unix системах.
    Mario wrote:2) 24 бит против 32 бит это экономия 25% памяти. Я конечно понимаю, что в век когда космические корабли бороздят просторы Большого память типичного ПК измеряется в гигабайтах это не столь актуально, но лично мне не нравится наметившаяся тенденция к разбуханию как программ, так и областей с данными.
    Ну, это смотря, в каких задачах. А потом я и так на Ассемблере пишу, что само собой, при хорошей оптимизации. экономит много памяти, в отличае от наСильников. В моём макросе, с использованием прямого доступа к видео памяти, будет экономия опер. памяти очень существенная (порядка 100Кб - зависит от размеров скроллбара), чем при использовании ф.35/36, не смотря на то, что бинарник увеличится на жалкие ~100 байт.
    Mario wrote:Прозрачность она вообще требует существенных накладных расходов и ее реализация для VESA в качестве массового явления это путь тупик.
    Возможно, но я очень люблю прозрачность. И потом, её массовой реализации под Колибри, я что-то не видел. Да и либу мою, всё ровно никто не использует (кроме меня), и вряд ли будут использовать.
    Mario wrote:Это съест все те доли процентов, которые я выжимал оптимизируя код VESA в течении нескольких десятков ревизий, чтобы скомпенсировать последствия внедрения кода с не отключающимся курсором. Впрочем дело хозяйское - можно и трусы через голову надевать в личных целях.
    1. Большое пасибо, за оптимиззацию кода VESA.
    2. Я трусы, на голову, одевать не собираюсь.
    3. Как писать свои программы, это моё личное дело.
    4. Я же не лезу в твою оптимизацию кода VESA, в ядре. Может ты там лишние 10 байт пожертвовал, для ускорения графики.
    Serge wrote:Rock_maniak_forever

    Намного проще.
    mov eax, [0xFE000000] - первый пиксель
    mov eax, [0xFE000004] - второй пиксель
    и т.д. если 32 bpp

    посмотри исходники pixlib svn://kolibrios.org/programs/develop/libraries/pixlib
    Спасибо, щас гляну.
  • Rock_maniak_forever wrote:
    Mario wrote:2) 24 бит против 32 бит это экономия 25% памяти. Я конечно понимаю, что в век когда космические корабли бороздят просторы Большого память типичного ПК измеряется в гигабайтах это не столь актуально, но лично мне не нравится наметившаяся тенденция к разбуханию как программ, так и областей с данными.
    Ну, это смотря, в каких задачах. А потом я и так на Ассемблере пишу, что само собой, при хорошей оптимизации. экономит много памяти, в отличае от наСильников. В моём макросе, с использованием прямого доступа к видео памяти, будет экономия опер. памяти очень существенная (порядка 100Кб - зависит от размеров скроллбара), чем при использовании ф.35/36, не смотря на то, что бинарник увеличится на жалкие ~100 байт.
    Я говорю про размер буфера под хранение данных. Размер бинарников тут совершенно роли не играет. Соответственно не нужно высказывать нападки к ЯВУ программистам.

    Если человек захочет скроллбар шириной в 30 пикселей (вполне реальное значение) и он будет на весь экран, то возьмем типичные 1024*768 (как некий средний размер экрана). Получим 30*4*768 = 90 Кб. В то время как 30*3*768= 67,5 Кб. Разница в 22,5 Кб, не совсем те 100 байт которые упоминались.
    Rock_maniak_forever wrote:3. Как писать свои программы, это моё личное дело.
    Я не отказывал кому-либо в праве иметь личное мнение и личное дело. Однако как любой человек я могу высказывать свои сомнения вслух.
  • Serge wrote:Rock_maniak_forever

    Намного проще.
    mov eax, [0xFE000000] - первый пиксель
    mov eax, [0xFE000004] - второй пиксель
    и т.д. если 32 bpp
    То есть можно так делать, без прерываний, если битность и разреш. экрана заранее известны?
    Serge wrote:Rock_maniak_forever
    посмотри исходники pixlib svn://kolibrios.org/programs/develop/libraries/pixlib
    Посмотрел, но почти ничего не понял, ибо почти весь код, на наСильнике. И что находится тут "0xDF000000"?
  • Mario wrote:Если человек захочет скроллбар шириной в 30 пикселей (вполне реальное значение) и он будет на весь экран, то возьмем типичные 1024*768 (как некий средний размер экрана). Получим 30*4*768 = 90 Кб. В то время как 30*3*768= 67,5 Кб. Разница в 22,5 Кб, не совсем те 100 байт которые упоминались.
    1. Под ста байтами, я имел ввиду размер бинарника. А под 100Кб, я имел ввиду размер трёх буферов, выделяемых для ф.36.
    2. Вот я и говорю, всё зависит от задачи. В 24 битной картинке, не получится сделать полупрозрачность в каждом пикселе отдельно.
    3. Под экономией в моём макросе, я имел ввиду избавление от лишних буферов которые использовала ф.36. Потому, что при исп. прямого доступа в видео буфер, те буфера которые выделялись для ф.36, будут не нужны. Тем самым, я существенно экономлю опер. память и получаю быстрый вывод, увеличив бинарник на жалкие ~100 байт.
  • Rock_maniak_forever

    Code: Select all

    #ifdef KOLIBRI_PE
      #define  LFB_BASE   0xDF000000
    #else
      #define  LFB_BASE   0xFE000000
    #endif
    В КРЕ был другой базовый адрес видеопамяти.
  • Who is online

    Users browsing this forum: No registered users and 7 guests