Board.KolibriOS.org

art_zh wrote:А еще лучше - передавать все параметры в стеке.

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

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

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

пусть и не глубоко, но перспективно и по сабжу суть - это было бы весьма

art_zh wrote:Столь радикальные изменения подразумевают смену соглашения о порядке передачи параметров в ядро ?

угу. Ты один из вариантов уже предложил. Только не "смену", а новое, заточенное под...
Думаю может и еще кто то экспериментировал с целью оптимизации. НУ и примитивы вполне свои плюсы могут дать, хотя бы, как упрощения вызовов, легкость использования, объявления...
Имхо.

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

Хм, неожиданный поворот событий. Ну, я быстрые вызовы тоже не использую.

Ну вроде у всех было время проголосовать (сдается мне, что и у троллей тоже).

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

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

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

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

Давно пора. И 1.2 туда же.

art_zh
Я думаю в Kolibri-A Ты волен развлекаться как вздумается, чем тебе лично trunk как есть мешает?

Serge wrote:И 1.2 туда же.

Так ведь я 1.2 уже давно выпилил - смотри исходники ядра и лог SVN.

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

Mario wrote: чем тебе лично trunk как есть мешает?

тем, что он застрял на уровне 0.7.7.0, и с тех пор практически не развивается.

В бранчах развитие и идет -- в совершенно разные стороны!
За полтора года - два форка.
Еще полгода без заливки свежих прорывных наработок - и проект будет порван на лоскуты.

Имхо, оптимизация и унификация графической подсистемы,
новые шрифты (которые вроде бы как уже есть, и только у нас, но насмерть заоптимизированы на 32bpp),
новый блиттер (который тоже вроде бы как уже имеется, но пока что выглядит как-то чужеродно),
новый десктоп (который уже который год как на стадии концептуальной разработки) --

всё это если и не вдохнет в проект новую жизнь, то хотя бы приостановит трисекцию тела еще года на полтора-два.

Mario
Как я отстал от жизни !
Не, Артём прав, в морг и чем быстрее тем лучше.

Ну, ваше право ломать конечно. Проект по сути анархический. Однако я свое мнение высказал.

Serge
Вообще с учетом того что "32 must die" и твоего стремления к 64 битам - зачем тебе лично трогать транковое ядро? Моя не понимат!

Mario
64 бита дело настолько далёкое, что HW OpenGL кажется ближе. А разбухание ядра нельзя не заметить. Недавно было 140 Кб, теперь 160. Да и код будет проще.

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

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

В таком случае возможно компромисное решение - вынести код Vesa в подгружаемый драйвер. Нужно 32-бит загружаем один драйвер, нужно 24-бита загружаем другой. Совсем выбрасывать код для 24 бит это очень плохое решение. Колибри всегда позиционировалась как ОС для слабых компьютеров, а вот уже в этой категории процент видео с 24 бита существенно выше чем в общем потоке. Если выкинуть по сути мертвый код Vesa 1.2 было стратегически верно (все равно процедур переключения банков у нас не было для большинства видеокарт), то выкинуть 24-х битный код совсем -это стратегически проигрышное решение.

Mario
Выигрышная стратегия - ориентироваться на железо 15-ти летней давности ? Эти динозавры вымрут естественной смертью ещё за 5 лет, а то что останется будет выгоднее продать на аукционе коллекционерам и взять два новеньких компа. Это как с легковушками на Кубе.
Понятие "слабый компьютер" очень относительно.
Вот компу 9 лет: P4 2.6 ГГц 1Гб RAM + набор Радеонов 9600 х1600 hd4670, везде 32bpp.
Поэтому два года назад я голосовал за условную компиляцию, а сейчас поддерживаю п.5

Цитата: "Нужно 32-бит загружаем один драйвер, нужно 24-бита загружаем другой."

Это почти то, что я хотел когда-то предложить, только с добавлением 16-и битного варианта.

---- Добавление -----

P.S.

А вообще-то надо скорее на встраиваемый рынок оглядываться.
Я не в курсе: там тоже везде 32-бита ?