.NET DrawString () различное расположение текста при изменении масштаба графики - PullRequest
Новая
       30

.NET DrawString () различное расположение текста при изменении масштаба графики

0 голосов
/ 17 августа 2011

Я использую простой код для рисования текста внутри указанного прямоугольника.Все работает нормально, за исключением того, что иногда расположение текста отличается в зависимости от масштаба графики (устанавливается с помощью метода Graphics.ScaleTransform).

Трудно описать проблему словами, поэтому посмотрите на пример image

  1. ScaleTransform установлен на что-то около 0,3 - текст помещается в одну строку в пределах указанного прямоугольника.
  2. ScaleTransform установлен на что-то около 0,6 - текст переносится перед последним словом.

В обоих случаях это один и тот же шрифт, текст, прямоугольник макета, StringFormatting и так далее.Единственное, что меняется, это масштаб.Обратите внимание, что я не использую «масштабирование шрифтов»!В обоих случаях это даже один и тот же объект шрифта.Не задано значение StringFormatFlags.

Как это исправить?Мне все равно, будет ли текст обернут или нет - мне просто нужна последовательность.Всегда завернутый или нет, независимо от масштаба.Как это сделать?

1 Ответ

2 голосов
/ 11 апреля 2012

Благодаря подсказкам от Ганса, возможное решение состоит в том, чтобы установить Graphics.TextRenderingHint в SingleBitPerPixel или SingleBitPerPixelGridFit - это помогает, и визуализированный текст всегда выглядит как первый. Но антиалиасинга нет, и текст выглядит некрасиво (как во втором примере).

К сожалению, это не решает мою проблему, потому что текст позже конвертируется в GraphicsPath, и результат всегда похож на второй, показанный на примере изображения. Однако есть альтернативное решение этой проблемы: сначала преобразовать текст в GraphicsPath, а затем нарисовать его.

Однако возможны некоторые проблемы:

  1. Убедитесь, что GraphicsPath обновляется только при изменении текста, поэтому общие накладные расходы будут минимальными.
  2. Имейте в виду, что накладные расходы резко возрастут во время изменение текста - но это важно, только если вы постоянно отображаете текст во время пользователя ввод, как в приложении WYSIWYG. GraphicsPath должно быть воссоздается при каждом нажатии клавиши во время ввода текста. Это может быть узкое место серьезной производительности. Убедитесь, что вы проверяете на цель Конфигурация зависит от вашего пробега.
  3. Graphics.SmoothingMode необходимо установить на AntiAlias (или HighQuality что то же самое), чтобы получить плавные кривые - еще одна вещь, которая может повлиять на производительность.

Самое интересное, что решение с текстом, преобразованным в GraphicsPath, превосходит традиционный метод Graphics.DrawString. Также обратите внимание, что сам шрифт является важным фактором - более сложные шрифты с причудливыми буквами использует больше точек кривой, следовательно, им нужно больше процессорного времени для рисования.

Во время моих тестов я заметил заметное замедление, когда строки были длиннее нескольких тысяч символов (i5 760 CPU, только один большой GraphicsPath для рисования)

...