Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Чт авг 16, 2018 1:57 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 249 сообщений ]  На страницу Пред. 16 7 8 9 1017 След.

Ваше мнение об оптимизации GUI ядра
Оставить как было 24%  24%  [ 16 ]
Убрать только CGA и VGA, оставить VESA1.2 8%  8%  [ 5 ]
Оставить только VESA2-режимы (без изменения) 9%  9%  [ 6 ]
Разделить 24 и 32bpp графику в условно-компилируемые блоки 26%  26%  [ 17 ]
Оставить в ядре единственный 32bpp-режим 33%  33%  [ 22 ]
Всего голосов: 66
Автор Сообщение
 Заголовок сообщения: Re: Оптимизация ядерной графики
СообщениеДобавлено: Пт май 20, 2011 8:22 am 
Не в сети
Аватара пользователя

Зарегистрирован: Пн апр 16, 2007 6:38 pm
Сообщения: 1222
почему в голосовании нет варианта "заменить графический на текстовый режим"?)

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!


Вернуться к началу
 Заголовок сообщения: Re: Оптимизация ядерной графики
СообщениеДобавлено: Пт май 20, 2011 9:54 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1292
Gluk

потому что зачем.


Вернуться к началу
 Заголовок сообщения: Re: Оптимизация ядерной графики
СообщениеДобавлено: Пт май 20, 2011 10:01 am 
Не в сети

Зарегистрирован: Вс ноя 04, 2007 2:46 am
Сообщения: 390
Почему нет варианта вырезать всю графику из ядра полностью?
Выделить в библиотеки и драйверы в смысле


Вернуться к началу
 Заголовок сообщения: Re: Оптимизация ядерной графики
СообщениеДобавлено: Пт май 20, 2011 10:01 am 
Не в сети
Public Relations
Аватара пользователя

Зарегистрирован: Пн июн 07, 2010 12:01 pm
Сообщения: 1879
Gluk писал(а):
почему в голосовании нет варианта "заменить графический на текстовый режим"?)

Если перефразировать CleverMouse: "У нас уже есть одна операционная система, выглядящая как DOS, - это DOS" :lol:


Вернуться к началу
 Заголовок сообщения: Re: Оптимизация ядерной графики
СообщениеДобавлено: Сб май 21, 2011 4:16 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пн апр 16, 2007 6:38 pm
Сообщения: 1222
yogev_ezra, то есть Колибри отличается от остальных ОС только своим интерфейсом?
Если портировать гр. инт. Колибри под линукс, такой линукс станет Колибри?

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!


Вернуться к началу
 Заголовок сообщения: Re: Оптимизация ядерной графики
СообщениеДобавлено: Сб май 21, 2011 4:31 pm 
И понесся флуд и оффтоп и возрыдали сирые форума сего...


Вернуться к началу
   
 Заголовок сообщения: Re: Оптимизация ядерной графики
СообщениеДобавлено: Сб май 21, 2011 5:13 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пн апр 16, 2007 6:38 pm
Сообщения: 1222
Mario, в моем сообщении трижды упоминается Колибри, и дважды графика (см. заголовок темы), для двух строчек это достаточно много

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!


Вернуться к началу
 Заголовок сообщения: Re: Оптимизация ядерной графики
СообщениеДобавлено: Сб май 21, 2011 7:48 pm 
Твой первый пост отклоняется от темы в провоцирующее русло "Давайте отрежем Сусанину ногу...", а тема насчет оптимизации GUI, а не замены его на что-то. Колибри исторически сложилась (в наследии от Menuet) как ОС с GUI. Вопрос об отделении GUI от ядра уже обсуждался в других темах форума.

Я думаю не имеет смысла опять все в одну кучу сваливать. В конечном счете если бы кто-то действительно хотел сделать Колибри с текстовым режимом вместо GUI, то он бы это сделал или нет? :?:


Вернуться к началу
   
 Заголовок сообщения: Re: Оптимизация ядерной графики
СообщениеДобавлено: Пн май 23, 2011 8:38 am 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
art_zh писал(а):
А на какой номер новые примитивы
не только примитивы, но и саму GUIшку "вынес" бы в виде отдельного апи, например, типа int 0x50
(вот в биосе int 0x10 существует целевым назначением и это хорошо ведь).
Зачем все на 40 все лепить?
Куда их экономить то, вектора эти, не вижу прока.
А вот тематическо-функциональное разделение мне кажется уместным, особенно в свете новых технологий, редакций, принципиально нового движка и т.д...
Дабы не было крика про поддержку "старого" GUI, вещи касательно 40вых дел можно ведь и не трогать, оставив на "пока", вполне возможно атрофируются сами со временем..., как проигравшая технология GUI.


