Оптимизация ядерной графики

Kernel-side graphics support

POLL Ваше мнение об оптимизации GUI ядра

Total votes: 68
Оставить как было
24%
16
Убрать только CGA и VGA, оставить VESA1.2
7%
5
Оставить только VESA2-режимы (без изменения)
10%
7
Разделить 24 и 32bpp графику в условно-компилируемые блоки
26%
18
Оставить в ядре единственный 32bpp-режим
32%
22

  • Gluk

    потому что зачем.
  • Почему нет варианта вырезать всю графику из ядра полностью?
    Выделить в библиотеки и драйверы в смысле
  • Gluk wrote:почему в голосовании нет варианта "заменить графический на текстовый режим"?)
    Если перефразировать CleverMouse: "У нас уже есть одна операционная система, выглядящая как DOS, - это DOS" :lol:
  • yogev_ezra, то есть Колибри отличается от остальных ОС только своим интерфейсом?
    Если портировать гр. инт. Колибри под линукс, такой линукс станет Колибри?
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • И понесся флуд и оффтоп и возрыдали сирые форума сего...
  • Mario, в моем сообщении трижды упоминается Колибри, и дважды графика (см. заголовок темы), для двух строчек это достаточно много
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Твой первый пост отклоняется от темы в провоцирующее русло "Давайте отрежем Сусанину ногу...", а тема насчет оптимизации GUI, а не замены его на что-то. Колибри исторически сложилась (в наследии от Menuet) как ОС с GUI. Вопрос об отделении GUI от ядра уже обсуждался в других темах форума.

    Я думаю не имеет смысла опять все в одну кучу сваливать. В конечном счете если бы кто-то действительно хотел сделать Колибри с текстовым режимом вместо GUI, то он бы это сделал или нет? :?:
  • art_zh wrote:А на какой номер новые примитивы
    не только примитивы, но и саму GUIшку "вынес" бы в виде отдельного апи, например, типа int 0x50
    (вот в биосе int 0x10 существует целевым назначением и это хорошо ведь).
    Зачем все на 40 все лепить?
    Куда их экономить то, вектора эти, не вижу прока.
    А вот тематическо-функциональное разделение мне кажется уместным, особенно в свете новых технологий, редакций, принципиально нового движка и т.д...
    Дабы не было крика про поддержку "старого" GUI, вещи касательно 40вых дел можно ведь и не трогать, оставив на "пока", вполне возможно атрофируются сами со временем..., как проигравшая технология GUI.
  • VaStaNi, быстрые системные вызовы sysenter и syscall имеют только одну точку входа.
    Кроме того, вы, похоже, не прочли или не осознали пост, на который отвечаете, - в посте речь шла о создании нескольких новых примитивов, а отнюдь не о переносе или замене существующих.
    Сделаем мир лучше!
  • VaStaNi
    Столь радикальные изменения подразумевают смену соглашения о порядке передачи параметров в ядро ?
    Если нет - тогда зачем менять шило на мыло? int40 - это пусть забавный, но все-таки не самый идиотский вариант.

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

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

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

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

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

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

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

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

    Users browsing this forum: No registered users and 25 guests