Отлично, думаю вполне нормальное решение. Генерацию больших объемов данных можно и отложить. Да и при современных объемах и характеристиках ПК даже несколько мегабайт данных это ничтожно мало.

Вот как. В таком случае, думаю виджет вполне подходящее решение. Тогда, возможно, имеет смысл сделать экран не один, а инстансом — т.е. вот есть экран по умолчанию, но если надо — то можно еще наклепать сколько надо и сделать их виджетами? Чтобы можно было сделать несколько виджетов и/или окон. Например при наличии двух мониторов можно будет на один вывести красивую 3D графику, а на втором разные элементы управления, виджеты или еще что-то нужное. Или для каждого экрана лучше просто делать отдельную форт-машину форком в отдельном потоке?

Начал работать TextEdit. Загрузка, сохранение, подсчет строк и отправка i-й строки в форт-машину.

Немного предсказуемый, но все равно неприятный эффект - никакие ухищрения с QImage и отложенным обновлением отрисовки не помогают привести двумерную графику к приемлемому уровню производительности. Проблема в отсылке сообщений из Форта в Qt - каждый пиксель надо "обернуть" в сообщение, поместить в FIFO, а оттуда его заберет основной поток приложения. А это все существенно медленнее, чем просто писать в массив. Так что еще одно препятствие образовалось на пути к красивым приложениям...

А - зачем каждый и - по одному?
Или - задачей диктуется?

В принципе, какого-то специального требования нет. Однако аналог объекта Canvas очень даже удобен. Достаточно просто ставить пиксели и другие объекты куда-то в буфер, а они оттуда сами забираются. Так сделано в Кварке, где вся графика рисуется без всякого знания о GDI со стороны программиста, просто буфер регулярно забирается движком Кварка и посылается на экран (с самостоятельным определением реального размера и прочего). По сравнение с написанием обработчика wm_paint это существенно проще, потому что при необходимости вывода чего-то другого в другой части программы уже не нужно думать, как это будет стыковаться с уже написанным для wm_paint кодом.

Я уже посматриваю в сторону QImage.loadFromData, который может принимать на вход указатель на массив, содержащий графический файл. В принципе, нет ничего сложного в подготовке bmp в самой программе, достаточно сделать фиксированный заголовок. Чуть неудобнее то, что инициировать отрисовку этого bmp придется программисту же, каждый раз, когда он захочет увидеть на экране сделанные изменения.

Уфф. Создание в памяти bmp, похоже, работает. И с учетом того, что момент обновления выбирается в программе, скорость вполне приличная. Остается еще один интересный вопрос - ведь с таким подходом "экранов" в программе становится много - столько, сколько будет создано QImage для вывода картинок.

Возможно не к месту, я использовал простой формат ppm
https://ru.wikipedia.org/wiki/Portable_anymap
он элементарно пишется и читается всем, чем угодно

P6
#тут возможна строка комментариев это текстовый заголовок
X Y
255
тут конец текстового заголовка, идут байты rgb в количестве X*Y

Действительно, интересная штука. Вот возможность записи/чтения в очевидной текстовой форме как раз и подкупает. Только боюсь, на обработку придется тратить больше времени. bmp все-таки самый простой вариант с точки зрения представления пикселов, причем достаточно фиксированного заголовка. Пока тестирую написанное, и скорость у bmp более или менее приемлемая. Понятно, что игровая графика при такой реализации получается с натяжкой, но для нее есть OpenGL.

В P6 только заголовок текстовый, rgb - это обычные бинарные байты
по байту на каждый цвет.

Да, вот тут написано, что ppm поддерживается.
https://doc.qt.io/qt-5/qimage.html#reading-and-writing-image-files

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

Ну так что?
Есть 64-битный Кварк в виде DLL?

Если есть, то какие конвенции вызозов поддерживаются.
И может ли Кварк пересохранить себя в виде DLL c записью новых функций в секцию экспорта?

Нет, он такой пока не нужен. Он в виде forth.h и компилируется в составе проекта - например, с GUI. Соответственно, и dll создает пускай внешняя программа.

QChart прошел по той же схеме подключения