Board.KolibriOS.org

Да, есть такое - наблюдал на Qemu. Перерисовывание множества окошек не такая быстрая вещь.
На реальной машине задержка практически незаметна - только что проверил на eBox.

Mario, текущее решение... неплохо. Оно есть. Но, может быть, не активировать окно вообще?

По опыту Фантома, могу посоветовать:

- пересобирать систему на сервере автоматом после любой модификации кода, но не чаще раза в час (иначе задолбает)
- после пересбора прогонять регресс-тесты. в фантоме тесты покрывают работу ключевых подсистем ядра (таких, как базовые аллокаторы, контейнеры, примитивы синхронизации и тайминга), части системных вызовов posix, инструкций виртуальной машины и ещё кой-чего по мелочи.
- рассылать на список рассылки итоги сборки и теста

собственно, процедуру автотеста (он, конечно, делается под юниксом на qemu) можно дёрнуть из Фантома, модифицировав под специфику Колибри

При каждом коммите, который затрагивает программы, входящие в дистрибутив, собирается новый дистр. Логи сборки лежат вместе с дистрибутивом.
Информация о сборке отображается в чате на форуме - самом оперативном средстве общения в проекте.

Прошу переписать на check_box2 следующие программы: cpu (я пробовал и у меня не вышло), kpack, fasm и другие, если есть. Я поправил только scrnshoot.

Что угодно, но не CPU. Такая программа должна работать без библиотек.

Сpu использует старую версию чекбокса check_box, я прошу переписать на новую.

Leency wrote:Прошу переписать на check_box2 следующие программы: cpu (я пробовал и у меня не вышло), kpack, fasm и другие, если есть. Я поправил только scrnshoot.

Ничего не надо переписывать. Box_Lib поправлена в ревизии 2249
Однако если еще какое-то приложение использует "checkbox 2", то в таких приложениях нужно исправить флаг.

SoUrcerer wrote:Что угодно, но не CPU. Такая программа должна работать без библиотек.

Box_Lib де-факто одна из стандартных библиотек. Ее отсутствие в образе является дурным тоном.
CPU кстати давно уже работает с Box_Lib.

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

Все-же наличие возможности менять размера изображения в Vesa, без перезапуска ядра, была хорошей фичей.

Без понятия. Я этот код с 2007 года не трогал.
Imho надо давно выкинуть. Метод потенциально небезопасный для мониторов.

Он небезопасный если менять частоту, а если ее сохранять, то вполне себе нормальный.

А там по другому не получается. Программировать PLL vmode не умеет. Поэтому если в загрузке было 1024*768 60Гц pixelclock будет 47.2 Мгц(47 185 920). При переходе к 800*600 получим частоту кадров 98Гц. Уже нестандартная частота. Более точно значение считается через VESA GTF, потому что разрешение считается в знакоместах текстового режима (8*16 пикселей). 1024*768 это текстовый режим 128*48.

Mario wrote:Уже не помню с какой ревизии VRR поломан, не хочется быть голословным, но человек это сделавший (Serge? или кто еще видео занимался) должен прояснить зачем так, можно ли починить или нужно убрать из дистрибутива программу и все ссылки на нее.

Все-же наличие возможности менять размера изображения в Vesa, без перезапуска ядра, была хорошей фичей.

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

Может быть запуск программы сломал ты, но вот сам драйвер VRR, который в ядре, не работает в дистрибутиве 0770, а в дистрибутиве 0700 еще работает.