Board.KolibriOS.org

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

АМД, виа и интел - да, везде. NV- само собой.

насчет вортексов не уверен - подскажите кто работал с ебоксом. у них на сайте никаких доков нет.

еле нашел по последней ссылке так что у Ёгева претензий тоже не будет.

Всё верно, eBox тоже поддерживает 32 бита. Я тоже уже лет 10 не видел ни одного компьютера / монитора, который бы их не поддерживал.
Я проголосовал за "Оставить в ядре единственный 32bpp-режим"

На всякий случай еще раз спрошу (может быть сути моего вопроса не уловили) - Что мешает вынести зависимую от глубины цвета (битности) часть кода в библиотеку/драйвер? Религия? Зачем ломать то что работает?

Mario
На всякий случай повторюсь

1) я сделал быстрый векторный аналог шрифта 0 (5х7) и тестирую еще 2 новых шрифта (7х9 и 9х12), все шрифты могут быть и моноширинными и пропорциональными. Эти шрифты будут (все вместе) весить меньше, чем нынешние два, и активироваться сразу после вхождения в страничный режим, еще до монтирования рамдиска (экранные логи, ага).

2) парсер шрифтов насмерть завязан на 32bpp, переделывать его на 24bpp не хочу (и боюсь, что даже если захочу - не сумею).

3) в принципе шрифты 0 и 1 можно будет использовать со старыми GUI-функциями, но для полного раскрытия их потенциала лучше добавить новые GUI-сервисы чтобы отрисовка не тормозилась старыми форматами.

4) вывод текста будет еще быстрее, если рисовать в блиттере (не выходя из Ring3) с последующей отрисовкой всей картинки. Софтверный блиттер кривоват, но его очень легко можно "прям щас" соптимизировать на 32bpp, и на первом этапе пока даже GPU здесь не нужен, ускорение с заливкой через SSE будет мама не горюй. А для SSE нужно 16-байтное выравнивание.

5) если кто возьмется повторить шаги 1) -4) на 24bpp - я буду просто счастлив. Но ведь никто не возьмется.

6) ну и как будет выглядеть раздельно-компилированное ядро, в котором 32-битная графика летает, а 24 - ползёт? И кто будет разрабатывать софт под 2 разных (аппаратно-несовместимых) GUI?

7) переход на 32битную графику облегчает ядро почти на 3кб и выносит из GUI-функций кучу тормозных проверок.
В синем экране остаётся по большому счету только выбор разрешения экрана, который можно включить в батник компиляции ядра (вместе с выбором языка) и грузиться за 2 секунды.

Делаю два вывода:
1) Ломать не строить. Тем более альтернативы не предлагается никакой.
2) Нам лень и вообще некогда решать проблему, но мы все равно

Spoiler:

Весь мир насилья мы разрушим
До основанья, а затем
Мы наш, мы новый мир построим, —
Кто был ничем, тот станет всем.

сломаем работающую систему (которая еще может пригодится некоторым людям) и не будем делать всякие бранчи.
Логика непробиваемая конечно.

Теперь - о том, зачем оно мне надо и чего меня приперло транк потрошить.

1) все понимают, что надо что-то менять в ядре по-крупному, и кое-кто пытается это что-то менять.
Плохо то, что у каждого свои очень разные подходы. Ну и задачи тоже разные.
Анархосиндикалистов переубеждать бесполезно, а убеждать - почти никогда не получается.
Каждый сам знает как лучше. В результате старое ядро уже ни для чьих новых разработок не годится, легче новые велосипеды сочинять.
И если ядро ничем не скреплять, то очень скоро мы единый Проект порвём как бобик грелку.

2) а чем же его можно скрепить, чтобы еще хотя бы на год-два у всех разработчиков (и у прикладников в первую очередь!) появился общий интерес?
- очевидно, чем-то таким, что будет очень полезно в каждой из новых веток, и что сейчас сильно у всех тормозит.
Будет новая быстрая графика, более удобный и мощный GUI - всем станет интереснее работать, найдутся оригинальные решения старых заморочек.

3) ну хорошо, допустим сделал я себе в А-ветке зашибиськакую графику. И может даже адаптировал к ней кое-какие приложения из транка. Но выглядит это (скажем так) очень непрезентабельно. Все воняет нафталином, и пофиг что внутри реактивный движок.
Ну не дизайнер я, и красивые кнопки в окошках рисовать в лом. Но ведь есть в проекте и дизайнеры, и новые эстеты могли бы прийти - но все знают, что ядро не развивается и вообще проект нацелен на поддержку реликтовых монстров из прошлого века.
Дайте им набор шрифтов, эллипсы, прозрачность, скругленные уголки, ну и еще по мелочи разных ништяков - и будет красиво.
Ну и у меня конечно тоже все будет.

