На основании тестов и показаний профайлера выяснилось, что значительную часть времени уходившего на отрисовку занимает создание и уничтожение GDI-шрифтов.

Я добавил кеширование шрифтов при отрисовке так что теперь по идее отрисовка должна ускориться. Но есть одна проблема. На моей машине (и доступных рядом) тормозов небыло заметно и раньше. Так что если у кого есть под рукой медленная техника на которой установлен фрэймворк 2.0 бэта 2, скачайте последнюю версию редактора и погоняйте в релиз-версии без отладчика.

Особенно обращайте внимание на ощущения от отрисовки при изменении выделения, листании страниц, скролинге.

Если кому в лом компилировать проект, то здесь можно найти исполняемые файлы (zip ~70 кил.).

Здравствуйте, VladD2, Вы писали:

VD>На основании тестов и показаний профайлера выяснилось, что значительную часть времени уходившего на отрисовку занимает создание и уничтожение GDI-шрифтов.

VD>Я добавил кеширование шрифтов при отрисовке так что теперь по идее отрисовка должна ускориться. Но есть одна проблема. На моей машине (и доступных рядом) тормозов небыло заметно и раньше. Так что если у кого есть под рукой медленная техника на которой установлен фрэймворк 2.0 бэта 2, скачайте последнюю версию редактора и погоняйте в релиз-версии без отладчика.

VD>Особенно обращайте внимание на ощущения от отрисовки при изменении выделения, листании страниц, скролинге.

VD>Если кому в лом компилировать проект, то здесь можно найти исполняемые файлы (zip ~70 кил.).

Radeon 7000 Mobility 32M + Pentium 3M 1000 Mhz пойдет?

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Radeon 7000 Mobility 32M + Pentium 3M 1000 Mhz пойдет?

Radeon 7000 Mobility это слишком быстро. Но процессор самое оно. В общем, подойдет все. Если заметны явные торомоза, то хорошо бы програть редактор под профайлером.

Да, только при тестировании нужно выбирать какой-нить C#-файл с большим количеством меняющихся подсветок.

Здравствуйте, VladD2, Вы писали:

VD>Radeon 7000 Mobility это слишком быстро. Но процессор самое оно. В общем, подойдет все. Если заметны явные торомоза, то хорошо бы програть редактор под профайлером.

VD>Да, только при тестировании нужно выбирать какой-нить C#-файл с большим количеством меняющихся подсветок.


В общем проверил. Оказалось, что этот компьютер вообще очень страшно тормозит Одна винда минут десять запускалась..
Касательно текстов.. Создал файл на 300 с небольшим кил с длинными строчками (150-200 символов). Тестировал путем быстрого набора тарабарщины и быстрой прокрутки текста. Никаких тормозов видно не было. Для сравнения — редактор из беты2 на том же тексте тормозил ужасно (правда, в основном набор и вероятнее всего из-за автокомплита).
В общем респект.

Здравствуйте, VladD2, Вы писали:

VD>На основании тестов и показаний профайлера выяснилось, что значительную часть времени уходившего на отрисовку занимает создание и уничтожение GDI-шрифтов.

VD>Я добавил кеширование шрифтов при отрисовке так что теперь по идее отрисовка должна ускориться. Но есть одна проблема. На моей машине (и доступных рядом) тормозов небыло заметно и раньше. Так что если у кого есть под рукой медленная техника на которой установлен фрэймворк 2.0 бэта 2, скачайте последнюю версию редактора и погоняйте в релиз-версии без отладчика.

VD>Особенно обращайте внимание на ощущения от отрисовки при изменении выделения, листании страниц, скролинге.

VD>Если кому в лом компилировать проект, то здесь можно найти исполняемые файлы (zip ~70 кил.).

Влад, я погонял на Celeron900, 256Mb RAM, S3Savage3D 8Mb
Насчет встроенной графики я таки соврал У меня внешняя S3-шка но дико древняя.
Результаты: скроллинг, выделение, прокрутка и прочее работает, как часы (не тормозит вообще). Но! При наборе текста довольно заметная стабильная задержка после каждого символа. (при слепом десятипальцевом наборе картинка на экране на 2-5 символов отстает от того, что я реально набрал).
Такие дела.

