Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Sep 17, 2019 2:20 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 44 posts ]  Go to page Previous 1 2 3
Author Message
 Post subject:
PostPosted: Wed Sep 05, 2007 9:34 pm 
Maxis
Quote:
когда приложение входит в цикл и не может ответить на сообщение о перерисовке окна(когда требуются все ресурсы процессора, например, при архивации файла), то это окно при попытке его перетащить перестает перерисовываться и может пропасть совсем, я так понимаю, чтобы решить эту проблему нужно пихать GUI-обьекты в ядро.

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


Top
   
 Post subject:
PostPosted: Wed Sep 05, 2007 11:17 pm 
Offline
User avatar

Joined: Fri May 18, 2007 11:11 pm
Posts: 125
Mario79
Quote:
Зачем? Все гораздо проще - запускается приложение, рисует окно и запускает второй поток, который занимается непосредственно архивацией.

Это верно, но приложений не использующих второй поток, тоже хватает, сюда же кривые и зависшие проги. Я лично за то чтобы при событии перерисовки окна, имеющего рамки, рамки рисовались ядром, так окно не потеряется. А внутренние обьекты это дело приложения.
Maxis
Quote:
А что если программа(сервер окон) вызывает(один раз) некую системную функцию, которая делает так что бы ядро перенаправляло все события клавиатуры и мыши этому приложению и только ему. Это приложение создает и перемещает окна(или регионы), а так же их перерисовывает через селектор gs. Обычное приложение через IPC создает обьекты этого сервера и получает события от мыши и клавиатуры также через IPC.

ИМХО Возможно через специальное приложение и IPC можно попробовать реализовать такие фишки как перетаскивание обьектов (файлов, текстов и т.п.). Возможно единственное что потребуется от ядра, присваивать специальным программам - системным сервисам фиксированные PIDы, для обращений, ну может улучшить(ускорить) функции IPC.


Top
   
 Post subject:
PostPosted: Wed Sep 05, 2007 11:33 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
Alver
Quote:
Это верно, но приложений не использующих второй поток, тоже хватает, сюда же кривые и зависшие проги.

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


Top
   
 Post subject:
PostPosted: Wed Sep 05, 2007 11:43 pm 
Offline
User avatar

Joined: Tue May 08, 2007 12:44 am
Posts: 346
Нужно концептуально вынести интерфейс в отдельный поток. Создал окно - получил поток. И сразу все проблемы снимутся. Чем тупо копировать существующие решения, лучше один раз подумать головой.


Top
   
 Post subject:
PostPosted: Thu Sep 06, 2007 2:23 am 
Offline
User avatar

Joined: Thu Mar 01, 2007 4:16 pm
Posts: 426
> И сразу все проблемы снимутся.
Не смеши. Если код приложения кривой, то, например, при обращении потока, который занимается отрисовкой, к "проблемноку коду" может вызвать зависание этого потока. К примеру это может произойти из-за взаимной блокировки потоков при попытки синхронизации доступа к общим данным.

Это был оффтом. А по теме я думаю мое мнение известно. Я за то, что бы был отдельный сервер WM и быстрый IPC :-).

..bw


Top
   
 Post subject:
PostPosted: Thu Sep 06, 2007 7:22 am 
bw
Quote:
при обращении потока, который занимается отрисовкой, к "проблемноку коду" может вызвать зависание этого потока. К примеру это может произойти из-за взаимной блокировки потоков при попытки синхронизации доступа к общим данным.

Работа с проблемным кодом это головная боль программиста, а не ядра.
Криво написанный код может подвесить любую даже сверхнадежную систему. Даже QNX при желании можно подвесить (теоретически, оговариваюсь, чтобы меня не загрызли любители этой опрационки).


Top
   
 Post subject:
PostPosted: Thu Sep 06, 2007 12:02 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Maxis

Похожим образом работает Х в *никсах и без особых тормозов.
Видеопамять начинается с 0xFE000000 и у любого приложения есть доступ к этим адресам и без селектора gs.

Кстати в WinXP если программа надолго зависает система прячет её окно и подменяет его своим с такими же характеристиками чтобы пользователь мог его перемещать. В документации оно называется ghost window. Это потому что отрисовка рамок окна и код перемещения и изменения размеров выполняется программой где-то в глубинах DefWindowProc() - обработчиками сообщений WM_NCPAINT WM_NCACTIVATE WM_SIZING и т.д. Разница с Х только в том что там весь код работает в user mode а в Win частично в ядре. В Kолибри можно сделать ещё один поток в контексте ядра который будет работать как оконный сервер. Даже не обязательно писать его на асме. elf или pe dll модули очень хорошо подходят для разных экспериментов.


Top
   
 Post subject:
PostPosted: Thu Sep 06, 2007 3:20 pm 
Offline

Joined: Sun Feb 04, 2007 2:07 pm
Posts: 178
Mario79
Quote:
Зачем? Все гораздо проще

А не выльется ли такая простота в проблемы для разработчика программы? Не знаю на сколько проблематично было делать Tinypad.

Тогда может рекомендации какие-нибудь писать? Типа не стоит в одном потоке устраивать циклы потребляющие большие ресурсы или доступ к cdromy.

Gluk
Quote:
чтобы бедненькие кривые программки окна не растеряли?

Кфар, КФМ, ТиниПад это не бедьненькие и кривые программки, но и они тоже окна теряют если например попробовать обраться к cdromу

Serge
Quote:
в контексте ядра который будет работать как оконный сервер

в контексте ядра сцуко апасна.:)


Last edited by Maxis on Thu Sep 06, 2007 3:32 pm, edited 1 time in total.

Top
   
 Post subject:
PostPosted: Thu Sep 06, 2007 3:29 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Maxis

Cейчас работает в ядре и ничего...


Top
   
 Post subject:
PostPosted: Thu Sep 06, 2007 3:34 pm 
Maxis
Quote:
А не выльется ли такая простота в проблемы для разработчика программы? Не знаю на сколько проблематично было делать Tinypad.

Все проблемы находятся в мозгу программиста. У меня таких проблем нету.
Quote:
Кфар, КФМ, ТиниПад это не бедьненькие и кривые программки, но и они тоже окна теряют если например попробовать обраться к cdromу

Не люблю заявлять заранее, но в будущих версиях KFM я собирался переписать на второй поток процедуры копирования, перемещения и удаления. Сделать загрузку содержимого директории вторым потоком еще проще, просто никто таких просьб ранее не выдвигал. Ты первый, с чем тебя и поздравляю. :-)
А вообще при первом обращении к ATAPI устройству в Винде после вставки диска притормаживается вся система. Так что Колибри в этом отношении гораздо лучше себя ведет.


Top
   
 Post subject:
PostPosted: Thu Sep 06, 2007 3:38 pm 
Offline

Joined: Sun Feb 04, 2007 2:07 pm
Posts: 178
Serge
Сложность встроенного в ядро GUI постоянна, а вот если я правильно понимаю идею Xов то с каждым обьектом будет возрастать его сложность и ошибка в каком-нибудь из обьектов может задеть ядро.


Top
   
 Post subject:
PostPosted: Thu Sep 06, 2007 5:04 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Maxis

В Х только один вид объектов - окно как прямоугольная область на экране. Все графические элементы управления -виджеты программы рисуют сами. libGUI построена по таком же принципу. Вообще реализовывать контролы в оконном менеджере идея не очень хорошая.


Top
   
PostPosted: Wed Jan 02, 2008 2:57 pm 
Maxis wrote:
Вообще реализовывать контролы в оконном менеджере идея не очень хорошая

OMG. Хоть один здравомыслящий человек


Top
   
PostPosted: Mon Jan 14, 2008 7:50 pm 
Offline

Joined: Thu Dec 21, 2006 10:51 am
Posts: 88
ИМХО их лучше всего вообще сделать child окнами. Т.е. любой контрол - окно. Так в принципе всюду сделанно. Если ядро поддерживает окна больше и не надо и все контролы лежат в Dll. А реализовывать контролы в ядре ИМХО - идиотизм оно и так жрет 32М ОЗУ.

_________________
Если бы строители строили здания, так же как программисты пишут программы первый же залетевший дятел разрушил бы цивилизацию.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 44 posts ]  Go to page Previous 1 2 3

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


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