А как насчет совсем сумасшедшей идеи - сделать много текстур размером с программное окошко (пользовательская область + рамка) каждая, и грузить блиттером только те "текстуры", в которых в течение последнего кадра имело место рисование/перемещение?Serge wrote:Почесал репу, есть относительно несложный способ ускорить ввод/вывод аппаратной акселерацией при помощи shadowfb. Сейчас ядро отображает первичный видеобуфер на LFB_BASE. Драйвер создаёт в системной памяти текстуру размером в экран и ремапит её вместо видеопамяти. Ставится обработчик прерывания и на обратном ходе луча текстура блиттером копируется в видеопамять. Получаем ускорение на запись в 60 раз и три порядка на чтение (если нет проблем с кешированием). Видеоплеер будет очень рад. В этом случае оптимизация кода отрисовки даст очень хороший прирост.
Я тут вижу три больших плюса и один огромный минус:
+ приложение просто рисует в своем индивидуальном "фреймбуфере", а ядро только предоставляет ему линейный адрес этого буфера - все остальные инструменты рисования (putpixel, drawline, drawbox ...) могут быть легко реализованы в Круге Третьем без потерь в скорости. И даже с заметным ускорением - не надо будет гонять int40 ради каждой ерунды.
+ программные задержки сокращаются (почти) до теоретического минимума за счет исключения цепочки тупых проверок и перепроверок (перекрытия окон, попаданий в границы экрана, и т.п.), которые сейчас съедают сотни тактов на каждом пикселе.
+ код GUI ядра становится простым как табуретка (во всяком случае, в сравнении с теперешним кошмаром), что должно положительно сказаться не только на скорости и размере, но и на общей надежности ядерных служб, а также на переносимости GUI на новые графические платформы.
- единый системный фреймбуфер сейчас требует максимум 9 Мбайт системной памяти (1920х1200х4). Если у каждого окошка будет свой отдельный фрейм, то системной памяти на всех может не хватить (крайний случай: 256 распахнутых на весь экран окон требуют больше 2Гб).