ЗЫ: о, еще заметил. при выделении курсором (стрелки + шифт) курсор двигается с такой же точно задержкой

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Результаты: скроллинг, выделение, прокрутка и прочее работает, как часы (не тормозит вообще). Но! При наборе текста довольно заметная стабильная задержка после каждого символа. (при слепом десятипальцевом наборе картинка на экране на 2-5 символов отстает от того, что я реально набрал).
ЗХ>Такие дела.

ЗХ>ЗЫ: о, еще заметил. при выделении курсором (стрелки + шифт) курсор двигается с такой же точно задержкой

Там на тулбаре есть кнопочка с голубым шариком. Это отключение двойной биферизации. Попробуй ее выключить и повторить тесты. Видна при этом разница?

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Результаты: скроллинг, выделение, прокрутка и прочее работает, как часы (не тормозит вообще). Но! При наборе текста довольно заметная стабильная задержка после каждого символа. (при слепом десятипальцевом наборе картинка на экране на 2-5 символов отстает от того, что я реально набрал).
ЗХ>Такие дела.

ЗХ>ЗЫ: о, еще заметил. при выделении курсором (стрелки + шифт) курсор двигается с такой же точно задержкой

Да, спасибо за помощь.

Не мог бы ты скачать ДжетБрэйновский профайлер (отсюда -~ 8 метров) и поглядеть под ним какая из функций у тебя тормозит? Там есть такой режим Hotspot. В нем сразу видны медленные функции. Профайлер нужно активировать уже после запуска из под него редактора (так чтобы он измерял только отрисовку). После активации нужно поделать те действия которые прводят к тормозам и сразу после это нажать "Get snapshot". Готорый снэпшот нужно сохранить как файл и отослать мне на мыло.

И... попробуй уменьшить окно. Уменьшаются ли при этом тормоза при вводе?


Буду очень признателен.

Здравствуйте, VladD2, Вы писали:

Ой... Я кажется первый раз в жизни получил цифровую оценку от Влада

VD>Там на тулбаре есть кнопочка с голубым шариком. Это отключение двойной биферизации. Попробуй ее выключить и повторить тесты. Видна при этом разница?

Колоссальная. Выключил — теперь все летает зверски

Здравствуйте, VladD2, Вы писали:

ЗХ>>Результаты: скроллинг, выделение, прокрутка и прочее работает, как часы (не тормозит вообще). Но! При наборе текста довольно заметная стабильная задержка после каждого символа. (при слепом десятипальцевом наборе картинка на экране на 2-5 символов отстает от того, что я реально набрал).
ЗХ>>Такие дела.

ЗХ>>ЗЫ: о, еще заметил. при выделении курсором (стрелки + шифт) курсор двигается с такой же точно задержкой

VD>Да, спасибо за помощь.

VD>Не мог бы ты скачать ДжетБрэйновский профайлер (отсюда -~ 8 метров) и поглядеть под ним какая из функций у тебя тормозит? Там есть такой режим Hotspot. В нем сразу видны медленные функции. Профайлер нужно активировать уже после запуска из под него редактора (так чтобы он измерял только отрисовку). После активации нужно поделать те действия которые прводят к тормозам и сразу после это нажать "Get snapshot". Готорый снэпшот нужно сохранить как файл и отослать мне на мыло.

VD>И... попробуй уменьшить окно. Уменьшаются ли при этом тормоза при вводе?

Сделаю, но ночью. Сейчас я спать иду.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Ой... Я кажется первый раз в жизни получил цифровую оценку от Влада

Вроде бы не первый.

ЗХ>Колоссальная. Выключил — теперь все летает зверски

Ясно, значит все же твоя видиокарта не тянет полноэкранное сглаживаение. Такая же фигня на встроенных в чипсет картах . Для них прийдется этот режим отключать.
К сожалению при этом переодически наблюдается мерцание. И это при том, что отрисовка "бесшовная", т.е. нет перекрывающихся частей изображения. Видимо сама функция вывода тектса рисует изображение в два прохода.

