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

Оптимизация 1:
Изменения в абзаце не сказываются на других абзацах, в частности на их высоте.

Оптимизация 2:
Изменение в тексте не затрагивают текст выше.

Наблюдение:
RichEdit как кстати и MS Word не обновляет ScrollBar синхронно. Это ъхорошо заметно, если открыть большой файл в ворде и поглядеть на количество страниц, либо если удалить в начале большого RTF файла 10-50 строк — ползунок прыгает немного вверх (и увеличивается), а потом обратно. Думаю стоит перенят опыт.

Я создаю свой элемент управления, функциональность которого частично повторяет RichEdit.
Необходимо отображать текст, который может быть достаточно большого размера (мегабайт и более). Естесственно нужна функция переноса слов (как в том же rich'е). Я создал некоторый алгоритм, который справляется замечательно со своей задачей если текст небольшой.

Мой алгоритм сводится примерно к следующему:
Есть некоторый динамический массив индексов. Каждый индекс — это просто смещение в текстовом буфере. Указывает на первый символ первого слова в каждой строке. При получении сообщения WM_SIZE происходит расчет: вычисляется количество помещаюихся в строку слов и на первый символ первого в каждой строке слова добавляется индекс. Потом при получении сообщения WM_PAINT по количеству индексов (строк) расчитывается размер scrollbar'а, а в зависимости от позиции ползунка расчитывается первая строка, с которой надо начать отрисовку текста и строка, которой надо закончить отрисовку. Потом рисуется текст.
Таким образом получаем прямопропорциональную зависимость — чем больше текст, тем больше необходимо времени на предварительный расчет индексов при изменении размеров окна.

С текстом около 100 кило уже заметен тормоз, а если текст будет больше — можно дожидаться отображения годами . Расчитывать частично я не могу — тогда неполучается расчитать параметры скроллбара.
Каким образом в том же richedit'е реализован расчет переноса слов? Он не тормозит даже при 500 килобайтном тексте.

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

A>Наблюдение:
A>RichEdit как кстати и MS Word не обновляет ScrollBar синхронно. Это ъхорошо заметно, если открыть большой файл в ворде и поглядеть на количество страниц, либо если удалить в начале большого RTF файла 10-50 строк — ползунок прыгает немного вверх (и увеличивается), а потом обратно. Думаю стоит перенят опыт.

Если опустить изменение скроллбара, то в принципе можно расчитывать только от начала абзаца (либо от начала предыдущего абзаца). Вот только чтобы получить общее количество строк — придеться провести расчет от и до. Над этим я еще подумаю, спасибо за идею...

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

Я рекомендую глянуть в исходники аналогичных компонентов.

В зависимости от типа текста и требуемого уровня оптимизации могут быть разные подходы.
Например если текст multifont, то имеет смысл разбить его на "кирпичи" — слова или фрагменты с одинаковым форматированием. И запоминать эти "кирпичи" в каждом параграфе — т.е. строить DOM со всеми вытекающими...

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

Имхо в МС продуктах, в том же IE или notepad`е размер скроллбара прикидывается "на глазок". Т.е. просчитывается разбиения не всего текста, а только того, что наверняка попадает на экран +- какой-то зазор. Это легко проверить, если открыть докмент в IE, а потом уменьшить размер окна браузера. Текст уедет. То же произойдет, если поменять размер шрифта.

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

R>...Текст уедет...

Он уедет по простой причине: IE (и notepad) смотрит не на позицию в тексте, а на смещение текущего view от начала документа. Изменяем размер шрифта — изменяем размкры документа.

Другое дело что броузеры пересчитывают размеры документа в отдельном потоке — поэтому скроллбар "скачет"

Я в HTMEngine успеваю считать "в темпе вальса" — скроллбар не скачет.

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

I>Я создаю свой элемент управления, функциональность которого частично повторяет RichEdit.
I>Необходимо отображать текст, который может быть достаточно большого размера (мегабайт и более). Естесственно нужна функция переноса слов (как в том же rich'е). Я создал некоторый алгоритм, который справляется замечательно со своей задачей если текст небольшой.

Я как-то делал нечто подобное на 2-м курсе. Советую посмотреть бестселлер Кнута "Все про TeX". Там в приложении 1 или 2 — точно не помню — очень круто изложен очень крутой алгоритм переноса слов Мне помогло

Переработал я все совершенно... Мне пришлось предварительно расчитать каждое отдльно взятое слово, что негативно сказывается на использовании памяти, но работает очень быстро. Рационально ли использовать столько вспомогательных данных? Я просто плохо представляю, сколько памяти можно разрешить "съедать" подобному элементу управления (Функциональность: отображение разноцветного текста, изображений, анимации и обработка горячих зон — гиперссылок).