Rodegast
У меня такое ощущение что ты что то не то делаешь.

Возможно. Я (как писал выше) - новичок в Python-е. Какое смог придумать решение - такое и реализовал. Может есть лучшее.

Задача у меня: Надо отображать в реальном времени поток текстовых данных (строк переменной длины) в отдельном окне (отдельном от главного окна; независимо управляемом; немодальном; и чтобы все возможности управления сохранялись даже если в главном окне открыт модальный диалог). Строки могут генериться не только GUI-потоком, но и любым другим потоком (thread-ом) приложения. Общая скорость потока строк может быть довольно высокой - до десятка МБ/сек (а может даже выше?). Должна сохраняться история (массив строк) не менее чем 300тыс. строк, лучше - больше. Отображение должно происходить в реальном времени: идёт поток и в это же время пользователь должен иметь возможность таскать окно по всей сохранённой истории потока, от начала до конца. И должен иметь возможность пристыковать его к концу потока с обновлением текущими данными. Без тормозов и артефактов! Длительность работы в таком режиме - неограничена (хоть несколько суток непрерывно). Этот процесс (управление и отображение в окне) должен минимально влиять на работу основного окна (а лучше - вообще не влиять никак). Это окна логгинга реалтайм-событий в программе. Точнее - логгинг обмена с внешним девайсом с парсингом в текстовый формат. С сохранением потока на диск.
Реалтаймовость обновления данных (когда окно отображает текущий хвост потока) должна быть не хуже чем ~0.1сек.

Поэтому - чтобы вся работа с массивом строк (добавление, обрезка истории массива, сохранение на диск, etc.) минимально влияла на GUI-поток, реализовал так: События ресайзинга окна обрабатываются в GUI-потоке; вычисляется новый размер окна (в столбцах/строках по X/Y); а также - положение слайдеров прокрутки по X/Y; этот размер+положение передаётся в поток, занимающийся массивом строк; а он уже вырезает из хранимого массива нужный фрагмент текста и отправляет его на отображение в GUI-поток. Таким образом - GUI-поток не тормозит, чем бы не занимался поток работы со строками.
Да - текст в окне многоцветный (в потоке текста есть команды управления цветностью, а также ещё некоторые команды).

Работает сейчас всё прекрасно - ничего не тормозит и не морозится в главном окне и в окне лога. Загрузка CPU = ~10% - вполне приемлемо. Была только одна эта проблема с моноширинным текстом. (точнее есть ещё одна, но не такая существенная).

ЗЫ: Функционал записи потока на диск пока не реализовал. Реализую позже. В ещё одном thread-е скорее всего.

> Общая скорость потока строк может быть довольно высокой - до десятка МБ/сек (а может даже выше?)

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

> вычисляется новый размер окна (в столбцах/строках по X/Y); а также - положение слайдеров прокрутки по X/Y; этот размер+положение передаётся в поток, занимающийся массивом строк; а он уже вырезает из хранимого массива нужный фрагмент текста и отправляет его на отображение в GUI-поток

В место самописных виджетов используй стандартный QTextEdit, тогда не нужно будет всё это вычислять.

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

Это максимальная скорость. Я же пишу “до”. Чтобы было понятие какая нагрузка может быть. Скорость неравномерна. При небольшой скорости - видны строки. Если бегут слишком быстро - нажал слайдер вверх - окно зафиксировалось на текущей позиции. Потом слайдер вниз - опять показывает хвост потока.

Rodegast
В место самописных виджетов используй стандартный QTextEdit, тогда не нужно будет всё это вычислять.

А если подумать?
Я же пишу: Общий объём лога может достигать несколько сотен тысяч строк. При добавлении такого объёма в QTextEdit он подвисает на пару секунд (вместе с главным окном). Даже на моём довольно новом и мощном ПК. И так - при каждом обновлении его.
Кроме того - нужна цветность. Чтобы её сделать в QTextEdit, придётся конвертить текст в HTML например. Что сложнее, чем просто нарисовать текст самостоятельно.

Вобщем всё уже работает нормально. На прикреплённой картинке как раз скриншот этого окна:

> Это максимальная скорость.

Знаешь роман “Война и мир”? Вот если его обычным текстом набрать то получится объём примерно 2-3 МиБ, а у тебя их 10 в секунду! Максимальная эта скорость или нет абсолютно не важно, к оператору один раз такое прилетело и всё, его деятельность сведена к нулю. Обычно для таких целей используют что то вроде grafana, но никак не ручное чтение лога.

> При добавлении такого объёма в QTextEdit он подвисает на пару секунд (вместе с главным окном).

Если добавлять всё сразу, то подвиснит, а если по одной строке закидывать, то норм.

> Кроме того - нужна цветность. Чтобы её сделать в QTextEdit, придётся конвертить текст в HTML например

Не нужно никакого HTML, подключаешь QSyntaxHighlighter и делаешь через него подсветку.

Rodegast
Максимальная эта скорость или нет абсолютно не важно, к оператору один раз такое прилетело и всё, его деятельность сведена к нулю.

Вы не понимаете о чём речь. Какой смысл тогда дискутировать? Я пользуюсь, пользоваться удобно, люди пользуются и довольны - значит нужно и полезно.

Rodegast
При добавлении такого объёма в QTextEdit он подвисает на пару секунд (вместе с главным окном).Если добавлять всё сразу, то подвиснит, а если по одной строке закидывать, то норм.

Ну да, “по одной строке” добавлять и удалять при том, что новые строки могут прилетать по несколько штук за миллисекунду. Оно виснуть будет непрерывно.
Это уже не говоря о проблемах со скроллерами, положение которых тоже придётся постоянно корректировать. И пользователь вообще не сможет ими пользоваться при входящем потоке (который может идти непрерывно; и при этом в это же время нужно скроллить окно). И куче других проблем на ровном месте.
Нафига вся эта куча проблем, если всё просто и элементарно решается собственной прорисовкой??? И с минимальной загрузкой CPU при этом? (при добавлении в QTextEdit загрузка CPU приличная).