Войти
ПрограммированиеФорумГрафика

Что изменилось в Windows 7 при отрисовке десктопа? софтверная отрисовка с контролем fps - теперь дергается

Страницы: 1 2 3 4 Следующая »
#0
17:50, 18 ноя. 2013

проблема возникает с контролем fps, с плавностью отрисовки. при использовании обычного bitblit - инга.
он теперь происходит неровно, начиная примерно с 30-ти кадров в секунду.
это конечно затрагивает только софтварные рендеры и т.п.

OpenGL и DirectX - там все нормально. это естественно. у них все свое. при переходе на классическую тему - все нормализуется, но и там видно, что в этом компоненте семерка стала заметно дерганей xp.

вот тест: http://www.nemehanika.ru/cg/download/test.exe
на XP идет сверх плавно, внутри программы никаких неучтенных потерей времени нет. слева отрисовывается время расчетов, справа время простоя. ну это не важно... главное: что-то испортилось с новой версией винды и пока не понятно, что с этим делать?

эффект видимо такой для аэро: - через определенный промежуток времени необходимость вывода(блитинг) натыкается на какую-то операцию семерки и происходит задержка вывода. т.е. формально блитинг происходит, а фактически задерживается и на солидный промежуток времени. словно у десктопа есть своя частота обновления.  но как это сратстается с тем, что у окон тоже свои могут быть частоты обновления?
может надо это как-то в событиях более грамотно заявить, чтоб винде было понятно когда окно программы обновляется, раз битблитинг этого не достигает. хрен его знает пока...

какие у кого есть соображения, может кто-то знает где об это почитать?.  фактически изменились достаточно ключевые спецификации и только распространненость опенжл и деректикса маскируют пока какой-то толи ляп майкрософта толи интересную фичу... но пока больше на ляп похоже...

относить весь битблитинг в WM_PAINT пробовал, не помогает.


#1
18:46, 18 ноя. 2013

GDI и так был как неторопливый жук навозник, а в Windows 7 он и вовсе дохлый. Если в Windows XP каждое GDI приложение находилось в очереди на отрисовку, т. е. происходила блокировка и каждое приложение по очереди использовали GID, то в Windows 7 для параллелизма механизм отрисовки изменили: сделали несколько независимых блокировок, после чего приложения перестали зависеть друг от друга, и после чего стали быстрее работать на многоядерных процессорах, но не наоборот. Это первая не столь очевидная причина, более очевидная следующая:

В Windows 7 изменили распределение памяти для GDI, теперь в нем все графические данные хранятся в видео-памяти (раньше детальная копия этих же данных хранилась и в системной памяти, что увеличивала затраты) и как раз из-за этого могут происходить задержки, например при чтении из видео памяти или на системные проверки выполняемые GDI.

Короче как не извертись, GDI от этого быстрее не станет.

Но точно знаю, что можно использовать дракона DirectDraw, он точно тормозить не будет, сам лично испытывал его (но с ним столько возни)...

#2
20:19, 18 ноя. 2013

>можно использовать дракона DirectDraw
это тот, на котором висит 2 десятка флагов "устарело", "не использовать", "ну и сам дурак", "еще твой дед на нем писал"?

#3
20:35, 18 ноя. 2013

Denadan
Да, тот самый

#4
23:03, 18 ноя. 2013

ну... bitblit не в составе GDI ничуть вроде...

странно все это, при fps 25 - все удивительно плавно, а начиная с 30 - словно какой-то резонанс наступает с некой внутренней деятельностью семерки.
примерно каждые 2 секунды - заметнейший рывок(задержка). при повышении, начиная примерно от 45 эффект размывается, просто из-за самой частоты кадров. но тоже остается.

и есть полный эффект выполненной VSYNC. что может неудивительно, если десктоп, например, реально через директикс рисуется и наверно имеет свою частоту обновления, которая например высчитывается по самому "суетливому" приложению. или фиг его знает, странно тоже представлять, что десктоп так много себя рисует постоянно, но вроде же из логики аэро это и вытекает.

на ixbt кто-то обмолвился что майкрософт завела некий общий буфер отрисовки десктопа с хитрой стратегией.
но подробно не развернул... 

#5
9:41, 19 ноя. 2013

igo
А может выводить картинку через OpenGL/Direct3D ? Тупо каждый кадр заливать нарендеренное своим софтрендером в текстуру и рисовать квадрат на весь экран с этой текстурой.

#6
9:49, 19 ноя. 2013

ZeroCool++
> GDI и так был как неторопливый жук навозник, а в Windows 7 он и вовсе дохлый.
Неправда. Правда я пользуюсь SetDiBitsToDevice, так вот эта ф-ция в Win7-8 стала раза в три быстрее, у меня лично работает очень гладко.

#7
11:44, 19 ноя. 2013

Panzerschrek[CN]
да можно то, да... если не причин не найдется, может так и придется сделать. и за одно ихним контролем частоты воспользоваться, но пока такой ход выглядит оч. некрасиво.


Mikle
двойная буферизация на GDI как выглядит? могешь скинуть в коде? если есть...

может туда майкрософты спецификации новые закапали...

#8
11:49, 19 ноя. 2013

igo
Двойная буферизация...создаёшь Bitmap размером с клиентскую часть окна (или куда ты там собираешься рисовать) и получаешь его HDC. И всё рисуешь в этот HDC. Когда приходит время вывести кадр на экран, рисуешь HDC Bitmap'а в HDC окна (или куда ты там собрался).

#9
11:51, 19 ноя. 2013

igo
> двойная буферизация на GDI как выглядит?
Она не требуется, просто формируется изображение в памяти, потом SetDiBitsToDevice на DC. Можешь проверить любой пример на SR2D, никаких мерцаний:
То есть двойная буферизация нужна только если рисуешь средствами GDI, а если свой софт рендер, то нет.

#10
12:40, 19 ноя. 2013

Mikle
ага, не гди...

но то что у тебя и у меня и у s3dworld и у... - по сути и есть двойная буферизация вроде. ну названия - не суть...
у меня тоже блитинг в 7-ке быстрее работает. это-то приятно.

а мерцаний-то нет и не было, все было хорошо-замечательно. дергаться только начало в семерке по неясным пока причинам.

ты мне просто кусочек кода брось прям сюда, как у тебя там что(совместимый битмап) объявляется и как он в dc отправляется.
твой способ попробую. там пара строк кажется, код самого дс - не нужен конечно...

s3dworld
и да... ну ее нафиг двойную буферизацию средствами GDI, лишние колеса не нужны - вопрос в том, что корректней работает на семерке.

это я от расстройства в ту сторону начал думать, что блитинг обычный вдруг перестал корректно работать.
#11
13:10, 19 ноя. 2013

igo
> просто кусочек кода брось прям сюда, как у тебя там что(совместимый битмап)
> объявляется и как он в dc отправляется.
Там примеры с кодом, работа с DC идёт не в DLL, а прямо в коде. Пример на VB6 более подходит для рассмотрения и перевода на C++, так как в C# пример ещё добавлены кое-какие костыли, чтобы совместить Managed и UnManaged код.

#12
1:35, 20 ноя. 2013

ZeroCool++
> GDI и так был как неторопливый жук навозник, а в Windows 7 он и вовсе дохлый.
> Если в Windows XP каждое GDI приложение находилось в очереди на отрисовку, т.
> е. происходила блокировка и каждое приложение по очереди использовали GID, то в
> Windows 7 для параллелизма механизм отрисовки изменили: сделали несколько
> независимых блокировок, после чего приложения перестали зависеть друг от друга,
> и после чего стали быстрее работать на многоядерных процессорах, но не
> наоборот. Это первая не столь очевидная причина, более очевидная следующая:

Все с точностью до наоборот. В WinAPI до висты GDI имел аппаратное ускорение в виде использования аппаратного блиттера для вывода содержимого DC в окна. В висте апаратный блиттер отключили, в семерке снова включили.

#13
21:59, 20 ноя. 2013

Mikle
в чужих исходниках утонуть можно, это надо еще найти где бэйсик запустить, чтоб подсветкой синтакиса задачу поиска облегчить...
ты ж сам сразу знаешь где оно у тебя...
прелесть форумов ведь не в том чтобы по гуглам другу-друга гонять и в исходниках топить...

ну пожалуста)))... сору-paste, please....

Wraith
есть примерчик хороший или ссылка с дб на GDI+?...

прошу не счесть за халявность, но нет любви к мелкософтовскому синтаксису, нет как нет... как не надо долго так забывается, какое у них там все страшное... и по гуглу прошел уже, накопал каких-то пухлых, буду разбирать...

на GDI вот теплится еще надежда, раз они с ним возятся еще.

а тож классический блитинг поламался блин. прям фундаменты рушатся...

#14
22:32, 20 ноя. 2013

igo
Да там и показывать особо нечего. Единственное, что стоит внимания - это то, что hDC получается один раз перед рендером, а не в каждом кадре. Думаю, ты это и сам делаешь.
Может причина тармозов в самой винде? Какой-нибудь гаджет рабочего стола может так себя проявлять.

Страницы: 1 2 3 4 Следующая »
ПрограммированиеФорумГрафика

Тема в архиве.