Board.KolibriOS.org

Rock_maniak_forever
36-я кривая, там всё закручено через медленный call dword [GETPIXEL], да еще и с преобразованием в 24bpp.
С той же скоростью ты можешь закрутить и 35-ю в цикле - главное сформировать (один раз) битмап исходного экрана. Все равно пока ты двигаешь скроллбар - эта область меняться не будет.
Отдельно нарисовать скроллбар и уже на него накладывать исходный битмап.
Потом вывести то что получилось обратно функцией 65 - мерцать не должно.

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

Mario
Накладные расходы 4Кб. Если приложение работает в несколько потоков выигрыш будет точно. А для прикладника выигрыш в простоте.

art_zh Спасибо попробую.

Ещё вопрос. А можно ли сделать снимок ф.61 или она только для записи в в.б.? Если да, то будет ли она быстрее, чем выше превидённые функции?

_________________
\ Маузер в руке, Путин – на крюке! \ Путину – клизму! Смерть капитализму! \ Путин – параша, победа будет наша!\
\ Застрели буржуя в спину! Он не лучше чем скотина! \

Rock_maniak_forever
Есть прямой доступ к видеопамяти по адресу 0xFE000000. Только надо учитывать ширину строки в байтах.

Ну да, через фреймбуфер оно конечно быстрее всего, и тогда 61-я нужна (от геморроя).

Немного не догнал! Как с этого адреса, считать цвет пикселя?

mov eax,61               ; <-|
mov ebx, [gs:0xFE000000] ; <- так, что ли? 
int 0x40                 ; <-|

Ну, эта не проблема, лишь бы работала быстро.

_________________
\ Маузер в руке, Путин – на крюке! \ Путину – клизму! Смерть капитализму! \ Путин – параша, победа будет наша!\
\ Застрели буржуя в спину! Он не лучше чем скотина! \

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. Упоминалась время от времени в разных темах.

Да, удобно, если не учитывать, что она очень сильно тормозит. Ради скорости, я готов пожертвовать лишней 100-ей байт и своим удобством, потому что меня очень достали тормоза, в Wыньдос и Unix системах.
Ну, это смотря, в каких задачах. А потом я и так на Ассемблере пишу, что само собой, при хорошей оптимизации. экономит много памяти, в отличае от наСильников. В моём макросе, с использованием прямого доступа к видео памяти, будет экономия опер. памяти очень существенная (порядка 100Кб - зависит от размеров скроллбара), чем при использовании ф.35/36, не смотря на то, что бинарник увеличится на жалкие ~100 байт.
Возможно, но я очень люблю прозрачность. И потом, её массовой реализации под Колибри, я что-то не видел. Да и либу мою, всё ровно никто не использует (кроме меня), и вряд ли будут использовать.
1. Большое пасибо, за оптимиззацию кода VESA.
2. Я трусы, на голову, одевать не собираюсь.
3. Как писать свои программы, это моё личное дело.
4. Я же не лезу в твою оптимизацию кода VESA, в ядре. Может ты там лишние 10 байт пожертвовал, для ускорения графики.
Спасибо, щас гляну.

_________________
\ Маузер в руке, Путин – на крюке! \ Путину – клизму! Смерть капитализму! \ Путин – параша, победа будет наша!\
\ Застрели буржуя в спину! Он не лучше чем скотина! \

Я говорю про размер буфера под хранение данных. Размер бинарников тут совершенно роли не играет. Соответственно не нужно высказывать нападки к ЯВУ программистам.

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

Я не отказывал кому-либо в праве иметь личное мнение и личное дело. Однако как любой человек я могу высказывать свои сомнения вслух.

То есть можно так делать, без прерываний, если битность и разреш. экрана заранее известны?
Посмотрел, но почти ничего не понял, ибо почти весь код, на наСильнике. И что находится тут "0xDF000000"?

_________________
\ Маузер в руке, Путин – на крюке! \ Путину – клизму! Смерть капитализму! \ Путин – параша, победа будет наша!\
\ Застрели буржуя в спину! Он не лучше чем скотина! \

1. Под ста байтами, я имел ввиду размер бинарника. А под 100Кб, я имел ввиду размер трёх буферов, выделяемых для ф.36.
2. Вот я и говорю, всё зависит от задачи. В 24 битной картинке, не получится сделать полупрозрачность в каждом пикселе отдельно.
3. Под экономией в моём макросе, я имел ввиду избавление от лишних буферов которые использовала ф.36. Потому, что при исп. прямого доступа в видео буфер, те буфера которые выделялись для ф.36, будут не нужны. Тем самым, я существенно экономлю опер. память и получаю быстрый вывод, увеличив бинарник на жалкие ~100 байт.

_________________
\ Маузер в руке, Путин – на крюке! \ Путину – клизму! Смерть капитализму! \ Путин – параша, победа будет наша!\
\ Застрели буржуя в спину! Он не лучше чем скотина! \

Rock_maniak_forever

#ifdef KOLIBRI_PE
  #define  LFB_BASE   0xDF000000
#else
  #define  LFB_BASE   0xFE000000
#endif

В КРЕ был другой базовый адрес видеопамяти.