История изменений
Исправление X512, (текущая версия) :
Часы в панели задач возводят таймер, по истечении таймера делают invalidate region и снимают таймер.
Если WM_PAINT не пришло, значит часы не видимы на экране, и дальше можно ни о чем не беспокоиться.
При получении WM_PAINT (часы снова стали видимы) – после отрисовки часы снова возводят таймер.
Я так тоже делаю в своих проектах. Это позволяет избежать шквала сообщений таймера при медленной отрисовке и позволяет не нагружать систему когда графический объект не видно. Также это лучше подходит для модели памяти со сборщиком мусора: не нужно обрабатывать оповещения об удалении визуального объекта из дерева объектов.
Другой пример: события мыши не стоят в очереди, а на лету генерируются в процессе чтения сообщений.
В результате окно зависает намертво если обработка сообщения отсылает новое сообщение. В Haiku всё работает. Я так и не нашёл способа избежать зависания. Надеялся на WM_ENTERIDLE, но оно не всегда присылается. В итоге пришлось сделать обработку в главном цикле и смириться с зависанием при открытии меню и модальных окон.
честная микроядерная реализация GUI на этом ядре тормозила на актуальном железе.
Это уже 20 лет не является проблемой. Сейчас ничего не мешает сделать графику в пространстве пользователя. Ссылаться на проблемы 199x годов в 2020 году - это странно.
Исходная версия X512, :
Часы в панели задач возводят таймер, по истечении таймера делают invalidate region и снимают таймер.
Если WM_PAINT не пришло, значит часы не видимы на экране, и дальше можно ни о чем не беспокоиться.
При получении WM_PAINT (часы снова стали видимы) – после отрисовки часы снова возводят таймер.
Я так тоже делаю в своих проектах. Это позволяет избежать шквала сообщений таймера при медленной отрисовке и позволяет не нагружать систему когда графический объект не видно. Также это лучше подходит для модели памяти со сборщиком мусора: не нужно обрабатывать оповещения об удалении визуального объекта из дерева объектов.
Другой пример: события мыши не стоят в очереди, а на лету генерируются в процессе чтения сообщений.
В результате окно зависает намертво если обработка сообщения отсылает новое сообщение. В Haiku всё работает. Я так и не нашёл способа избежать зависания. Надеялся на WM_ENTERIDLE, но оно не всегда присылается. В итоге пришлось сделать обработку в главном цикле и смириться с зависанием при открытии меню и модальных окон.
честная микроядерная реализация GUI на этом ядре тормозила на актуальном железе.
Это уже 20 лет не является проблемой. Сейчас ничего не мешает сделать графику в пространстве пользователя.