Вот как-то так, такая мотивация.

3ы конечно если 2/3 против, то и хрен с ним, пусть как раньше.

art_zh wrote:3ы конечно если 2/3 против, то и хрен с ним, пусть как раньше.

Тут пока что из высказавшихся как раз наоборот (не считая протухшее голосование) получается.
У каждого конечно свои корыстные цели, но когда они тупо урезают даже на 5% поддерживаемое железо - мне лично очень не нравится. Вот придет человек новый и ему нужна будет поддержка именно этого, а у нас ее не будет. Мы ему посоветуемся пользоваться старьем или выбросить свою рухлядь. Очень правильные советы с точки зрения советующих, но абсолютно не приемлемые со стороны просящего.

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

Как говорится ничего личного, только бизнес хобби.

art_zh wrote:И кто будет разрабатывать софт под 2 разных (аппаратно-несовместимых) GUI?

Вот тут мне показалось, что есть некоторая натяжка. Прикладникам вообще должно быть пофиг на аппаратную несовместимость, если нужные функции наличествуют. Понятно, что где-то без деталей не обойтись, и 24-битное изображение придется считать по 3 байта, а не по 4. Но в чем, объясните мне, разница в выводе текста системной функцией? Не с твоей стороны как ядерщика, а с моей -- как прикладника? Ну, номер шрифта другой. Ну, размеры другие. И всё.

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

Если вдруг выяснится, что добавление шрифтов дает новый API, может оказаться логичным текущее ядро вынести в legacy -- выпустить его наконец-то как ветку 0.7.8, а самим сосредоточиться на транковой 0.8 -- уже с новым API. А любителям старины, соответственно, предлагать 0.7.8, и через какое-то время даже получить статистику о ее фактической популярности относительно 0.8.

Если же в будущем хомячки внезапно начнут роптать об отсутствии 24-битной графики, -- что же, это новая реальность, которую придется осознавать заново, уже имея полноценные шрифты. К тому времени и практика по ним наработана будет, и полезность доказана, и всё остальное. Тогда-то и станет ясно, то ли портировать новые фишки из 0.8 в legacy-ветку, то ли наоборот, логичней и проще напрячься и вернуть поддержку 24-битной графики в 0.8. Ну, или будет некому, как обычно.

А без развития и выпуска новых версий -- никуда, только в сторону. Пример с Miranda NG показателен.

Ребяты, поддержу Freeman'а. Сам обещаю вернуться к проекту после сдачи сессии (она у меня заключительная, не сдам - отчислят к чертям, такие дела).

Freeman wrote:Вот тут мне показалось, что есть некоторая натяжка. Прикладникам вообще должно быть пофиг на аппаратную несовместимость, если нужные функции наличествуют.

ты вообще давно на фасме в Колибри кодил?
может, подскажешь, как выбрать в 4-й функции шрифт №5 ?

в остальном - согласен.

Mario
заботясь о 5% барахла сегодня, не упустить бы остальные 95% завтра.
и заметь - эти 5% все равно по-любому придется кормить вчерашними версиями.

art_zh wrote:может, подскажешь, как выбрать в 4-й функции шрифт №5 ?

А где там аппаратная несовместимость? Особенность API, не более. Один чёрт -- переделывать.

Spoiler:

Ай-яй-яй, битов в регистре не хватило, айда на 64 бита переходить!

Цитата: "может, подскажешь, как выбрать в 4-й функции шрифт №5 ?"

Но для 4-х шрифтов место есть (+ можно добавить возможность динамически менять эти четыре шрифта для каждого слота (ну дополнительные 4*4*256 байт для данных в ядре)).

P.S. Я на стороне Mario (аргументация позже, если вкратце - то я против радикальных полумер).

динамически менять эти четыре шрифта для каждого слота

Заморочки какие. А если надо одновременно пять кеглей ?

Serge wrote:А если надо одновременно пять кеглей ?

А для остальных 100500 кеглей должна быть отдельная системная функция. Потом 4-ю можно сделать устаревшей и постепенно отказаться от неё.
Нельзя приготовить яичницу, не разбив яйца. Нельзя сделать такой важный шаг, как оптимизация ядерной графики, не принеся что-либо в жертву. Что это будет - совместимость, скорость, удобство - это решать тому, кому под силу переделать ядро и кто это будет делать.

Spoiler:

Меня устроит как вынос кода в драйвер, так и в условно-компилируемые блоки.