Serge
Убедил, буферизация вывода действительно ускоряет рисование до 3.7 раз (похоже, запись во фреймбуйр идет блоками по 64 байта).
Дык я в этом и не сомневался!

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

Я несколько выше предложил модель экономящую память, работающую без сжатия. Несколько позже попытаюсь все изложить в графическом виде, чтобы объяснить суть. Все-же 100 Кб или 2,2 Мб - практически без потерь в скорости, поскольку как и предполагалось нас останавливает скорость обмена именно с видеопамятью. Обмен же с ОЗУ значительно более быстрый и даже удвоение времени затрачиваемого на вычисления не скажется на самом выводе, но даже этого можно избежать если правильно реализовать код.

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

Скорость отрисовки при произвольном доступе очень маленькая, так что здесь будет полезна любая оптимизация. Даже если мы упрёмся в скорость видеопамяти.

Последние 10 лет видеокарты используют тайловую организацию видеопамяти. Пикселы располагаются не построчно, а блоками 4х2 или 2х2 пикселя, которые объединяются в бОльшие блоки по 2 или 4 кБ. В этом случае соседние пиксели на экране попадают в соседние линейки кеша gpu.

Mario
Надо бы что-то такое простенькое придумать, и желательно с дырками.

Serge
Угу, я тоже думал о тайлах (переводится как "кафельная плитка" или типа того)

Народ,
а что если мы системно разрешим только окна четного размера (в пикселях) для всех четырех углов?
- пользователь этого даже не заметит,
- железу это очень сильно понравится,
- карта экрана (даже если ее не удастся заменить чем-то более разумным) усохнет в 4 раза,
- и еще растровые шрифты можно будет сильно сжать и ускорить.

art_zh wrote:Mario
Надо бы что-то такое простенькое придумать, и желательно с дырками.

С дырками не получиться экономии - либо дырки, либо экономия. Впрочем с 2003 года (насколько я знаком с системой начиная с Menuet) операционка замечательно обходиться без дырок. 99,99% приложений.

art_zh wrote: Народ,
а что если мы системно разрешим только окна четного размера (в пикселях) для всех четырех углов?
- пользователь этого даже не заметит,
- железу это очень сильно понравится,
- карта экрана (даже если ее не удастся заменить чем-то более разумным) усохнет в 4 раза,
- и еще растровые шрифты можно будет сильно сжать и ускорить.

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

Вот собственно что я подразумевал: Весь фокус в том что для такой однобитовой матрицы не нужно хранить всю структуру. Достаточно хранить две проекции - на сторону X (горизонтали) и сторону Y (по вертикали). В результате на пресечении двух единиц есть точка, если хотя-бы по одной стороне отсутствует единица, то точки нет. Когда два нуля, то само собой ноль сразу.

Для хранения 256 слоев каждой точки на каждой стороне нужно 256 битовое значение, т.е. 32 байт.
Вся проверка сводиться к обработке этих 32-х байт по Х и 32-х байт по Y, разумеется это в крайнем случае если окно самое нижнее в оконном стеке. Самое верхнее окно вообще проверять не нужно.
Т.е. Каждое 32-х байтное значение это набор слоев по сути.

Если обрабатывать dword'ами, то для самого нижнего окна это будет 8 проверок на Х и 8 проверок на Y. Опять же это крайний случай. Проверка каждого для каждого dword это команда test - проверка на наличие установленных битов выше текущего рассчитываемого слоя. Причем если проверять с самого верхнего слоя то в общем случае это будет быстрее, чем проверять от нижнего к верхнему.

Из плюсов, кроме существенной экономии памяти пересчет при изменении позиции окна в оконном стеке значительно ускорится.

Mario
Хорошо. Битовые поля просматриваются легко и просто.
Хотя еще экономичнее в этом случае просматривать (на больше/меньше) для каждого окна его x1, y1, x2 и y2 - тут даже отдельная структура не нужна, координаты каждого окна известны. И работать будет явно быстрее, чем моя некэшируемая таблица

Только надо как-то эффективно проверять перекрытие окон - перетряхивать весь оконный стек?

