Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Dec 04, 2021 9:23 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 13 posts ] 
Author Message
 Post subject:
PostPosted: Tue Aug 15, 2006 8:08 pm 
Offline

Joined: Fri Nov 12, 2004 3:20 pm
Posts: 90
Проблема возникает из-за того, что обработка нажатия клавиши происходит медленней, чем сигнал о нажатии от клавиатуры. Исправить это можно
а) ускорением функций рисования
б) повышать приоритет активного процесса - но этого пока в КоОС нет
в) при добавлении нажатия в буфер проверять предыдущие несколько символов - если они совпадают с добавляемым, не учитывать это нажатие.


Top
   
 Post subject:
PostPosted: Wed Aug 16, 2006 1:21 am 
Offline
User avatar

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

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


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


Top
   
 Post subject:
PostPosted: Wed Aug 16, 2006 9:03 am 
Offline

Joined: Fri Nov 12, 2004 3:20 pm
Posts: 90
2 andew_programmer
а) не секрет, что GUI в КоОС отвратительнейший и далеко не только из-за отсутствия аппаратного ускорения;
в) символы в буфере есть тогда, когда их оттуда никто не забрал, так что будет "такое" только в том случае, какой описал Марат

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


Top
   
 Post subject:
PostPosted: Sat Feb 17, 2007 9:36 am 
Offline

Joined: Thu Feb 08, 2007 10:17 am
Posts: 54
Есть мысль!
Можно к каждой задаче прикрутитить свой буфер клавиатуры, и оставить один общий буфер клавиатуры для всех приложений. А может даже лучше написать функцию, чтобы любая задача могла назначить себе определенного размера буфер клавиатуры. И когда задача станет активной драйвер клавиатуры бутет паралельно наполнять не только свой буфер но и буфер активной задачи.
Точнее сказать не могу, нет четкой структуры ядра :-(


Top
   
 Post subject:
PostPosted: Sun Feb 18, 2007 11:56 am 
Offline

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

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

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


Top
   
 Post subject:
PostPosted: Sun Feb 18, 2007 5:13 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
w-tools
>Для удобства нужно сделать не одну битовую маску шириной 128 бит, а небольшой массив из битовых масок размерностью например 8 - 16, и организовать их заполнение типа кольцевого буфера

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


Top
   
 Post subject:
PostPosted: Sun Feb 18, 2007 10:15 pm 
Offline

Joined: Thu Feb 08, 2007 10:17 am
Posts: 54
Serge
>1. А почему не одне битовую маску?
>2. И зачем кольцевой битовый буфер?
>3. Работать с кольцевым буфером сложнее чем с линейным массивом.

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

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

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

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


Top
   
 Post subject:
PostPosted: Mon Feb 19, 2007 3:25 am 
На мой взгляд каждому приложению нужно выделить свой буфер.
Что касается алгоритма обработки, то в первую очередь приложение должно обработать или выбросить все коды клавиш которые лежат в буфере, а уж потом перерисовывать своё окно (в винде WM_PAINT приходит только если в очерединет никаких других сообщений).


Top
   
 Post subject:
PostPosted: Mon Feb 19, 2007 5:34 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Нужны не отдельные буферы клавиатур для каждого приложения а нормальные очереди для всех событий с приоритетами и произвольной выборкой
w-tools
А зачем хранить предыдущее состояние битовой маски ? За одно событие меняется только один бит, достаточно хранить его номер, только зачем он вообще?


Top
   
 Post subject:
PostPosted: Mon Feb 19, 2007 10:48 am 
Offline

Joined: Thu Feb 08, 2007 10:17 am
Posts: 54
Mario79
Обработчик клавиатуры деиствительно усложняется но не на много, зато упрощается алгоритм обработки клавиш со стороны пользовательского приложения. Если я правильно понял, то по прерыванию с клавиатуры обработчик клавиатуры заполняет свой буфер клавиатуры.
В первом, описанном выше случае он еще установит байтовую маску (а лучше если будет хранить одно или несколько педыдущих состояний маски) Это небольшое усложнение в ядре по моему мнению ускорит работу приложений пользователей за счет упрощения их кода обработки клавиш.

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

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

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


Top
   
 Post subject:
PostPosted: Mon Feb 19, 2007 11:05 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Я не против битовой маски состояния клавиш. Похожая вещь есть в DirectInput и полезна для игрушек, хотя многие игры делают её сами.
Но зачем могут понадобиться предыдущие состояния не понял. Если делать отдельные буферы для клавиатуры то придётся делать отдельные буферы и для мыши, портов и вообще всех "железок".
ИМХО программам нужны свои очереди событий а не отдельные буферы. Кстати большая часть кода для таких очередей уже готова но сам код генерирующий события размазан по всему ядру и нужно много времени чтобы его переписать.


Top
   
 Post subject:
PostPosted: Mon Feb 19, 2007 1:16 pm 
Offline

Joined: Thu Feb 08, 2007 10:17 am
Posts: 54
Serge
Все правильно !!! Отдельные буферы придется делать, но пинципиально какая разница имеется ли в системе монолитный буфер именуемый очередью или есче как нибудь, или эти буферы распределены и возникают только по надобности ???

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

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


Top
   
 Post subject:
PostPosted: Sun May 06, 2007 10:27 pm 
Offline
User avatar

Joined: Thu Mar 29, 2007 3:02 am
Posts: 249
было бы неполохо, для начала сделать буфер программно отключаемым, или, вернее получать данные о нажатых клавишах без его использования... это важно для игрушек, например... :)


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 13 posts ] 

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited