Интерактивное (почти) управление

[Racheengel]

Но все это полумеры и основной проблемы не решает..

А какую собственно вы хотите решить проблему? Отзывчивость GUI?
Ну так она решается предложенным вами методом. По другому гуй нормально разгрузить не получиться.
Как-то вы сами за сомневались в решении, которое сами же решили использовать.

Загрузка основного потока, имхо, тут основная проблема. А обновления гуя уже как следствие.

[lit-uriy]

Наоборот, пусть меняет много раз если успевает - это желательно

Нихрена не понял. Это ведь и было проблемой:

Наконец "просралось", дело дошло до событий, и выяснилось что надавил значение куда больше чем думал.

что вообще значит "Если успеет"?

Пользователь внёс изменения -> блокировка ввода -> расчёт -> отображение результата -> разблокировка ввода -> цикл замкнуть тут.

[Old]

Загрузка основного потока, имхо, тут основная проблема. А обновления гуя уже как следствие.

Скажем так, основная проблема в "тупизме GUI" продолжительные паузы между этапами обработки событий, накопившихся в очереди.
Какие решения возможны:
* увеличить частоту отработки processEvents, возможно для этого придется разбивать долгую работу на части, между которыми обрабатывать события. Недостатки: ручной менеджмент всего этого разбиения (этакий ручной greenthreads) Такое сложно сопровождать и расширять.
* вынести все тяжелые операции в отдельный поток, оставив GUI-потоку непрерывную обработку событий.

Рабочая нитка:

Код:

void work()
{
    for(;;)
    {
        readUserCtl();     // Читаем значения из GUI установленные пользователем
        readTextures();   // 40 минут
        calcGeometry(); // 1 час 15 минут
        renderScene();   // 3 часа
    }
}

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

[Igors]

Загрузка основного потока, имхо, тут основная проблема. А обновления гуя уже как следствие.

Прямолинейно разгрузить главную нитку легко может оказаться нереальным.

что вообще значит "Если успеет"?

Напр кадр считается секунду(ы). За это время он напр 5 раз нажал "газ", каждое увеличило значение на 0.1, на следующем кадре газ намного больше. На здоровье ЕСЛИ он видел (и значит согласен) с этим.  

Пользователь внёс изменения -> блокировка ввода -> расчёт -> отображение результата -> разблокировка ввода -> цикл замкнуть тут.

Это соответствует режиму "шаг" (т.е. следующий кадр по действию юзера). А когда "автомат", остается только принять все накопившиеся события и опять уйти на расчет. А накопиться их может немало.

[Old]

Прямолинейно разгрузить главную нитку легко может оказаться нереальным.

Конечно. Все зависит от того, кто и как ее загружал.

[lit-uriy]

так, вроде я понял, что тебе надо.

См. скриншот во вложении

У меня есть мнемосхема оборудования, на ней элемент регулятора. При изменении положения ползунка или спинбокса команда отправляется в оборудование, происходит это не быстро.
Чтобы не засирать канал данными (другие мнемоэлементы тоже хотят пообщаться), желательно передавать "конкретное" значение. А пользователю хочется "по рулить".

Сделал так:
С ползунка данные отправляются когда пользователь его отпустит;
Со спинбокса - когда произойдёт таймаут после изменения его величины.

[Igors]

Напомню условие

Но есть одно обстоятельство: в отличие от игры время смены кадра может быть любым ..

Почему-то спокойно принять это условие оказалось невозможным, внимание сосредоточилось только на одном: как сделать время меньше. Да, тогда проблема рассосется сама собой - но это уже др задача (кстати куда более сложная).

Что делать если требуется отрисовка (обычно небольшая), но событийный цикл глухо забит? Использовать вторичный цикл - тоже не гуд. Гораздо естественнее действовать наоборот - заведем нитку которая будет обслуживать нажатия юзера пока главная занята. Но здесь срабатывает заученное правило "UI ТОЛЬКО в главной нитке". Кстати откуда оно взялось? (я лично не помню). Вероятно Qt так снимает кучу ненужных вопросов, но может перетерпеть нативняк NSWindow/HWND куда выгоднее?

Хорошо, смотрю типа "PeekMessage other thread". Ответ однозначен - нет, в др нитке никаких событий не придет. И объяснение почему: окно принимает месяги в той нитке где оно было создано. Позвольте, так значит и создавать (и рисовать) нативные окна в др нитке МОЖНО? И события есть? Тогда что мешает "накрыть виджет прозрачным стеклом", т.е. в др нитке создать окно поверх нашего и спокойно обновлять его. Или как? Или я что-то неправильно понял?

[Old]

Гораздо естественнее действовать наоборот - заведем нитку которая будет обслуживать нажатия юзера пока главная занята. Но здесь срабатывает заученное правило "UI ТОЛЬКО в главной нитке".

А что поменялось? В чем вы видите этот "наоборот"? Это все то же, что предлагал Racheengel.

[Smogg]

А есть другие варианты кроме learning by doing?
Писать продакшен код всяко лучше вместо того, чтобы говнокодить абстрактную муйню по примерам из книжек.

Глупость брякнули, право) Сначала learning, а уж потом doing. Как говаривал Ницше: "Лишь построив дом научаешься тому, что должен был знать с самого начала". Научится-то научился, но дом-то уже построен!

Не имея нормальной практики, по книжкам не выучишься. Это так же, как не выучиться летать на самолете по книжке.

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

Как показывает практика, всё реально, вопрос лишь в количестве костылей