Rock_maniak_forever
36-я кривая, там всё закручено через медленный call dword [GETPIXEL], да еще и с преобразованием в 24bpp.
С той же скоростью ты можешь закрутить и 35-ю в цикле - главное сформировать (один раз) битмап исходного экрана. Все равно пока ты двигаешь скроллбар - эта область меняться не будет.
Отдельно нарисовать скроллбар и уже на него накладывать исходный битмап.
Потом вывести то что получилось обратно функцией 65 - мерцать не должно.
.....Надо бы сделать новую 32bpp-функцию с прямым копированием экрана в битмап.
Помогите новичку
Mario
Накладные расходы 4Кб. Если приложение работает в несколько потоков выигрыш будет точно. А для прикладника выигрыш в простоте.
Накладные расходы 4Кб. Если приложение работает в несколько потоков выигрыш будет точно. А для прикладника выигрыш в простоте.
art_zh Спасибо попробую.art_zh wrote:Rock_maniak_forever
36-я кривая, там всё закручено через медленный call dword [GETPIXEL], да еще и с преобразованием в 24bpp.
С той же скоростью ты можешь закрутить и 35-ю в цикле - главное сформировать (один раз) битмап исходного экрана. Все равно пока ты двигаешь скроллбар - эта область меняться не будет.
Отдельно нарисовать скроллбар и уже на него накладывать исходный битмап.
Потом вывести то что получилось обратно функцией 65 - мерцать не должно.
.....Надо бы сделать новую 32bpp-функцию с прямым копированием экрана в битмап.
Ещё вопрос. А можно ли сделать снимок ф.61 или она только для записи в в.б.? Если да, то будет ли она быстрее, чем выше превидённые функции?
Rock_maniak_forever
Есть прямой доступ к видеопамяти по адресу 0xFE000000. Только надо учитывать ширину строки в байтах.
Есть прямой доступ к видеопамяти по адресу 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 в течении нескольких десятков ревизий, чтобы скомпенсировать последствия внедрения кода с не отключающимся курсором. Впрочем дело хозяйское - можно и трусы через голову надевать в личных целях.
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
Намного проще.
mov eax, [0xFE000000] - первый пиксель
mov eax, [0xFE000004] - второй пиксель
и т.д. если 32 bpp
посмотри исходники pixlib svn://kolibrios.org/programs/develop/libraries/pixlib
Это что - очередная недокументированная возможность?
FireWall
Этой возможности лет 6. Упоминалась время от времени в разных темах.
Этой возможности лет 6. Упоминалась время от времени в разных темах.
Да, удобно, если не учитывать, что она очень сильно тормозит. Ради скорости, я готов пожертвовать лишней 100-ей байт и своим удобством, потому что меня очень достали тормоза, в Wыньдос и Unix системах.Mario wrote:36 функция удобна тем, что:
1) Она универсальна - всегда получаешь 24 бита изображения. Результат ожидаем и не нужны дополнительные телодвижения со стороны приложения. Удобно.
Ну, это смотря, в каких задачах. А потом я и так на Ассемблере пишу, что само собой, при хорошей оптимизации. экономит много памяти, в отличае от наСильников. В моём макросе, с использованием прямого доступа к видео памяти, будет экономия опер. памяти очень существенная (порядка 100Кб - зависит от размеров скроллбара), чем при использовании ф.35/36, не смотря на то, что бинарник увеличится на жалкие ~100 байт.Mario wrote:2) 24 бит против 32 бит это экономия 25% памяти. Я конечно понимаю, что в век когдакосмические корабли бороздят просторы Большогопамять типичного ПК измеряется в гигабайтах это не столь актуально, но лично мне не нравится наметившаяся тенденция к разбуханию как программ, так и областей с данными.
Возможно, но я очень люблю прозрачность. И потом, её массовой реализации под Колибри, я что-то не видел. Да и либу мою, всё ровно никто не использует (кроме меня), и вряд ли будут использовать.Mario wrote:Прозрачность она вообще требует существенных накладных расходов и ее реализация для VESA в качестве массового явления это путь тупик.
1. Большое пасибо, за оптимиззацию кода VESA.Mario wrote:Это съест все те доли процентов, которые я выжимал оптимизируя код 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:Ну, это смотря, в каких задачах. А потом я и так на Ассемблере пишу, что само собой, при хорошей оптимизации. экономит много памяти, в отличае от наСильников. В моём макросе, с использованием прямого доступа к видео памяти, будет экономия опер. памяти очень существенная (порядка 100Кб - зависит от размеров скроллбара), чем при использовании ф.35/36, не смотря на то, что бинарник увеличится на жалкие ~100 байт.Mario wrote:2) 24 бит против 32 бит это экономия 25% памяти. Я конечно понимаю, что в век когдакосмические корабли бороздят просторы Большогопамять типичного ПК измеряется в гигабайтах это не столь актуально, но лично мне не нравится наметившаяся тенденция к разбуханию как программ, так и областей с данными.
Если человек захочет скроллбар шириной в 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
Посмотрел, но почти ничего не понял, ибо почти весь код, на наСильнике. И что находится тут "0xDF000000"?Serge wrote:Rock_maniak_forever
посмотри исходники pixlib svn://kolibrios.org/programs/develop/libraries/pixlib
1. Под ста байтами, я имел ввиду размер бинарника. А под 100Кб, я имел ввиду размер трёх буферов, выделяемых для ф.36.Mario wrote:Если человек захочет скроллбар шириной в 30 пикселей (вполне реальное значение) и он будет на весь экран, то возьмем типичные 1024*768 (как некий средний размер экрана). Получим 30*4*768 = 90 Кб. В то время как 30*3*768= 67,5 Кб. Разница в 22,5 Кб, не совсем те 100 байт которые упоминались.
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 10 guests