Вернуться к началу
 Заголовок сообщения: Re: Оптимизация ядерной графики
СообщениеДобавлено: Пн май 23, 2011 2:58 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1611
VaStaNi, быстрые системные вызовы sysenter и syscall имеют только одну точку входа.
Кроме того, вы, похоже, не прочли или не осознали пост, на который отвечаете, - в посте речь шла о создании нескольких новых примитивов, а отнюдь не о переносе или замене существующих.

_________________
Сделаем мир лучше!


Вернуться к началу
 Заголовок сообщения: Re: Оптимизация ядерной графики
СообщениеДобавлено: Пн май 23, 2011 4:12 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1292
VaStaNi
Столь радикальные изменения подразумевают смену соглашения о порядке передачи параметров в ядро ?
Если нет - тогда зачем менять шило на мыло? int40 - это пусть забавный, но все-таки не самый идиотский вариант.

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

CleverMouse
fastcall и syscall оказались малоэффективной заменой для int40, их можно безболезненно убрать из макроопределения mcall. А потом - и из ядра. Полгода ругани - и всё забудется...
Для syscall заметное (до трех раз!) ускорение входа в Ring0 достигается только если не переключать стек задачи, и не использовать ecx для передачи параметров. А еще лучше - передавать все параметры в стеке.

Но это, в сущности, и определяет некий новый API-механизм, к которому можно будет приклеить и соответствующий fastcall, и int50.


Вернуться к началу
 Заголовок сообщения: Re: Оптимизация ядерной графики
СообщениеДобавлено: Пн май 23, 2011 6:03 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
art_zh писал(а):
А еще лучше - передавать все параметры в стеке.

Но это, в сущности, и определяет некий новый API-механизм, к которому можно будет приклеить и соответствующий fastcall, и int50.
ну вот и чудненько. Если еще кто по графике спец и поддержит, то просуммировав пройденный опыт можно надеяться, что удастся
art_zh писал(а):
глубоко продумать альтернативный механизм, иначе можно что-то еще смешнее накостылять.
пусть и не глубоко, но перспективно и по сабжу суть - это было бы весьма
art_zh писал(а):
Столь радикальные изменения подразумевают смену соглашения о порядке передачи параметров в ядро ?
угу. Ты один из вариантов уже предложил. Только не "смену", а новое, заточенное под...
Думаю может и еще кто то экспериментировал с целью оптимизации. НУ и примитивы вполне свои плюсы могут дать, хотя бы, как упрощения вызовов, легкость использования, объявления...
Имхо.


Вернуться к началу
 Заголовок сообщения: Re: Оптимизация ядерной графики
СообщениеДобавлено: Пн май 23, 2011 9:18 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3949
Поддерживаю идею. Быстрые вызовы дают слишком мизерные улучшения. Может при их появлении и был смысл, но с тех пор микроархитектуры сильно поменялись.


Вернуться к началу
 Заголовок сообщения: Re: Оптимизация ядерной графики
СообщениеДобавлено: Вт май 24, 2011 2:07 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1611
Хм, неожиданный поворот событий. Ну, я быстрые вызовы тоже не использую.

_________________
Сделаем мир лучше!


Вернуться к началу
 Заголовок сообщения: Re: Оптимизация ядерной графики
СообщениеДобавлено: Ср окт 10, 2012 11:36 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1292
Ну вроде у всех было время проголосовать (сдается мне, что и у троллей тоже).

Пора принимать трудное решение - переходить исключительно на 32-битную графику, или оставить всё блин как есть.

Пока что прозвучал только один (весьма убедительный и очень авторитетный) консервативный довод.

Да, есть эмуляторы.
И еще не везде выкинули старые надежные платформы (EGA не видел, но VGA в натуре еще есть!!), на которых только ДОС и Колибри можно реально запустить.

Ну и что, так и будем ждать когда они совсем сдохнут, или все-таки оглянемся вперёд?


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 249 сообщений ]  На страницу Пред. 16 7 8 9 1017 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB