Сообщение Re[32]: Еще от 12.06.2017 11:53
Изменено 12.06.2017 15:08 ononim
Re[32]: Еще
V>>Для абстракции HDC, полученной для поверхности DirectDraw, тоже выполнялось аппаратное ускорение.
CS>Тебя обманули.
Всех обманули: https://www.neowin.net/forum/topic/1036369-did-you-know-all-gdi-apps-render-slower-under-win7/
V>>Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места).
CS>Слушай, прекращай уже фантазировать. Какой нахрен битмап в видеопамяти?
А в чем проблема? Мапим нужные физ страницы из видеопамяти в юзермодное АП и радуемся супер-быстрим блиттингам из невидимого битмапа в экранный. Ну и расстраиваемся медленным чтениям из битмапов.
https://blogs.msdn.microsoft.com/tmulcahy/2009/02/11/windows-and-video-memory/ — особое внимание пунктику 6, в висте это разумеется сломали, в семерке немного починили, и все возрадовались — ура, нормальная ось.
Давно ведь известный метод маркетинга — не сможешь сделать лучше, сделай хуже, а потом исправь. Немножечко — чтоб остался задел на будущее.
CS>
И была лет 11 назад у меня задача сделать "затененную" копию экрана, ну примерно как сейчас с UACом делается, и кстати для примерно такой же цели, наверно МС у нас идею стырило, да не в этом суть. А суть в том что я заюзал тогда эту самую AlphaBlend и все было замечательно, пока QA не обнаружило, что на одной из систем в результате вместо затененной картинки получается какой-то трэш из сдвинутых строк. Путем локализации бага оказалось что виновата.. видюха (какая — уже не помню)!
Фикс был простой — накропать альфа бленд ручками, получив GetDIBits и просчитав все самому, то есть сделав тот самый CPU rendering. Оно работало сильно медленнее, если засекать фреймы-в-секунды, но на моей задаче это было непринципиально.
А мораль сей басни такова — не только BitBlt хардварно процессился, но еще и AlphaBlend. Дело было, кстати на ХР. Потом на том же железе интереса ради проверил на свежепоявившейся Висте — баг не воспроизводился.
Ну а то что альфабленд уже в те времена процессился хардварно на WS_EX_LAYERED окнах — это по моему и ежу понятно было. Причем работал и per-pixel блендинг, используя 4й канал битмапов. То есть в принципе техническая возможность допилить GDI чтобы BitBlt поддерживал блендинг, заданный в 4м канале битмапов, явно была, но сдвиг парадигмы разработки винды в сторону "каждую новую фичу пишем с нуля, отдельно нанятой командой индусов" как раз начал набирать обороты. Потому сделали совершенно новый WDDM, в котором отломали ускорение GDI, полноэкранную консоль сломали, и объявили курс на светлое будущее в виде Direct *D. А старые технологии развивать — это ведь не модно. Нужо больше баззвордов.
CS>Тебя обманули.
Всех обманули: https://www.neowin.net/forum/topic/1036369-did-you-know-all-gdi-apps-render-slower-under-win7/
V>>Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места).
CS>Слушай, прекращай уже фантазировать. Какой нахрен битмап в видеопамяти?
А в чем проблема? Мапим нужные физ страницы из видеопамяти в юзермодное АП и радуемся супер-быстрим блиттингам из невидимого битмапа в экранный. Ну и расстраиваемся медленным чтениям из битмапов.
https://blogs.msdn.microsoft.com/tmulcahy/2009/02/11/windows-and-video-memory/ — особое внимание пунктику 6, в висте это разумеется сломали, в семерке немного починили, и все возрадовались — ура, нормальная ось.
Давно ведь известный метод маркетинга — не сможешь сделать лучше, сделай хуже, а потом исправь. Немножечко — чтоб остался задел на будущее.
CS>
Есть такая ф-я GDI AlphaBlend
И была лет 11 назад у меня задача сделать "затененную" копию экрана, ну примерно как сейчас с UACом делается, и кстати для примерно такой же цели, наверно МС у нас идею стырило, да не в этом суть. А суть в том что я заюзал тогда эту самую AlphaBlend и все было замечательно, пока QA не обнаружило, что на одной из систем в результате вместо затененной картинки получается какой-то трэш из сдвинутых строк. Путем локализации бага оказалось что виновата.. видюха (какая — уже не помню)!
Фикс был простой — накропать альфа бленд ручками, получив GetDIBits и просчитав все самому, то есть сделав тот самый CPU rendering. Оно работало сильно медленнее, если засекать фреймы-в-секунды, но на моей задаче это было непринципиально.
А мораль сей басни такова — не только BitBlt хардварно процессился, но еще и AlphaBlend. Дело было, кстати на ХР. Потом на том же железе интереса ради проверил на свежепоявившейся Висте — баг не воспроизводился.
Ну а то что альфабленд уже в те времена процессился хардварно на WS_EX_LAYERED окнах — это по моему и ежу понятно было. Причем работал и per-pixel блендинг, используя 4й канал битмапов. То есть в принципе техническая возможность допилить GDI чтобы BitBlt поддерживал блендинг, заданный в 4м канале битмапов, явно была, но сдвиг парадигмы разработки винды в сторону "каждую новую фичу пишем с нуля, отдельно нанятой командой индусов" как раз начал набирать обороты. Потому сделали совершенно новый WDDM, в котором отломали ускорение GDI, полноэкранную консоль сломали, и объявили курс на светлое будущее в виде Direct *D. А старые технологии развивать — это ведь не модно. Нужо больше баззвордов.
Re[32]: Еще
V>>Для абстракции HDC, полученной для поверхности DirectDraw, тоже выполнялось аппаратное ускорение.
CS>Тебя обманули.
Всех обманули: https://www.neowin.net/forum/topic/1036369-did-you-know-all-gdi-apps-render-slower-under-win7/
V>>Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места).
CS>Слушай, прекращай уже фантазировать. Какой нахрен битмап в видеопамяти?
А в чем проблема? Мапим нужные физ страницы из видеопамяти в юзермодное АП и радуемся супер-быстрим блиттингам из невидимого битмапа в экранный. Ну и расстраиваемся медленным чтениям из битмапов.
https://blogs.msdn.microsoft.com/tmulcahy/2009/02/11/windows-and-video-memory/ — особое внимание пунктику 6, в висте это разумеется сломали, в семерке немного починили, и все возрадовались — ура, нормальная ось.
Давно ведь известный метод маркетинга — не сможешь сделать лучше, сделай хуже, а потом исправь. Немножечко — чтоб остался задел на будущее.
CS>
И была лет 12 назад у меня задача сделать "затененную" копию экрана, ну примерно как сейчас с UACом делается, и кстати для примерно такой же цели, наверно МС у нас идею стырило, да не в этом суть. А суть в том что я заюзал тогда эту самую AlphaBlend и все было замечательно, пока QA не обнаружило, что на одной из систем в результате вместо затененной картинки получается какой-то трэш из сдвинутых строк. Путем локализации бага оказалось что виновата.. видюха (какая — уже не помню)!
Фикс был простой — накропать альфа бленд ручками, получив GetDIBits и просчитав все самому, то есть сделав тот самый CPU rendering. Оно работало сильно медленнее, если засекать фреймы-в-секунды, но на моей задаче это было непринципиально.
А мораль сей басни такова — не только BitBlt хардварно процессился, но еще и AlphaBlend. Дело было, кстати на ХР. Потом на том же железе интереса ради проверил на свежепоявившейся Висте — баг не воспроизводился.
Ну а то что альфабленд уже в те времена процессился хардварно на WS_EX_LAYERED окнах — это по моему и ежу понятно было. Причем работал и per-pixel блендинг, используя 4й канал битмапов. То есть в принципе техническая возможность допилить GDI чтобы BitBlt поддерживал блендинг, заданный в 4м канале битмапов, явно была, но сдвиг парадигмы разработки винды в сторону "каждую новую фичу пишем с нуля, отдельно нанятой командой индусов" как раз начал набирать обороты. Потому сделали совершенно новый WDDM, в котором отломали ускорение GDI, полноэкранную консоль сломали, и объявили курс на светлое будущее в виде Direct *D. А старые технологии развивать — это ведь не модно. Нужо больше баззвордов.
CS>Тебя обманули.
Всех обманули: https://www.neowin.net/forum/topic/1036369-did-you-know-all-gdi-apps-render-slower-under-win7/
V>>Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места).
CS>Слушай, прекращай уже фантазировать. Какой нахрен битмап в видеопамяти?
А в чем проблема? Мапим нужные физ страницы из видеопамяти в юзермодное АП и радуемся супер-быстрим блиттингам из невидимого битмапа в экранный. Ну и расстраиваемся медленным чтениям из битмапов.
https://blogs.msdn.microsoft.com/tmulcahy/2009/02/11/windows-and-video-memory/ — особое внимание пунктику 6, в висте это разумеется сломали, в семерке немного починили, и все возрадовались — ура, нормальная ось.
Давно ведь известный метод маркетинга — не сможешь сделать лучше, сделай хуже, а потом исправь. Немножечко — чтоб остался задел на будущее.
CS>
Есть такая ф-я GDI AlphaBlend
И была лет 12 назад у меня задача сделать "затененную" копию экрана, ну примерно как сейчас с UACом делается, и кстати для примерно такой же цели, наверно МС у нас идею стырило, да не в этом суть. А суть в том что я заюзал тогда эту самую AlphaBlend и все было замечательно, пока QA не обнаружило, что на одной из систем в результате вместо затененной картинки получается какой-то трэш из сдвинутых строк. Путем локализации бага оказалось что виновата.. видюха (какая — уже не помню)!
Фикс был простой — накропать альфа бленд ручками, получив GetDIBits и просчитав все самому, то есть сделав тот самый CPU rendering. Оно работало сильно медленнее, если засекать фреймы-в-секунды, но на моей задаче это было непринципиально.
А мораль сей басни такова — не только BitBlt хардварно процессился, но еще и AlphaBlend. Дело было, кстати на ХР. Потом на том же железе интереса ради проверил на свежепоявившейся Висте — баг не воспроизводился.
Ну а то что альфабленд уже в те времена процессился хардварно на WS_EX_LAYERED окнах — это по моему и ежу понятно было. Причем работал и per-pixel блендинг, используя 4й канал битмапов. То есть в принципе техническая возможность допилить GDI чтобы BitBlt поддерживал блендинг, заданный в 4м канале битмапов, явно была, но сдвиг парадигмы разработки винды в сторону "каждую новую фичу пишем с нуля, отдельно нанятой командой индусов" как раз начал набирать обороты. Потому сделали совершенно новый WDDM, в котором отломали ускорение GDI, полноэкранную консоль сломали, и объявили курс на светлое будущее в виде Direct *D. А старые технологии развивать — это ведь не модно. Нужо больше баззвордов.