А как на глаз? Я так понимю, ты пишешь вслепую и должен замечать артифакты.

ЗЫ

Поясню ситуацию. При малейшем изменении происходит перерисовка всего контрола. Это позволяет избежать моря кода связанного с оптимизацией процесса отрисовки. Вроде как современные видеокарты легко выдерживают даже самые суровые режимы со сглаживаеним и проблем быть не должно. Но фрэймворк, зараза, запускается и на куда более древнем и слабом железе. Вот я и беспокоюсь как бы не было проблем.

Со временем хочется заменить в Янусе и R#-е Сцинтилу на Rsdn.Editor. И нужно сделать так, чтобы у основной массы пользователей не возникло дискомфорта. Ну, да если на этом ноуте Янус уже запускать тяжело, то значит, что сам редактор уже имеет требования ниже чем Янус и проблем быть недолжно. Вопрос только в том как это дело поведет себя на встроенной графике.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Сделаю, но ночью. Сейчас я спать иду.

Если при выключении двойной буферизации скорость становится нормальной, то и так все ясно. Дело именно в ней. Так что профайлинг тут бесполезен.

Здравствуйте, VladD2, Вы писали:

VD>К сожалению при этом переодически наблюдается мерцание. И это при том, что отрисовка "бесшовная", т.е. нет перекрывающихся частей изображения. Видимо сама функция вывода тектса рисует изображение в два прохода.

VD>А как на глаз? Я так понимю, ты пишешь вслепую и должен замечать артифакты.

Вроде бы прилично. Т.е. легкое мерцание иногда заметно, но именно "легкое иногда".
Даже при установленном мелком шрифте (Lucida Console, 8pt — шрифт очень склонен ко всяческим мелким артефактам) — все вполне прилично смотрится.

Правда, стартует редактор очень тяжело. Как Боинг, примерно.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>>Сделаю, но ночью. Сейчас я спать иду.

VD>Если при выключении двойной буферизации скорость становится нормальной, то и так все ясно. Дело именно в ней. Так что профайлинг тут бесполезен.

Ок.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Вроде бы прилично. Т.е. легкое мерцание иногда заметно, но именно "легкое иногда".

Видимо играет роль инертность ноутбучной матрицы.

ЗХ>Даже при установленном мелком шрифте (Lucida Console, 8pt — шрифт очень склонен ко всяческим мелким артефактам) — все вполне прилично смотрится.

Это хорошо.

ЗХ>Правда, стартует редактор очень тяжело. Как Боинг, примерно.

Дык джит и другие компонентности. Попробуй прогнать ngen.exe для сборки и экзешника. Скорость загрузки должна возрасти.

Ну, да не думаю, что в Янусе подгрузка редактора будет сильно заметна.

На Celeron 1.7 GeForce4 MX 440 довольно все быстро и никаких замечаний по скорости и с doublle buffering и без нее.

Только после произвольных нажатий:

VD>Особенно обращайте внимание на ощущения от отрисовки при изменении выделения, листании страниц, скролинге.

Погонял дома на АтлонXP-2500, видео ATI-9200. Открывал "разобранный" System.Windows.Forms.Control.cs. Размер около 15 тысяч строк. При листании и скролинге никаких проблем. Переключение буфера тоже никак не повлияло. Единственная проблема это когда при включенном переносе строк уменьшенное окно максимизизуешь и вновь восстанавливаешь. Очень тормозит. Визуально видно как окно сначал меняет координаты и перепозициониуется в верхний левый угол, а потом увеличивает размеры. Если отключить перенос строк то все ок.

На следующей неделе постараюсь найти на работе машину послабее и погонять.

Здравствуйте, <Аноним>, Вы писали:

А>Только после произвольных нажатий:
...

А как это дело воспроизвести?

Здравствуйте, Andre, Вы писали:

