а) Иван,а как их можно ускорить,если видеокарта поддерживает только vesa,а аппаратного PutImage нет ?
Ведь в старых видеокартах вся проблема вывода графики ложиться на ЦП.А,если в качестве ЦП Pentium100,то быстрой работы графики ожидать неприходиться.
Я замерял скорость работы 7-ой функции на Pentium100.В режиме 640*480 с поддержкой vesa2.0 - 33 кадра в секунду.
В случае vesa1.2 и отсутствии родного драйвера видеокарты fps=6(вот тут уж мы сразу ощутим инертность клавиатуры).

в) Получается,если я закочу написать "аааааа" ,то у меня выйдет "ааа ".Мне бы такого не хотелось.


Я считаю,что буфер укорачивать нужно.А вот длину буфера нужно подбобрать экспериментально(чтобы все приложения нормально работали).

2 andew_programmer
а) не секрет, что GUI в КоОС отвратительнейший и далеко не только из-за отсутствия аппаратного ускорения;
в) символы в буфере есть тогда, когда их оттуда никто не забрал, так что будет "такое" только в том случае, какой описал Марат

Усечение буфера приведёт к тому, что система просто будет пропускать *все* символы, когда буфер полон, тогда как выборочное добавление будет пропускать только многократные повторы одного и того же символа.

Есть мысль!
Можно к каждой задаче прикрутитить свой буфер клавиатуры, и оставить один общий буфер клавиатуры для всех приложений. А может даже лучше написать функцию, чтобы любая задача могла назначить себе определенного размера буфер клавиатуры. И когда задача станет активной драйвер клавиатуры бутет паралельно наполнять не только свой буфер но и буфер активной задачи.
Точнее сказать не могу, нет четкой структуры ядра

Если кому интересно, то в ядро нужно ввести второй буфер клавиатуры. Если быть точнее то ввести нужно битовую маску размером например 128 бит, где каждый бит будет означать определенную клавишу клавиатуры (еденица - клавиша нажата, ноль - клавиша отпущена). По прерыванию с клавиатуры обработчик клавиатуры будет заполнять как байтовый буфер клавиатуры так и битовую маску. Для удобства нужно сделать не одну битовую маску шириной 128 бит, а небольшой массив из битовых масок размерностью например 8 - 16, и организовать их заполнение типа кольцевого буфера. Будет еще лучше если написать функции котороые позволят любому приложению иметь свой кольцевой байтовый буфер, и свой кольцевой буфер битовых масок. Тогда обработчик клавиатуры будет заполнять не только свои внутренние (общедоступные ) бит маску и байтовый буфер клавиатуры, но и буферы активного на данный момент приложения. Для удобства программиста нужно будет дописать пару сервисных функций работы с буферами клавиатуры. Например функцию которая будет возвращать ширину и глубину битовой маски или функцию которая сможет задавать эти самые параметры.

Для того чтобы это все работало нужно прежде всего написать пару взаимообратных фунуций работы с памятью.

1 - Выделить из свободной памяти буфер (кусок памяти)
2 - Удалть выбранный буфер (освободить память)

w-tools
>Для удобства нужно сделать не одну битовую маску шириной 128 бит, а небольшой массив из битовых масок размерностью например 8 - 16, и организовать их заполнение типа кольцевого буфера

А почему не одне битовую маску? И зачем кольцевой битовый буфер? Работать с кольцевым буфером сложнее чем с линейным массивом.

Serge
>1. А почему не одне битовую маску?
>2. И зачем кольцевой битовый буфер?
>3. Работать с кольцевым буфером сложнее чем с линейным массивом.

1. Если использовать только одну битовую маску то не возможно будет по ней определить предыдущее состояние этой битовой маски. И придется лезть в буфер нажатых клавиш. Так что битовых масок должно быть как минимум две

2. Под фразой "кольцевой битовый буфер" имелося в виду алгоритм заполнения массива из битовых масок (по типу кольцевого байтового буфера обычной клавиатуры)

3. Однозначно, что массив битовых масок будет организован как линейный массив. (видимо я не правильно выразил свою мысль)

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

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

Нужны не отдельные буферы клавиатур для каждого приложения а нормальные очереди для всех событий с приоритетами и произвольной выборкой
w-tools
А зачем хранить предыдущее состояние битовой маски ? За одно событие меняется только один бит, достаточно хранить его номер, только зачем он вообще?

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

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

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

P.S. В общем говоря на такомже алгоритме нужно строить GUI
[/b]

Я не против битовой маски состояния клавиш. Похожая вещь есть в DirectInput и полезна для игрушек, хотя многие игры делают её сами.
Но зачем могут понадобиться предыдущие состояния не понял. Если делать отдельные буферы для клавиатуры то придётся делать отдельные буферы и для мыши, портов и вообще всех "железок".
ИМХО программам нужны свои очереди событий а не отдельные буферы. Кстати большая часть кода для таких очередей уже готова но сам код генерирующий события размазан по всему ядру и нужно много времени чтобы его переписать.

Serge
Все правильно !!! Отдельные буферы придется делать, но пинципиально какая разница имеется ли в системе монолитный буфер именуемый очередью или есче как нибудь, или эти буферы распределены и возникают только по надобности ???

Нестыковки которые возникают из моих постов имеют концептуальный характер. Я описываю микроядерную, несимметричную многопроцессорную, асинхронную модель. В кторой имеет актуальность только быстрое и стабилное микроядро. Осталное возлагается на "руки умельцев". Поэтому и идут концептуальные нестыковки.

Посему я "подбиваю" начать параллельно еще один но "микроядерный проект", а Колибри использовать как платформу для отладки и эксперементов не трогая ее сущности. Проблема в том что на данном этапе я еще не совсем въехал в тонкости защищенного режима i386, посему не могу организовать грамотный менеджер задач!!!
Если микроядерный проект 'пойдет' это будет ГУД !!!

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