И потом, надо ведь не просто определить видимость одной конкретной точки (для этого, кстати, нынешняя таблица лучше всего приспособлена).
Как я понял Serge'a, надо уметь быстро (и просто) отрезАть от заданной линии невидимые куски, после чего забивать видимую часть линии во фреймбуфер на максимально достижимой скорости (например, rep movsd без дополнительных проверок)

Сложноватой получится проверка. И ещё одна проблема. Карта окон используется для определения окна в точке (x,y) и установки соответствующего курсора.

И не забываем про эмуляторы. Там просадка будет не слабой. Особенно в Боше.

Нынешний вариант для Колибри самый оптимальный. Своеобразный z-буфер - размен памяти на быстродействие это обычное явление.

art_zh

Хотя еще экономичнее в этом случае просматривать (на больше/меньше) для каждого окна его x1, y1, x2 и y2 - тут даже отдельная структура не нужна, координаты каждого окна известны. И работать будет явно быстрее, чем моя некэшируемая таблица

Насчет быстрее я бы не стал так однозначно утверждать. Потому что в худшем случае придется просматривать все 255 слоев, а на каждый слой 4 проверки координат итого 256*4=1024 проверки на каждую точку.

Только надо как-то эффективно проверять перекрытие окон - перетряхивать весь оконный стек?

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

И потом, надо ведь не просто определить видимость одной конкретной точки (для этого, кстати, нынешняя таблица лучше всего приспособлена).

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

Serge

Сложноватой получится проверка. И ещё одна проблема. Карта окон используется для определения окна в точке (x,y) и установки соответствующего курсора.

Да, с курсором еще надо подумать как быть. Впрочем можно ограничить использование сменного курсора только на верхнее окно.

С другой стороны это ведь пока только идея.

Mario wrote:в худшем случае придется просматривать все 255 слоев, а на каждый слой 4 проверки координат итого 256*4=1024 проверки на каждую точку.

У меня нет 255 задач. И у тебя нет. И ни у кого нет. Тем более чтобы все были развернуты и что-то там себе рисовали.
20-30 маленьких окошек реально перекрывают весь экран, т.е. просмотр потребует (пусть не в худшем, но в "очень плохом" случае) около сотни проверок.
Скорость вывода отдельных пикселей не очень критична (если только буквы не рисуются попиксельно). Надо думать как нам пробить стену в скорости горизонтальной заливки (особенно для битмапов).
Да, 20% ускорение в hline - это конечно хорошо.
Но уже сейчас видно, что можно быстрее.

И совершенно ясно, что кэш надо освобождать для более полезного груза. У меня, например, поток входных данных рвется при отрисовке картинки - проц буксует на простейшей выборке. И запрет кэширования таблицы конечно же не помог - рисование теперь просто засыпает.
А ведь открыты-то всего 2-3 окна, здесь "больше/меньше" просто напрашиватся.

Пока что никто не реализовал лучше. Особенно чтобы в тесте заметно было.

Последний эксперимент (кэшируемая таблица, hline и vline вызываются через быстрый AMD-syscall с передачей параметров через стек)
Результаты для транка - в крайнем правом столбце; в левом окне - баловство с закрытым окном (это то, чего можно достичь с двойной оконной буферизацией)
Левый столбец правого окна - то, что уже реализовано. По-моему, очень даже заметно.

art_zh wrote:вызываются через быстрый AMD-syscall

Ты опять говоришь о 20-30% парка электроники на которой может запускаться Колибри.

"Что русскому хорошо, то немцу смерть." к\ф. Брат

Mario wrote:Ты опять говоришь о 20-30% парка электроники на которой может запускаться Колибри.

Ну а что я могу поделать - только на них работает более-менее приличный syscall (правда тоже со своим приветом - ecx теряется). Видишь - сразу прирост скорости hline на 25%.

Ну а если через int40 - тогда только на 20%.
Но зато - для всех Колибри-машин с VESA2/32bpp-режимом.

На Атлонах sysenter есть. И на прежних моделях работает быстрее родного syscall.