Здравствуйте, 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 прямо на видеокарту.
