У меня через GDI+ рисуется порядка сотни прямоугольников с закругленными углами. Вот просто на глаз видно, как они медленно и печально появляются на экране. Произвел замер — время отрисовки колеблется от 50 мс до 250 мс. Это чудовищно долго. И не понятно, почему время отрисовки так скачет.
Здравствуйте, Marty, Вы писали:
M>У меня через GDI+ рисуется порядка сотни прямоугольников с закругленными углами. Вот просто на глаз видно, как они медленно и печально появляются на экране. Произвел замер — время отрисовки колеблется от 50 мс до 250 мс. Это чудовищно долго. И не понятно, почему время отрисовки так скачет.
M>Кто виноват и что делать?
Для начала отрисовать их без GDI+, просто через RoundRect. Может, дело не в GDI+
Здравствуйте, Pavel Dvorkin, Вы писали: M>>Кто виноват и что делать? PD>Для начала отрисовать их без GDI+, просто через RoundRect. Может, дело не в GDI+
На самом деле, у меня там не RoundRect'ы, а пути, которые я потом заполняю. Потому, что у меня фигуры могут быть не обязательно прямоугольники, а произвольные их слияния (буквой Г, например).
Интерфейс у меня написан для GDI и для GDI+, но простой GDI дуги закруглений неряшливо присует. Вот так выглядят тайминги отрисовки:
ЗЫ Хотел еще без закруглений тайминги померять, померял — для GDI — картина точно такая же — что есть дуги, что их нет, а GDI+ — так просто не проверить уже, потому что версия без закруглений всегда через GDI рисуется, надо уже в глубине ковыряться
ЗЫЫ SetSmoothingMode в GDI+ с различными режимами что-то никак не влияет ни на скорость, ни на качество отрисовки
Здравствуйте, Marty, Вы писали:
M>На самом деле, у меня там не RoundRect'ы, а пути, которые я потом заполняю. Потому, что у меня фигуры могут быть не обязательно прямоугольники, а произвольные их слияния (буквой Г, например). M>Интерфейс у меня написан для GDI и для GDI+, но простой GDI дуги закруглений неряшливо присует. Вот так выглядят тайминги отрисовки:
Тайминги отрисовки желательно получить более детально, то есть не просто DoPaint, а сколько времени на что внутри него уходит.
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>Интерфейс у меня написан для GDI и для GDI+, но простой GDI дуги закруглений неряшливо присует. Вот так выглядят тайминги отрисовки:
PD>Тайминги отрисовки желательно получить более детально, то есть не просто DoPaint, а сколько времени на что внутри него уходит.
Здравствуйте, Marty, Вы писали:
PD>>Тайминги отрисовки желательно получить более детально, то есть не просто DoPaint, а сколько времени на что внутри него уходит.
M>И как же это сделать простыми способами?
DoPaint твой ? Если да — замеряй время каждого обращения к GDI+ внутри него. Только аккуратно — не выводи тут же в файл
Здравствуйте, Pavel Dvorkin, Вы писали: PD>>>Тайминги отрисовки желательно получить более детально, то есть не просто DoPaint, а сколько времени на что внутри него уходит. M>>И как же это сделать простыми способами? PD>DoPaint твой ?
Мой
PD>Если да — замеряй время каждого обращения к GDI+ внутри него. Только аккуратно — не выводи тут же в файл
Здравствуйте, Marty, Вы писали:
PD>>Если да — замеряй время каждого обращения к GDI+ внутри него. Только аккуратно — не выводи тут же в файл
M>Я ж спрашивал про простые способы
А расставить в коде QueryPerfomanceCounter и отправлять в некий list так уж сложно ? Не сотни же там вызовов GDI+.
Суть простая — надо найти, какой именно вызов GDI+ тормозит. И нет ли в DoPaint чего-то помимо GDI+, что тормозит. В общем, кто виноват.
Картинка твоя не подходит. Там непонятно от чего % считается, не только рисование входит.
Здравствуйте, paradok, Вы писали:
P>Все правильно — gdi+ тормоз P>Переделывай на DirectX (OpenGL, Metal)
Тогда уж Direct2D или как его там. Мне помимо рисования буквы надо рисовать, как там с этим?
Изначально я просто на GDI делал, так как он весьма быстрый и неплохо мне знакомый. Но — сразу всё обернул в свой IDeviceContext интерфейс — чтобы потом, при необходимости линупса в кутю переделать только реализацию десятка методов рисования вместо переделки всей проги. Потом заметил, что дуги и сочленения с прямыми в GDI коряво смотряться. Сделать реализацию под GDI+ — было просто, а вот с совсем новыми для меня технологиями — боюсь провожусь долго. Так что пока так оставлю, бо можно обойтись таки простым GDI
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А расставить в коде QueryPerfomanceCounter и отправлять в некий list так уж сложно ? Не сотни же там вызовов GDI+.
Не то, чтобы так уж сложно, но таки и не слишком просто
PD>Суть простая — надо найти, какой именно вызов GDI+ тормозит. И нет ли в DoPaint чего-то помимо GDI+, что тормозит. В общем, кто виноват.
Да ничего такого — с GDI весь тот же код работает весьма шустро
PD>Картинка твоя не подходит. Там непонятно от чего % считается, не только рисование входит.
Я так понимаю, проценты от всего времени работы. То, что именно функции GDI входят в топчик, намекает, что сколько бы я не расставлял QueryPerfomanceCounter'ы, ничего особо хорошего я не поймаю
Здравствуйте, Нomunculus, Вы писали:
M>>Кто виноват и что делать?
Н>А у тебя они каждый кадр динамически меняются? если нет, то почему не отрисуешь статику сначала в битмапу, а потом уже битмапу рисовать?
Да, не каждый кадр, есть куда оптимизировать, но вот как первоначальное отображение происходит — несколько напрягает. Хотя, конечно, можно и при первоначальном отображение в memDC рисовать и перекидывать по быстрому, но я пока с оптимизациями вообще не заморачивался, руки ещё не дошли. Просто думал, может, можно как-то по-быстрому полечить GDI+
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, paradok, Вы писали:
P>>Все правильно — gdi+ тормоз P>>Переделывай на DirectX (OpenGL, Metal)
M>Тогда уж Direct2D или как его там. Мне помимо рисования буквы надо рисовать, как там с этим?
это надо в гейм-деве поспрашивать, так на первый взгляд в играх со шрифтами нет кризиса, надписи в играх все делают...
еще есть на ява скрипт — babylonjs.com
ТАМ WebGL надписи в демках выглядят прилично
Здравствуйте, paradok, Вы писали:
P>это надо в гейм-деве поспрашивать,
Да, это мысль
P>так на первый взгляд в играх со шрифтами нет кризиса, надписи в играх все делают...
Я давно не играл ни во что, кроме танчиков, но, имхо, в играх почти везде шрифты свои рисованные, рисуются как спрайты, и заточены под пару-тройку поддерживаемых языков
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, paradok, Вы писали:
P>>это надо в гейм-деве поспрашивать,
M>Да, это мысль
P>>так на первый взгляд в играх со шрифтами нет кризиса, надписи в играх все делают...
M>Я давно не играл ни во что, кроме танчиков, но, имхо, в играх почти везде шрифты свои рисованные, рисуются как спрайты, и заточены под пару-тройку поддерживаемых языков
вроде сейчас проблема решена, можно использовать масштабируемые шрифты из виндов — truetype
вот из хэлпа юнити
Для добавления шрифта в проект, нужно положить файл со шрифтом в папку Assets.
Unity автоматически определит и импортирует этот файл.
Поддерживаются следующие форматы шрифтов: TrueType Fonts (.ttf) и OpenType Fonts (.otf).
Здравствуйте, paradok, Вы писали:
P>вроде сейчас проблема решена, можно использовать масштабируемые шрифты из виндов — truetype P>вот из хэлпа юнити P>Для добавления шрифта в проект, нужно положить файл со шрифтом в папку Assets. P>Unity автоматически определит и импортирует этот файл. P>Поддерживаются следующие форматы шрифтов: TrueType Fonts (.ttf) и OpenType Fonts (.otf).
Мне такой гемор нафик не нужен, я хочу системные шрифты использовать
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>А расставить в коде QueryPerfomanceCounter и отправлять в некий list так уж сложно ? Не сотни же там вызовов GDI+.
M>Не то, чтобы так уж сложно, но таки и не слишком просто
Сдается мне, что за время, которое ты потратил на переписку здесь, ты вполне бы смог вставить десяток QueryPerfomanceCounter и list.add и один fwrite
PD>>Суть простая — надо найти, какой именно вызов GDI+ тормозит. И нет ли в DoPaint чего-то помимо GDI+, что тормозит. В общем, кто виноват.
M>Да ничего такого — с GDI весь тот же код работает весьма шустро
GDI+ во многом просто настройка над GDI, и в этой части не должен тормозить. Реально код GDI выполняется в kernel mode. Однако есть в GDI+ и свой код, и он выполняется в самом GDI+. Он содержит то, чего в GDI нет и делает что-то сам, ну а потом все же вызывает GDI. Вот что-то из этого, может, и тормозит.
M>Я так понимаю, проценты от всего времени работы. То, что именно функции GDI входят в топчик, намекает, что сколько бы я не расставлял QueryPerfomanceCounter'ы, ничего особо хорошего я не поймаю
Проценты от времени работы сейчас не интересны. Интересно лишь одно — какое было время при входе в DoPaint, потом после первого вызова чего-то из GDI+, потом после второго вызова и т.д. Все остальное пока к делу не относится.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, paradok, Вы писали:
P>>вроде сейчас проблема решена, можно использовать масштабируемые шрифты из виндов — truetype P>>вот из хэлпа юнити P>>Для добавления шрифта в проект, нужно положить файл со шрифтом в папку Assets. P>>Unity автоматически определит и импортирует этот файл. P>>Поддерживаются следующие форматы шрифтов: TrueType Fonts (.ttf) и OpenType Fonts (.otf).
M>Мне такой гемор нафик не нужен, я хочу системные шрифты использовать
так трутайп это и есть системные шрифты в виндах и они в виндах где-то в папке систем и лежат...
я немного програмил в юнити на C# и мне показалось очень комфортно и удобно да и бонус + кросс платформ просто гигантский на все что сейчас вообще есть.
Там не только 3Д но и 2Д есть. Плюс экспорт в один клик в ява-скрипт и запуск в любом браузере проекта на C# — ну то есть автомат перекомпиляции из C# в ява-скрипт,
работает весьма недурственно.
Вот еще сглаживание шрифтов и кривых из коробки — Swift
замечу еще что если много юзеров то системные шрифты не спасут,
всегда попадутся юзеры у которых системный набор отличается от набора на ПК виндовс у разраба (версия шрифта не та, не хватает начертаний, не хватает символов и тд и тп)
и будут очень странные и непонятные траблы (винда вместо сообщения что нет шрифта подставляет самый похожий по ее мнению молча),
так что встроить шрифт в проект не такая уж и плохая идея когда юзеров десятки тысяч из разных стран
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Сдается мне, что за время, которое ты потратил на переписку здесь, ты вполне бы смог вставить десяток QueryPerfomanceCounter и list.add и один fwrite
Проект компилится, я тут пишу
PD>Проценты от времени работы сейчас не интересны.
Почему?
Для GDI картинка сильно отличается
Скрытый текст
PD>Интересно лишь одно — какое было время при входе в DoPaint, потом после первого вызова чего-то из GDI+, потом после второго вызова и т.д. Все остальное пока к делу не относится.
Это если сравнить не с чем. А если те же алгоритмы отрисовки через GDI работают в 10 раз быстрее, то как бы становится понятно, кто там тормоз, не?
Здравствуйте, paradok, Вы писали:
M>>Мне такой гемор нафик не нужен, я хочу системные шрифты использовать
P>так трутайп это и есть системные шрифты в виндах и они в виндах где-то в папке систем и лежат...
Ну вот лежат себе и лежат, и я знать не хочу, где они лежат, пусть система мне хорошо сделает сама, чтобы я ничего никуда не подкладывал
P>я немного програмил в юнити на C# и мне показалось очень комфортно и удобно да и бонус + кросс платформ просто гигантский на все что сейчас вообще есть. P>Там не только 3Д но и 2Д есть. Плюс экспорт в один клик в ява-скрипт и запуск в любом браузере проекта на C# — ну то есть автомат перекомпиляции из C# в ява-скрипт, P>работает весьма недурственно.
P>Вот еще сглаживание шрифтов и кривых из коробки — Swift
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, paradok, Вы писали:
M>>>Мне такой гемор нафик не нужен, я хочу системные шрифты использовать
P>>так трутайп это и есть системные шрифты в виндах и они в виндах где-то в папке систем и лежат...
M>Ну вот лежат себе и лежат, и я знать не хочу, где они лежат, пусть система мне хорошо сделает сама, чтобы я ничего никуда не подкладывал
эту проблему при массовой проге избежать не получиться
если много юзеров то системные шрифты не спасут,
всегда попадутся юзеры у которых системный набор отличается от набора на ПК виндовс у разраба (версия шрифта не та, не хватает начертаний, не хватает символов и тд и тп)
и будут очень странные и непонятные траблы (винда вместо сообщения что нет шрифта подставляет самый похожий по ее мнению молча),
так что встроить шрифт в проект не такая уж и плохая идея когда юзеров десятки тысяч из разных стран
Здравствуйте, Marty, Вы писали:
M>Почему? M>Для GDI картинка сильно отличается
Потому что ничего не дает. Надо найти того, кто тормозит в DoPaint, а то, что что-то тормозит, было ясно после твоего первого сообщения с таймингами его на GDI и GDI+
PD>>Интересно лишь одно — какое было время при входе в DoPaint, потом после первого вызова чего-то из GDI+, потом после второго вызова и т.д. Все остальное пока к делу не относится.
M>Это если сравнить не с чем. А если те же алгоритмы отрисовки через GDI работают в 10 раз быстрее, то как бы становится понятно, кто там тормоз, не?
Нет. См. мое предыдущее сообщение. Там может тормозить какой-то метод из GDI+, который сам GDI+ и реализует.
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>Почему? M>>Для GDI картинка сильно отличается
PD>Потому что ничего не дает. Надо найти того, кто тормозит в DoPaint, а то, что что-то тормозит, было ясно после твоего первого сообщения с таймингами его на GDI и GDI+
Ну как же не даёт?
На первой картинке видно, что GdipDrawPath/GdipFillPath как вместе, так и по отдельности жрут CPU больше, чем GetMessageW, а на второй картинке видно, что StrokeAndFillPath жрёт в два раза меньше той же GetMessageW. Хочешь сказать, что это ни о чем?
M>>Это если сравнить не с чем. А если те же алгоритмы отрисовки через GDI работают в 10 раз быстрее, то как бы становится понятно, кто там тормоз, не?
PD>Нет. См. мое предыдущее сообщение. Там может тормозить какой-то метод из GDI+, который сам GDI+ и реализует.
Ну вот тормозят GdipDrawPath/GdipFillPath, и что делать?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А расставить в коде QueryPerfomanceCounter и отправлять в некий list так уж сложно ? Не сотни же там вызовов GDI+.
Ты застрял в прошлом веке. В 20м веке придумали профайлеры, но ещё мало использовали в 21 веке неумение пользоваться профайлером — или ретроградство или профнепригодность. Посмотри на dotTrace.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Marty, Вы писали:
M>Ну как же не даёт? M>На первой картинке видно, что GdipDrawPath/GdipFillPath как вместе, так и по отдельности жрут CPU больше, чем GetMessageW, а на второй картинке видно, что StrokeAndFillPath жрёт в два раза меньше той же GetMessageW. Хочешь сказать, что это ни о чем?
Конечно, ни о чем. Какое отношение к делу имеют функции, не относящиеся к отрисовке ? Ты бы еще со strcpy сравнил
Троллить ты, что ли, решился — так не тот форум.
M>Ну вот тормозят GdipDrawPath/GdipFillPath, и что делать?
Во-первых, убедиться, что это именно они. Пока что нет уверенности в этом. Они скорее всего просто оболочки для StrokePath/FillPath
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>GDI+ во многом просто настройка над GDI, и в этой части не должен тормозить. Реально код GDI выполняется в kernel mode.
Это уже давно не так.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Marty, Вы писали: M>Интерфейс у меня написан для GDI и для GDI+, но простой GDI дуги закруглений неряшливо присует.
Вот в этой фразе есть намек, что GDI просто фигачит пиксели одним цветом, без всякого сглаживания и антиалиасинга.
В GDI+ запросто может быть врукопашную какой-то антиалиасинг реализован, а это перемалывание пикселей через CPU.
Я в свое время что-то подобное сам реализовывал, чтобы из иконочных шрифтов генерировать иконки в формате ico с альфа-каналом.
Здравствуйте, Философ, Вы писали:
Ф>Ты застрял в прошлом веке. В 20м веке придумали профайлеры, но ещё мало использовали в 21 веке неумение пользоваться профайлером — или ретроградство или профнепригодность. Посмотри на dotTrace.
Да, профайлеры придумали в прошлом веке, и я именно тогда их и использовал. . Visual Studio 6.0 profiler. Хорошая была штука.
Но мой опыт говорит, что в ряде случаев лучше просто замерять в коде. Профайлер не может совсем уж не вмешиваться в профилируемый процесс, а кроме того, он все же рассчитан на некий общий универсальный код, а свои замеры я сделаю как хочу.
Здравствуйте, qaz77, Вы писали:
Q>Здравствуйте, Marty, Вы писали: M>>Интерфейс у меня написан для GDI и для GDI+, но простой GDI дуги закруглений неряшливо присует.
Q>Вот в этой фразе есть намек, что GDI просто фигачит пиксели одним цветом, без всякого сглаживания и антиалиасинга. Q>В GDI+ запросто может быть врукопашную какой-то антиалиасинг реализован, а это перемалывание пикселей через CPU.
Да, скорее всего именно так дело и обстоит, и похоже, что с этим ничего не сделать
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Конечно, ни о чем. Какое отношение к делу имеют функции, не относящиеся к отрисовке ? Ты бы еще со strcpy сравнил
Можно и со strcpy сравнить, в чем проблема?
PD>Троллить ты, что ли, решился — так не тот форум.
Нет, не "решился". Я совершенно искренне не понимаю, чем такой приблизительный способ оценки производительности не годится.
M>>Ну вот тормозят GdipDrawPath/GdipFillPath, и что делать?
PD>Во-первых, убедиться, что это именно они. Пока что нет уверенности в этом.
У меня — есть
PD>Они скорее всего просто оболочки для StrokePath/FillPath
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Но мой опыт говорит, что в ряде случаев лучше просто замерять в коде. Профайлер не может совсем уж не вмешиваться в профилируемый процесс, а кроме того, он все же рассчитан на некий общий универсальный код, а свои замеры я сделаю как хочу.
Вообще-то я тоже профилировал, и отрисовку в том числе. И мой опыт говорит о том, что QPC нужен когда код выполняется У ПОЛЬЗОВАТЕЛЯ, куда ты с профилировщиком и дебаггером не можешь подобраться. В остальных случаях это бесполезная трата времени.
Если что я писал собственные PerformanceCounter'ы. Но я писал их для того чтобы понять причину по которой ПОЛЬЗОВАТЕЛЬ не может данных дождаться, а на своём рабочем месте только профайлер, а QPC только для развлечения и "практики". Не стоит оно того, чтоб время на него тратить.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Вообще-то я тоже профилировал, и отрисовку в том числе. И мой опыт говорит о том, что QPC нужен когда код выполняется У ПОЛЬЗОВАТЕЛЯ, куда ты с профилировщиком и дебаггером не может подобраться. В остальных случаях это бесполезная трата времени. Ф>Если что я писал собственные PerformanceCounter'ы. Но я писал их для того чтобы понять причину по которой ПОЛЬЗОВАТЕЛЬ не может данных дождаться, а на своём рабочем месте только профайлер, а QPC только для развлечения и "практики". Не стоит оно того, чтоб время на него тратить.
Ну что касается времени, то тратить его практически не придется. Copy/paste несколько вызовов одного метода, а он все сделает, потому что написан давным-давно и изменения в нем не требуются.
Мне было так удобнее. Например, какой-то кусок проходить без тайминга — с ним и так понятно, что тут тормозов быть не может. Где-то детально, каждый кусочек кода, где-то только от-до и т.д. На мой взгляд это все же гибче. Но у каждого свое мнение и свои задачи, и не надо так уж категорично заявлять, что это бесполезная трата времени.
Здравствуйте, Философ, Вы писали:
PD>>GDI+ во многом просто настройка над GDI, и в этой части не должен тормозить. Реально код GDI выполняется в kernel mode.
Ф>Это уже давно не так.
Что именно не так ? Что код GDI выполняется в ядре ?
Здравствуйте, Философ, Вы писали:
PD>>Что именно не так ? Что код GDI выполняется в ядре ?
Ф>Угу. Его вроде ещё в 7-ке начали переносить. Потом с выходом эксплоитов для шрифтов ускорились (это времена Windows 8).
Хм. А можно какой-нибудь пруф ? Может, я и впрямь пропустил это ?
Пока что вижу только вот это. 2021 год, если что.
GDI is the intermediary support between a Microsoft Windows NT-based graphics driver and an application. Applications call Microsoft Win32 GDI functions to make graphics output requests. These requests are routed to kernel-mode GDI. Kernel-mode GDI then sends these requests to the appropriate graphics driver, such as a display driver or printer driver. Kernel-mode GDI is a system-supplied module that cannot be replaced.
Здравствуйте, Философ, Вы писали:
PD>>Что именно не так ? Что код GDI выполняется в ядре ?
Ф>Угу. Его вроде ещё в 7-ке начали переносить. Потом с выходом эксплоитов для шрифтов ускорились (это времена Windows 8).
По большому счету разве есть разница, в ядре или нет выполняется код?
Здравствуйте, Marty, Вы писали:
M>Просто думал, может, можно как-то по-быстрому полечить GDI+
Не полечится. GDI+ писался в спешке в ожидании новой эры почти-3D приложений поэтому об оптимизации тогда никто не думал, она отладывалась на потом, так как нужно было выкатить этот API вовремя.
Потом спустя 6 лет случился DWM, который все операции отрисовки DC делает на процессоре и только потом отсылает готовую сцену соотв. окна на видеокарту. Вышло так, что привычное аппаратное ускорение отрисовки DC не получилось воткнуть в эту новую схему вещей, поэтому аппаратное ускорение было выключено даже для обычного GDI начиная с Vista. За счет продолжающей расти мощности процессоров эти изьяны были не очень заметными, поэтому никто не напрягался. А GDI+ остался таким каким он был, чисто софтовым, не до него было.
Затем новая эпоха Microsoft с их попытками засунуть ОС в другие форм-факторы полностью затмила какие-либо работы по улучшению существуещих статус-кво. А теперь имеем то, что имеем — GDI и GDI+ покрытые пятнадцетилетней пылью, но еще кое-как работающие.
Если хотите преодолеть эти ограничения — нужно Direct 3D surface поднимать и рисовать прямоугольники там, отправляя batch job прямо на видеокарту.
The Windows 2000 Display Driver Model (XDDM) is the legacy display/graphics driver architecture that was used for Windows 2000 through Windows Vista and Windows 7.
Сейчас картина выглядит иначе:
Graphics hardware vendors must write user-mode display drivers for their display adapters. The user-mode display driver is a dynamic-link library (DLL) that is loaded by the Microsoft Direct3D runtime. A user-mode display driver must at least support the Direct3D version 9 DDI. User-mode display drivers can also support the Direct3D version 10 DDI. The user-mode display driver can consist of one DLL that supports both Direct3D version 9 DDI and Direct3D version 10 DDI or it can consist of two separate DLLs, one for version 9 and the other for version 10 of Direct3D DDI. The following topics discuss various aspects of the user-mode display driver:
Если смотреть что из себя представляет Win32k.sys то обнаруживается, что его функции не так просто найти, но таки можно, и там полностью отсутствует что-либо связанное с регионами, полигонами, брашами, карандашами и тем более шрифтами. Это говорит о том, что всё это теперь за пределами ядра.
Всё сказанное выше — личное мнение, если не указано обратное.
The Windows 2000 Display Driver Model (XDDM) is the legacy display/graphics driver architecture that was used for Windows 2000 through Windows Vista and Windows 7.
Да, тут ты прав.
Ф>Сейчас картина выглядит иначе:
А вот это для меня не новость. То, что есть user mode драйверы Direct3D и OpenGL — это я знаю. Но мы не о них говорим, а о GDI.
Ф>Если смотреть что из себя представляет Win32k.sys то обнаруживается, что его функции не так просто найти, но таки можно, и там полностью отсутствует что-либо связанное с регионами, полигонами, брашами, карандашами и тем более шрифтами. Это говорит о том, что всё это теперь за пределами ядра.
Ох, что-то не то.
То, что ты дал по ссылке — это результат какой-то grep для какой-то drsyscall. Естественно, там не все.
Ищем в Windows win32k.sys. У меня их FAR нашел 12 штук , в разных подкаталогах C:\Windows\WinSxS. Некоторые из них имеют размер в 300-400 байт, но есть и иного размера.
Честно говоря, не в курсе, какой из них действующий
Правда, есть там еще win32u.dll, и в ней тоже полно аналогичных экспортов. Увы, непонятно, для какого она режима — user mode или kernel mode — импорты ее dumpbin не показывает.
Но вот здесь сказано
win32u.dll is a link for System calls between User mode (Ring 3) and Kernel mode (Ring 0) : Ring 3 => Ring 0
Здравствуйте, Marty, Вы писали:
M>Здравствуйте!
M>У меня через GDI+ рисуется порядка сотни прямоугольников с закругленными углами. Вот просто на глаз видно, как они медленно и печально появляются на экране. Произвел замер — время отрисовки колеблется от 50 мс до 250 мс. Это чудовищно долго. И не понятно, почему время отрисовки так скачет.
M>Кто виноват и что делать?
У тебя вообще какая задача стоит, что ты взялся такие тесты делать?
btw, уроки по opengl от Neon Hlium: http://pmg.org.ru/nehe/ там есть и про шрифты. Я когда тестовые задания по opengl делал, текст выводил, проблем не было, сделал быстро, даже не помню, как.
Здравствуйте, Marty, Вы писали:
CEM>>У тебя вообще какая задача стоит, что ты взялся такие тесты делать?
M>Я не тесты делаю, я прогу делаю, а тут такое...
Ты там замеры делал, это тесты производительности
Вообще, если ты в GDI рисуешь, с двойной буферизацией, то оно работает довольно быстро, я на этом realtime игры делал.
Я про задачу почему спрашивал: если тебе прям надо плотно с 2D-графикой работать — лучше взять что-то более близкое к железу. SDL, может? Это оконный движок с openGL-ной графикой в основе. MS WPF — тоже на основе DirectX сделано. А GDI+ — медленный всегда был, он больше подходит, когда надо быстро(закодить) что-то небольшое нарисовать и лень разбираться. Я его использовал для закачки каких-то графических форматов, типа jpeg/tiff/png.
Здравствуйте, CEMb, Вы писали:
CEM>Вообще, если ты в GDI рисуешь, с двойной буферизацией, то оно работает довольно быстро, я на этом realtime игры делал.
Ну да, я как-то так и полагал. Но дуги корявые не понравились, решил попробовать GDI+, благо он весьма похож на GDI, а он тормозит.
CEM>Я про задачу почему спрашивал: если тебе прям надо плотно с 2D-графикой работать — лучше взять что-то более близкое к железу. SDL, может? Это оконный движок с openGL-ной графикой в основе. MS WPF — тоже на основе DirectX сделано. А GDI+ — медленный всегда был, он больше подходит, когда надо быстро(закодить) что-то небольшое нарисовать и лень разбираться. Я его использовал для закачки каких-то графических форматов, типа jpeg/tiff/png.
Плотно возможно потом понадобится, но пока это не в приоритете. Я GDI/GDI+ потому и взял, что оно мне знакомо и можно побыстрому закодить отрисовку. Иначе так бы и застрял на этапе осваивания нового графического API
Потом может переделаю, а пока просто буду замерять скорость отрисовки, и если что, говорить пользователю, что система у него медленная, и надо настройки графики поурезать
Здравствуйте, Marty, Вы писали:
M>У меня через GDI+ рисуется порядка сотни прямоугольников с закругленными углами. Вот просто на глаз видно, как они медленно и печально появляются на экране. Произвел замер — время отрисовки колеблется от 50 мс до 250 мс. Это чудовищно долго. И не понятно, почему время отрисовки так скачет.
GDI начиная с win7 для основных вещей имеет hw acceleration
GDI+ не имеет hw acceleration вообще.
D2D нужно юзать, или D3D
M>Кто виноват
Здравствуйте, rudzuk, Вы писали:
R>GDI далеко не с семерки аппаратно ускоренный, а сильно-сильно раньше.
только в висте его убили, а в вин7 частично вернули, поэтому GDI hw acceleration на XP и Win7 как бы отличаются,
так что юзать GDI для отрисовки сложных вещей начиная с висты противопоказано.
Здравствуйте, Marty, Вы писали:
M>У меня через GDI+ рисуется порядка сотни прямоугольников с закругленными углами. Вот просто на глаз видно, как они медленно и печально появляются на экране. Произвел замер — время отрисовки колеблется от 50 мс до 250 мс. Это чудовищно долго. И не понятно, почему время отрисовки так скачет.
За такое время можно скачать картинку по хттп и нарисовать её жээсом.
M>Кто виноват и что делать?
10 лет назад у меня .net. system.drawing который под капотом GDI+ уверенно рисовал порядка 10..15тыс примитивов в секунду.
Это если без шрифтов. Со шрифтами намного меньше.
Покажи, что именно ты рисуешь.
Проблемы с гди+ возможны, и в странных местах — например, если логические координаты слишком большие или когда часть рендеринга идет мимо видимой области. Лучше отключить всё такое, включая клиппинг, и делать это самому. Тогда сюрпризов меньше будет.
Для примера — если логическую область сделать в логических единицах от -50млн до +50млн, и попытаться нарисовать линию стилем dash от одного края, до другого не прямо, а наискосок, то рисование такой линии занимает секунды и линия может оказаться изогнутой на экране, т.е. пройдет совсем не там, куда бы она попала если стиль solid
Здравствуйте, Pauel, Вы писали:
M>>У меня через GDI+ рисуется порядка сотни прямоугольников с закругленными углами. Вот просто на глаз видно, как они медленно и печально появляются на экране. Произвел замер — время отрисовки колеблется от 50 мс до 250 мс. Это чудовищно долго. И не понятно, почему время отрисовки так скачет.
P>За такое время можно скачать картинку по хттп и нарисовать её жээсом.
Можно
P>10 лет назад у меня .net. system.drawing который под капотом GDI+ уверенно рисовал порядка 10..15тыс примитивов в секунду. P>Это если без шрифтов. Со шрифтами намного меньше.
P>Покажи, что именно ты рисуешь.
Вот такие штуки:
P>Проблемы с гди+ возможны, и в странных местах — например, если логические координаты слишком большие или когда часть рендеринга идет мимо видимой области. Лучше отключить всё такое, включая клиппинг, и делать это самому. Тогда сюрпризов меньше будет.
Всё только в пределах экрана
P>Для примера — если логическую область сделать в логических единицах от -50млн до +50млн, и попытаться нарисовать линию стилем dash от одного края, до другого не прямо, а наискосок, то рисование такой линии занимает секунды и линия может оказаться изогнутой на экране, т.е. пройдет совсем не там, куда бы она попала если стиль solid
Никаких дашей, и только горизонтальные/вертикальные прямые, дуги и заливка. Правда, рисую не как RoundRect'ы, а как Path'ы
Здравствуйте, Marty, Вы писали:
M>Никаких дашей, и только горизонтальные/вертикальные прямые, дуги и заливка. Правда, рисую не как RoundRect'ы, а как Path'ы
Здравствуйте, Pauel, Вы писали:
M>>Никаких дашей, и только горизонтальные/вертикальные прямые, дуги и заливка. Правда, рисую не как RoundRect'ы, а как Path'ы
P>А RoundRect насколько быстрый?
Я наврал. Просто прямоугольники с закругленными углами я как RoundRect'ы и рисую, посложнее фигуры — через Path'ы. Но таких у меня несколько штук от силы
Здравствуйте, Pauel, Вы писали:
P>>>А что именно тормозит — создание path, или его отрисовка в графический контекст?
M>>Отрисовка
P>А если все это вручную отрисовать, безо всякого path, как изменится перформанс?
А как быть с заливкой? Или ты предлагаешь самому попиксельно вообще все рисовать?
Здравствуйте, Marty, Вы писали:
P>>А если все это вручную отрисовать, безо всякого path, как изменится перформанс?
M>А как быть с заливкой? Или ты предлагаешь самому попиксельно вообще все рисовать?
Однако, про заливку я не знал. Кстати говоря, как изменится перформанс если отключить заливку ?
А ты не мог бы фрагмент картинки показать? Есть ли вариант, скажем, нарисовать несколько типовых картинок в битмап и уже потом шпокать этот битмап?
P>>Я имею ввиду весь результ или кусочек его. Одного элемента маловато, что бы суть происходящего понять. M>Ну вот как-то так M>Image: 2022_10_02_12_03_20_image.png
А если заливку отключить? Т.е. что по времени отъедает больше всего?
Здравствуйте, Pauel, Вы писали: M>>Ну вот как-то так M>>Image: 2022_10_02_12_03_20_image.png P>А если заливку отключить? Т.е. что по времени отъедает больше всего?
, то где-то раза в два-три побыстрее, но все равно в дцать раз медленнее обычного GDI
P>А если поиграться с настройками сглаживания? У меня шота не складывается пазл, какая то загадка у тебя. Работает как в конце 90х
Настройки сглаживания по идее только на границы должны влиять. Куда 2/3 времени при заливке уходят — не понятно. Ну и я пробовал играть — но то ли баг где-то у меня, то ли хз — но всякие антиальясинг опции для GDI+ ничего не меняют
, то где-то раза в два-три побыстрее, но все равно в дцать раз медленнее обычного GDI
P>А если поиграться с настройками сглаживания? У меня шота не складывается пазл, какая то загадка у тебя. Работает как в конце 90х
Ну, если что, у меня видяха хоть если и не из девяностых, то из начала десятых, low profile low power AMD какая-то. Меня устраивает в общем, я её уже в третий комп переставляю. Но если по текущему проекту, мне бы вообще хотелось, чтобы всё работало на любом древнем хламе
Здравствуйте, Marty, Вы писали:
M>Ну, если что, у меня видяха хоть если и не из девяностых, то из начала десятых, low profile low power AMD какая-то. Меня устраивает в общем, я её уже в третий комп переставляю. Но если по текущему проекту, мне бы вообще хотелось, чтобы всё работало на любом древнем хламе
А если тож самое отрендерить в битмап, как изменится перформанс? Это чтобы проверить, видяха виновата или нет.
Здравствуйте, Pauel, Вы писали:
M>>Ну, если что, у меня видяха хоть если и не из девяностых, то из начала десятых, low profile low power AMD какая-то. Меня устраивает в общем, я её уже в третий комп переставляю. Но если по текущему проекту, мне бы вообще хотелось, чтобы всё работало на любом древнем хламе
P>А если тож самое отрендерить в битмап, как изменится перформанс? Это чтобы проверить, видяха виновата или нет.
В битмап — это в MemoryDC? Там видяха не будет участвовать? Или как-то по другому?
Здравствуйте, Marty, Вы писали:
P>>А если тож самое отрендерить в битмап, как изменится перформанс? Это чтобы проверить, видяха виновата или нет.
M>В битмап — это в MemoryDC? Там видяха не будет участвовать? Или как-то по другому?
Наверное в меморидц, рисовать должен процессор, насколько я понимаю.
Здравствуйте, Pauel, Вы писали:
P>>>А если тож самое отрендерить в битмап, как изменится перформанс? Это чтобы проверить, видяха виновата или нет.
M>>В битмап — это в MemoryDC? Там видяха не будет участвовать? Или как-то по другому?
P>Наверное в меморидц, рисовать должен процессор, насколько я понимаю.
Ну, с одной стороны похоже на то, да, но с другой стороны это убивает напрочь идею двойной буферизации — отрисовка в бэк буфер не будет аппаратно ускоряться.
Хотя, почитал — вроде так. Странно. Раньше что-то не задумывался
Здравствуйте, Marty, Вы писали:
P>>Наверное в меморидц, рисовать должен процессор, насколько я понимаю.
M>Ну, с одной стороны похоже на то, да, но с другой стороны это убивает напрочь идею двойной буферизации — отрисовка в бэк буфер не будет аппаратно ускоряться.
Не убивает. Просто ты руками это будешь делать. Склеиваешь слои из битмапу и потом плюхаешь это в wm-paint.
Перформанс как изменится, если в через мемори рисовать?
Здравствуйте, Pauel, Вы писали:
M>>Ну, с одной стороны похоже на то, да, но с другой стороны это убивает напрочь идею двойной буферизации — отрисовка в бэк буфер не будет аппаратно ускоряться.
P>Не убивает. Просто ты руками это будешь делать. Склеиваешь слои из битмапу и потом плюхаешь это в wm-paint.
P>Перформанс как изменится, если в через мемори рисовать?
Ну, GDI+ то он вроде и так всё процессором рисует, а вот обычный GDI вроде использует аппаратное ускорение видяхи, когда на экран рисует
Здравствуйте, Marty, Вы писали:
M>Ну, GDI+ то он вроде и так всё процессором рисует, а вот обычный GDI вроде использует аппаратное ускорение видяхи, когда на экран рисует
Надо выяснить, поменяется ли перформанс. А он может поменяться в обе стороны.
