Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Apr 05, 2020 4:02 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 1138 posts ]  Go to page Previous 138 39 40 41 4276 Next
Author Message
PostPosted: Mon Sep 24, 2012 9:12 pm 
Offline
Kernel Developer
User avatar

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

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


Top
   
PostPosted: Mon Sep 24, 2012 11:13 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario
Накладные расходы 4Кб. Если приложение работает в несколько потоков выигрыш будет точно. А для прикладника выигрыш в простоте.


Top
   
PostPosted: Tue Sep 25, 2012 12:14 am 
Offline
User avatar

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

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

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

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

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


Top
   
PostPosted: Tue Sep 25, 2012 12:36 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Rock_maniak_forever
Есть прямой доступ к видеопамяти по адресу 0xFE000000. Только надо учитывать ширину строки в байтах.


Top
   
PostPosted: Tue Sep 25, 2012 1:37 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1402
Ну да, через фреймбуфер оно конечно быстрее всего, и тогда 61-я нужна (от геморроя).


Top
   
PostPosted: Tue Sep 25, 2012 4:24 am 
Offline
User avatar

Joined: Mon Feb 09, 2009 4:13 am
Posts: 445
Serge wrote:
Rock_maniak_forever
Есть прямой доступ к видеопамяти по адресу 0xFE000000.
Немного не догнал! Как с этого адреса, считать цвет пикселя?
Code:
mov eax,61               ; <-|
mov ebx, [gs:0xFE000000] ; <- так, что ли?
int 0x40                 ; <-|
Serge wrote:
Только надо учитывать ширину строки в байтах.
Ну, эта не проблема, лишь бы работала быстро.

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


Top
   
PostPosted: Tue Sep 25, 2012 7:24 am 
36 функция удобна тем, что:
1) Она универсальна - всегда получаешь 24 бита изображения. Результат ожидаем и не нужны дополнительные телодвижения со стороны приложения. Удобно.
2) 24 бит против 32 бит это экономия 25% памяти. Я конечно понимаю, что в век когда космические корабли бороздят просторы Большого память типичного ПК измеряется в гигабайтах это не столь актуально, но лично мне не нравится наметившаяся тенденция к разбуханию как программ, так и областей с данными.

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


Top
   
PostPosted: Tue Sep 25, 2012 11:04 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Rock_maniak_forever

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

посмотри исходники pixlib svn://kolibrios.org/programs/develop/libraries/pixlib


Top
   
PostPosted: Tue Sep 25, 2012 2:23 pm 
Offline

Joined: Wed Sep 15, 2010 7:22 pm
Posts: 101
Это что - очередная недокументированная возможность?


Top
   
PostPosted: Tue Sep 25, 2012 4:05 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
FireWall
Этой возможности лет 6. Упоминалась время от времени в разных темах.


Top
   
PostPosted: Tue Sep 25, 2012 4:21 pm 
Offline
User avatar

Joined: Mon Feb 09, 2009 4:13 am
Posts: 445
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
Спасибо, щас гляну.

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


Top
   
PostPosted: Tue Sep 25, 2012 4:42 pm 
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. Как писать свои программы, это моё личное дело.

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


Top
   
PostPosted: Tue Sep 25, 2012 4:53 pm 
Offline
User avatar

Joined: Mon Feb 09, 2009 4:13 am
Posts: 445
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"?

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


Top
   
PostPosted: Tue Sep 25, 2012 5:26 pm 
Offline
User avatar

Joined: Mon Feb 09, 2009 4:13 am
Posts: 445
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 байт.

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


Top
   
PostPosted: Tue Sep 25, 2012 6:41 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Rock_maniak_forever
Code:
#ifdef KOLIBRI_PE
  #define  LFB_BASE   0xDF000000
#else
  #define  LFB_BASE   0xFE000000
#endif
В КРЕ был другой базовый адрес видеопамяти.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 1138 posts ]  Go to page Previous 138 39 40 41 4276 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited