Сообщение Re[32]: Еще от 11.06.2017 9:49
Изменено 11.06.2017 10:04 vdimas
Re[32]: Еще
Здравствуйте, c-smile, Вы писали:
V>>Для абстракции HDC, полученной для поверхности DirectDraw, тоже выполнялось аппаратное ускорение.
CS>Тебя обманули.
CS>
Ой как некрасиво резать по цитатам:
Надо было называть конкретные карточки, которые не ускоряли "большинство GDI команд" в пользу 3D-акселерации. При том, что мне одно время приходилось поддерживать довольно-таки приличный парк машин для оптовой конторы в конце 90-х, ни на одной не стояло видеокарточки, нацеленной именно на 3D.
В общем, в нашей реальности рисование прямоугольников и линий сплошным цветом выполнялось графическим ускорителем еще со времён Win98. А со времён WinXP практически поголовно происходило ускорение так же процедур рисования растровой кистью.
Собсно, да какие проблемы? Этот ускоритель можно было отключить и наблюдать на машинах того времени артефакты медленной прорисовки — мелькающие черные квадратики.
Эта разница тогда была слишком заметна даже для обычного UI (не надо было даже 3D), чтобы сейчас можно было так громко утверждать, что ускорения не было. ))
V>>Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места).
CS>Слушай, прекращай уже фантазировать. Какой нахрен битмап в видеопамяти?
Самый что ни на есть обычный битмап в обычной видеопамяти.
CS>Для примера: для того чтобы TextOut работала и выводила ClearType ей нужен доступ к background pixels.
Это только в случае BkMode=TRANSPARENT. Но все стандартные контролы, т.е. вообще все, рисуют при установленном явно BkColor и BkMode=OPAQUE. Т.е. цвет заднего фона задан явно, никакого доступа к задним пикселям не надо.
CS>Ты предлагаешь сначала тот background закинуть в видео память потом оттуда его же читать и писать попиксельно?
CS>Ну нет конечно.
Не, это просто праздник какой-то сегодня!
До Win7 ты вообще рисовал ПРЯМО в видеопамять.
То бишь, когда ты получал HDC текущего окна для прорисовки, ты получал DC над экранным буфером видеопамяти.
Причем, доступ к отображаемому в данный момент видеобуферу — он на тех карточках всегда был более медленный, чем к заднему буферу.
В Висте/Win7 и выше ты больше не пишешь прямо в экранный буфер, поэтому, когда ты растягиваешь окно, то опять появляются артефакты — черные или белые "пустые" области, пока приложение там прорисует в свой буфер.
V>>ID2DRenderingTarget — это абстракция некоего интерфейса, наподобие HDC.
V>>Ну разве что АПИ оформлено не в процедурном стиле, а в стиле COM.
CS>Да при чем там API?
Потому что разный вид АПИ тебя путает, вестимо.
CS>Просто для управления временем жизни и версионностью этих ресурсов удобно использовать готовую идею IUnknown.
А вот остальное ты зря скипнул. ))
Да, GDI многое делает "само", "под капотом", а в DirectDraw ты можешь явно просить у объекта IsLost — то бишь, памяти не хватило и некий буфер (Surface) был насильно освобождён. В случае же GDI этот буфер может молча переехать в обычную память, а ты и знать не будешь. Или сразу будет создан в обычной памяти — а ты тоже знать не будешь.
Вот и всей разницы, собсно. Остальные принципиальные отличия я указал в пред.сообщении.
V>>Для абстракции HDC, полученной для поверхности DirectDraw, тоже выполнялось аппаратное ускорение.
CS>Тебя обманули.
CS>
Ой как некрасиво резать по цитатам:
При том, что и здесь в целом неверно.When the GDI DDI was first defined, most display acceleration hardware targeted the GDI primitives. Over time, more and more emphasis was placed on 3D game acceleration and less on application acceleration. As a consequence the BitBlt API was hardware accelerated and most other GDI operations were not.
Надо было называть конкретные карточки, которые не ускоряли "большинство GDI команд" в пользу 3D-акселерации. При том, что мне одно время приходилось поддерживать довольно-таки приличный парк машин для оптовой конторы в конце 90-х, ни на одной не стояло видеокарточки, нацеленной именно на 3D.
В общем, в нашей реальности рисование прямоугольников и линий сплошным цветом выполнялось графическим ускорителем еще со времён Win98. А со времён WinXP практически поголовно происходило ускорение так же процедур рисования растровой кистью.
Собсно, да какие проблемы? Этот ускоритель можно было отключить и наблюдать на машинах того времени артефакты медленной прорисовки — мелькающие черные квадратики.
Эта разница тогда была слишком заметна даже для обычного UI (не надо было даже 3D), чтобы сейчас можно было так громко утверждать, что ускорения не было. ))V>>Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места).
CS>Слушай, прекращай уже фантазировать. Какой нахрен битмап в видеопамяти?
Самый что ни на есть обычный битмап в обычной видеопамяти.
CS>Для примера: для того чтобы TextOut работала и выводила ClearType ей нужен доступ к background pixels.
Это только в случае BkMode=TRANSPARENT. Но все стандартные контролы, т.е. вообще все, рисуют при установленном явно BkColor и BkMode=OPAQUE. Т.е. цвет заднего фона задан явно, никакого доступа к задним пикселям не надо.
CS>Ты предлагаешь сначала тот background закинуть в видео память потом оттуда его же читать и писать попиксельно?
CS>Ну нет конечно.
Не, это просто праздник какой-то сегодня!
До Win7 ты вообще рисовал ПРЯМО в видеопамять.
То бишь, когда ты получал HDC текущего окна для прорисовки, ты получал DC над экранным буфером видеопамяти.
Причем, доступ к отображаемому в данный момент видеобуферу — он на тех карточках всегда был более медленный, чем к заднему буферу.
В Висте/Win7 и выше ты больше не пишешь прямо в экранный буфер, поэтому, когда ты растягиваешь окно, то опять появляются артефакты — черные или белые "пустые" области, пока приложение там прорисует в свой буфер.
(это цитата из времён, когда Win7 была старшей текущей операционкой)GDI functions for blitting operations only are hardware accelerated on Windows 7 exclusively
V>>ID2DRenderingTarget — это абстракция некоего интерфейса, наподобие HDC.
V>>Ну разве что АПИ оформлено не в процедурном стиле, а в стиле COM.
CS>Да при чем там API?
Потому что разный вид АПИ тебя путает, вестимо.
CS>Просто для управления временем жизни и версионностью этих ресурсов удобно использовать готовую идею IUnknown.
А вот остальное ты зря скипнул. ))
Да, GDI многое делает "само", "под капотом", а в DirectDraw ты можешь явно просить у объекта IsLost — то бишь, памяти не хватило и некий буфер (Surface) был насильно освобождён. В случае же GDI этот буфер может молча переехать в обычную память, а ты и знать не будешь. Или сразу будет создан в обычной памяти — а ты тоже знать не будешь.
Вот и всей разницы, собсно. Остальные принципиальные отличия я указал в пред.сообщении.
Re[32]: Еще
Здравствуйте, c-smile, Вы писали:
V>>Для абстракции HDC, полученной для поверхности DirectDraw, тоже выполнялось аппаратное ускорение.
CS>Тебя обманули.
CS>
Ой как некрасиво резать по цитатам:
Надо было называть конкретные карточки, которые не ускоряли "большинство GDI команд" в пользу 3D-акселерации. При том, что мне одно время приходилось поддерживать довольно-таки приличный парк машин для оптовой конторы в конце 90-х, ни на одной не стояло видеокарточки, нацеленной именно на 3D.
В общем, в нашей реальности рисование прямоугольников и линий сплошным цветом выполнялось графическим ускорителем еще со времён Win98. А со времён WinXP практически поголовно происходило ускорение так же процедур рисования растровой кистью.
Собсно, да какие проблемы? Этот ускоритель можно было отключить и наблюдать на машинах того времени артефакты медленной прорисовки — мелькающие черные квадратики. Эта разница тогда была слишком заметна даже для обычного UI (не надо было даже 3D), чтобы сейчас можно было так громко утверждать, что ускорения не было. ))
V>>Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места).
CS>Слушай, прекращай уже фантазировать. Какой нахрен битмап в видеопамяти?
Самый что ни на есть обычный битмап в обычной видеопамяти. Зачем, по-твоему, делали битмапу LockBits? Неужели до сих пор не разобрался? ))
Потому что доступ к видеопамяти исторически происходил через "окна" — некий участок адреса, предназначенный для основной памяти. Т.е. надо было сделать так, чтобы нужный участок видеопамяти достоверно был отображён на это "окно" (если битмап размещается в видеопамяти).
(В x64 этот момент уже стал неактуальным, кста, там идёт полное отбражение, без "окон").
CS>Для примера: для того чтобы TextOut работала и выводила ClearType ей нужен доступ к background pixels.
Это только в случае BkMode=TRANSPARENT. Но все стандартные контролы, т.е. вообще все, рисуют при установленном явно BkColor и BkMode=OPAQUE. Т.е. цвет заднего фона задан явно, никакого доступа к задним пикселям не надо.
CS>Ты предлагаешь сначала тот background закинуть в видео память потом оттуда его же читать и писать попиксельно?
CS>Ну нет конечно.
Не, это просто праздник какой-то сегодня!
До Win7 ты вообще рисовал ПРЯМО в видеопамять.
То бишь, когда ты получал HDC текущего окна для прорисовки, ты получал DC над экранным буфером видеопамяти.
Причем, доступ к отображаемому в данный момент видеобуферу — он на тех карточках всегда был более медленный, чем к заднему буферу.
В Висте/Win7 и выше ты больше не пишешь прямо в экранный буфер, поэтому, когда ты растягиваешь окно, то опять появляются артефакты — черные или белые "пустые" области, пока приложение там прорисует в свой буфер.
V>>ID2DRenderingTarget — это абстракция некоего интерфейса, наподобие HDC.
V>>Ну разве что АПИ оформлено не в процедурном стиле, а в стиле COM.
CS>Да при чем там API?
Потому что разный вид АПИ тебя путает, вестимо.
CS>Просто для управления временем жизни и версионностью этих ресурсов удобно использовать готовую идею IUnknown.
А вот остальное ты зря скипнул. ))
Да, GDI многое делает "само", "под капотом", а в DirectDraw ты можешь явно просить у объекта IsLost — то бишь, памяти не хватило и некий буфер (Surface) был насильно освобождён. В случае же GDI этот буфер может молча переехать в обычную память, а ты и знать не будешь. Или сразу будет создан в обычной памяти — а ты тоже знать не будешь.
Вот и всей разницы, собсно. Остальные принципиальные отличия я указал в пред.сообщении.
V>>Для абстракции HDC, полученной для поверхности DirectDraw, тоже выполнялось аппаратное ускорение.
CS>Тебя обманули.
CS>
Ой как некрасиво резать по цитатам:
При том, что и здесь в целом неверно.When the GDI DDI was first defined, most display acceleration hardware targeted the GDI primitives. Over time, more and more emphasis was placed on 3D game acceleration and less on application acceleration. As a consequence the BitBlt API was hardware accelerated and most other GDI operations were not.
Надо было называть конкретные карточки, которые не ускоряли "большинство GDI команд" в пользу 3D-акселерации. При том, что мне одно время приходилось поддерживать довольно-таки приличный парк машин для оптовой конторы в конце 90-х, ни на одной не стояло видеокарточки, нацеленной именно на 3D.
В общем, в нашей реальности рисование прямоугольников и линий сплошным цветом выполнялось графическим ускорителем еще со времён Win98. А со времён WinXP практически поголовно происходило ускорение так же процедур рисования растровой кистью.
Собсно, да какие проблемы? Этот ускоритель можно было отключить и наблюдать на машинах того времени артефакты медленной прорисовки — мелькающие черные квадратики.
Эта разница тогда была слишком заметна даже для обычного UI (не надо было даже 3D), чтобы сейчас можно было так громко утверждать, что ускорения не было. ))V>>Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места).
CS>Слушай, прекращай уже фантазировать. Какой нахрен битмап в видеопамяти?
Самый что ни на есть обычный битмап в обычной видеопамяти. Зачем, по-твоему, делали битмапу LockBits? Неужели до сих пор не разобрался? ))
Потому что доступ к видеопамяти исторически происходил через "окна" — некий участок адреса, предназначенный для основной памяти. Т.е. надо было сделать так, чтобы нужный участок видеопамяти достоверно был отображён на это "окно" (если битмап размещается в видеопамяти).
(В x64 этот момент уже стал неактуальным, кста, там идёт полное отбражение, без "окон").
CS>Для примера: для того чтобы TextOut работала и выводила ClearType ей нужен доступ к background pixels.
Это только в случае BkMode=TRANSPARENT. Но все стандартные контролы, т.е. вообще все, рисуют при установленном явно BkColor и BkMode=OPAQUE. Т.е. цвет заднего фона задан явно, никакого доступа к задним пикселям не надо.
CS>Ты предлагаешь сначала тот background закинуть в видео память потом оттуда его же читать и писать попиксельно?
CS>Ну нет конечно.
Не, это просто праздник какой-то сегодня!
До Win7 ты вообще рисовал ПРЯМО в видеопамять.
То бишь, когда ты получал HDC текущего окна для прорисовки, ты получал DC над экранным буфером видеопамяти.
Причем, доступ к отображаемому в данный момент видеобуферу — он на тех карточках всегда был более медленный, чем к заднему буферу.
В Висте/Win7 и выше ты больше не пишешь прямо в экранный буфер, поэтому, когда ты растягиваешь окно, то опять появляются артефакты — черные или белые "пустые" области, пока приложение там прорисует в свой буфер.
(это цитата из времён, когда Win7 была старшей текущей операционкой)GDI functions for blitting operations only are hardware accelerated on Windows 7 exclusively
V>>ID2DRenderingTarget — это абстракция некоего интерфейса, наподобие HDC.
V>>Ну разве что АПИ оформлено не в процедурном стиле, а в стиле COM.
CS>Да при чем там API?
Потому что разный вид АПИ тебя путает, вестимо.
CS>Просто для управления временем жизни и версионностью этих ресурсов удобно использовать готовую идею IUnknown.
А вот остальное ты зря скипнул. ))
Да, GDI многое делает "само", "под капотом", а в DirectDraw ты можешь явно просить у объекта IsLost — то бишь, памяти не хватило и некий буфер (Surface) был насильно освобождён. В случае же GDI этот буфер может молча переехать в обычную память, а ты и знать не будешь. Или сразу будет создан в обычной памяти — а ты тоже знать не будешь.
Вот и всей разницы, собсно. Остальные принципиальные отличия я указал в пред.сообщении.