A>Погонял дома на АтлонXP-2500, видео ATI-9200. Открывал "разобранный" System.Windows.Forms.Control.cs. Размер около 15 тысяч строк. При листании и скролинге никаких проблем. Переключение буфера тоже никак не повлияло. Единственная проблема это когда при включенном переносе строк уменьшенное окно максимизизуешь и вновь восстанавливаешь. Очень тормозит. Визуально видно как окно сначал меняет координаты и перепозициониуется в верхний левый угол, а потом увеличивает размеры. Если отключить перенос строк то все ок.

Дык 15К строк это уже серьезный документ. Он где угодно будет тормозить. В более старых редакторах вроде Сцентилы сделан фоновый перенос строк, т.е. перенос строк производится в отдельном потоке и если вэто время происходит еще одно изменение размеров просто грубо прирывается и начинается занова. Быстрее от этого не становится, но визуально (и тактильно) человек ущущает тормоза значтельно меньше. Я знаю об этом эффектне, но не думаю, что стоит заниматься решениями вроде тех что приняты в Сцентиле. Ведь файлы такого размера редактируются крйне редка и уж точно можено прежить, что изменение размеров окна при этом подторможивает. Я лично тестировал редактор на файле размером в ~120 тысяч строк. При этом трмоза еще большие и видны очень хорошо, но жить можно. Редактирование же и скролинг сделаны так, что на них размеры (в размуных пределах конечно) файла не влияют.

В общем, у этой задачи приоритет наинизший. Если я не прав, то переубеждайте.

A>На следующей неделе постараюсь найти на работе машину послабее и погонять.

Особо интересует техника со встроенной графикой. Причем не обязательно с дохлым прцессором. Он вданном случае играет не самую важную роль.

Здравствуйте, VladD2, Вы писали:

VD>На основании тестов и показаний профайлера выяснилось, что значительную часть времени уходившего на отрисовку занимает создание и уничтожение GDI-шрифтов.
Подтвердилось?

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

Здравствуйте, orangy, Вы писали:

O>Здравствуйте, VladD2, Вы писали:

VD>>На основании тестов и показаний профайлера выяснилось, что значительную часть времени уходившего на отрисовку занимает создание и уничтожение GDI-шрифтов.
O>Подтвердилось?

Да, вроде как. Я, правда, разницы не ощущаю, но профайлер больше пальцем не тычит. Рекцию народа ты видишь. Правда, никого со встроенной графикой так и не откликнулось. АВК вроде смотрел, но ответ не внятны. Вроде как все ОК.

O>Столкнулся с аналогичной проблемой — в условиях отжирания процессом памяти, примерно равной половине физической памяти, отрисовка начинает ужасно тормозить. Причем, в основном, на встроенных и дохлых видеокартах. Столкнулись вчера, а сегодня мне подсказали, что ты про это что-то писал. Подскажешь, куда копать кроме профилера?

А профайлер то чем не устраивает?

Ну, да могу только поделиться тем как отрисовываюсь я.

Принцип очень простой.
1. Для вывода текста используется API-ый TextOut (вроде как асмая быстрая функция).
2. Для подсчетов размеров и других вычислений связанных с размерами текста использую специальный класс FontHelper. Он кэширует размеры символов в специально разработанной для этого структуре ускоряя подсчет размеров строк.
3. Функции оборачивающие вывод текста помещены в специальный класс который кэширует хэндлы шрифтов при первом использовании и использует для дальнейшей отрисовки уже кэшированные хэндлы. Удаление хэндлов производится п конце отрисовки (по Dispse-у).
4. Использование GDI+ свеедно к минимуму. Для отрисовки картинок используются функци ImagrList-а, которые (вроде бы) используют банальные GDI-шные функции.

Сейчас, вроде как, самым медлыенным участом отрисовки является закраска пустых фоновых поврхностей которая проивзодится через GDI+.

Эксперементы показали, что GDI+ вроде как кэширует ширфты, но при этом у него есть нехилвые дополнительные затраты во время отрисовки. В принципе более-менее примлемой скорости можно добиться и на GDI+, но GDI-вариант завсегда выходит быстрее. Вот только нужно кэшировать шрифты. Иначе вместо выигрыша даже проигрывашь, так как пересоздание ширфтов (при частом их использовании) занимает даже больше времени чем использование неповоротлиового GDI+.

Здравствуйте, VladD2, Вы писали:

VD>Сейчас, вроде как, самым медлыенным участом отрисовки является закраска пустых фоновых поврхностей которая проивзодится через GDI+.

А если и их TextOut'ом делать, типа так:

    void FillSolidRect(HDC hdc, LPCRECT lpRect, COLORREF clr)
    {
        ::SetBkColor(hdc, clr);
        ::ExtTextOut(hdc, 0, 0, ETO_OPAQUE, lpRect, NULL, 0, NULL);
    }

Здравствуйте, Блудов Павел, Вы писали:

БП>А если и их TextOut'ом делать, типа так:

БП>

БП>    void FillSolidRect(HDC hdc, LPCRECT lpRect, COLORREF clr)
БП>    {
БП>        ::SetBkColor(hdc, clr);
БП>        ::ExtTextOut(hdc, 0, 0, ETO_OPAQUE, lpRect, NULL, 0, NULL);
БП>    }
БП>

То будет быстро. Но:
1. Будут проблемы в 256 и 16 цветах. Хотя на сегодня этот аргумент конечно можно засунуть куда подальше.
2. Это ведь надо делать. А скорости вроде и так достаточно.

Здравствуйте, VladD2, Вы писали:

VD>1. Будут проблемы в 256 и 16 цветах. Хотя на сегодня этот аргумент конечно можно засунуть куда подальше.
Откуда? Ведь сам текст выводится через тот же TextOut, с тем же BackColor. Наоборот, должно убавиться проблем, если пустые области закрашивать через GDI

VD>2. Это ведь надо делать. А скорости вроде и так достаточно.
Так вроде готово. Закинул с нимимумом комментариев.

Здравствуйте, Блудов Павел, Вы писали:

БП>Откуда? Ведь сам текст выводится через тот же TextOut, с тем же BackColor. Наоборот, должно убавиться проблем, если пустые области закрашивать через GDI

Понимашь ли. Я не не делаю предположений по этому поводу. Я точно знаю, так как применял этот способ во времена когда 256 цветов были распространенным явлением.

При выводе текста с помощью TextOutEx фон самого текста выводится дизирингом, а свободные части закрашиваются ближайшим чистым цветом.

VD>>2. Это ведь надо делать. А скорости вроде и так достаточно.
БП>Так вроде готово. Закинул с нимимумом комментариев.

В смысле? Ты уже исправил код? Поглядим...

Хотя надо было бы сделать для начала варинт на #if-ах, чтобы сравнить производительность.

Здравствуйте, VladD2, Вы писали:

VD>Понимашь ли. Я не не делаю предположений по этому поводу. Я точно знаю, так как применял этот способ во времена когда 256 цветов были распространенным явлением.
Только что проверил на всех компах в конторе включая Virtual PC и терминалку. Всюду выводится совершенно одинаково.
Может, в твоём случает имеет место чисто драйверная проблема?

VD>При выводе текста с помощью TextOutEx фон самого текста выводится дизирингом, а свободные части закрашиваются ближайшим чистым цветом.
А как выглядят пробелы в тексте? Они же тоже выводятся через ExtTextOut.

Здравствуйте, Блудов Павел, Вы писали:

БП>Только что проверил на всех компах в конторе включая Virtual PC и терминалку. Всюду выводится совершенно одинаково.

А как проверял? Там весь смысл чтобы цвет фона был каким-нибудь не чистым. Например сделать его салатовым, но так чтобы этот салатовый явно отличался от любого из 16 стандартных цветов.

БП>Может, в твоём случает имеет место чисто драйверная проблема?

Врад ли. Единственное что... это было на на ХРюше. Но в VMWare где крутится ХРюша в 256 цветах в одном из моих 16-битных приложений я такой эффект постоянно наблюдаю.

БП>А как выглядят пробелы в тексте? Они же тоже выводятся через ExtTextOut.

Я же говорю, фон вокруг текста закрашивается немного отличающимся цветом.

Кстати, 256 цветов я могу добиться только запуском 16-битного приложения. Без него у меня минимальных режим 16-бит, т.е. хай-колор.