Board.KolibriOS.org

Official KolibriOS board
It is currently Wed Nov 25, 2020 2:11 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 249 posts ]  Go to page Previous 18 9 10 11 1217 Next

Ваше мнение об оптимизации GUI ядра
Оставить как было 24%  24%  [ 16 ]
Убрать только CGA и VGA, оставить VESA1.2 7%  7%  [ 5 ]
Оставить только VESA2-режимы (без изменения) 10%  10%  [ 7 ]
Разделить 24 и 32bpp графику в условно-компилируемые блоки 25%  25%  [ 17 ]
Оставить в ядре единственный 32bpp-режим 33%  33%  [ 22 ]
Total votes: 67
Author Message
PostPosted: Thu Oct 11, 2012 3:04 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1438
FireWall wrote:
А вообще-то надо скорее на встраиваемый рынок оглядываться.
Я не в курсе: там тоже везде 32-бита ?

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

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


Top
   
PostPosted: Thu Oct 11, 2012 8:18 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1438
еле нашел по последней ссылке
Code:
    switch (ucColorDepth)
    {
        case 8:
            usVESAModeNum = pModePrivate->Mode_ID_8bpp;
            break;

        case 16:
            usVESAModeNum = pModePrivate->Mode_ID_16bpp;
            break;

        case 32:
            usVESAModeNum = pModePrivate->Mode_ID_32bpp;
            break;
    }

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


Top
   
PostPosted: Thu Oct 11, 2012 8:50 pm 
Offline
Public Relations
User avatar

Joined: Mon Jun 07, 2010 12:01 pm
Posts: 1879
Всё верно, eBox тоже поддерживает 32 бита. Я тоже уже лет 10 не видел ни одного компьютера / монитора, который бы их не поддерживал.
Я проголосовал за "Оставить в ядре единственный 32bpp-режим"


Top
   
PostPosted: Fri Oct 12, 2012 10:20 am 
На всякий случай еще раз спрошу (может быть сути моего вопроса не уловили) - Что мешает вынести зависимую от глубины цвета (битности) часть кода в библиотеку/драйвер? Религия? Зачем ломать то что работает?


Top
   
PostPosted: Fri Oct 12, 2012 3:22 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1438
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 секунды.


Last edited by art_zh on Fri Oct 12, 2012 6:17 pm, edited 2 times in total.

Top
   
PostPosted: Fri Oct 12, 2012 5:59 pm 
Делаю два вывода:
1) Ломать не строить. Тем более альтернативы не предлагается никакой.
2) Нам лень и вообще некогда решать проблему, но мы все равно
Spoiler: Show
Quote:
Весь мир насилья мы разрушим
До основанья, а затем
Мы наш, мы новый мир построим, —
Кто был ничем, тот станет всем.

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


Top
   
PostPosted: Fri Oct 12, 2012 6:18 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1438
Теперь - о том, зачем оно мне надо и чего меня приперло транк потрошить.

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

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

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

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

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


Top
   
PostPosted: Fri Oct 12, 2012 7:25 pm 
art_zh wrote:
3ы конечно если 2/3 против, то и хрен с ним, пусть как раньше.

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

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

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


Top
   
PostPosted: Fri Oct 12, 2012 7:58 pm 
Offline
User avatar

Joined: Tue May 08, 2007 12:44 am
Posts: 353
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 показателен.


Top
   
PostPosted: Fri Oct 12, 2012 8:26 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Ребяты, поддержу Freeman'а. Сам обещаю вернуться к проекту после сдачи сессии (она у меня заключительная, не сдам - отчислят к чертям, такие дела).


Top
   
PostPosted: Sat Oct 13, 2012 1:10 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1438
Freeman wrote:
Вот тут мне показалось, что есть некоторая натяжка. Прикладникам вообще должно быть пофиг на аппаратную несовместимость, если нужные функции наличествуют.

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

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

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


Top
   
PostPosted: Sat Oct 13, 2012 2:14 am 
Offline
User avatar

Joined: Tue May 08, 2007 12:44 am
Posts: 353
art_zh wrote:
может, подскажешь, как выбрать в 4-й функции шрифт №5 ?

А где там аппаратная несовместимость? Особенность API, не более. Один чёрт -- переделывать.
Spoiler: Show
Ай-яй-яй, битов в регистре не хватило, айда на 64 бита переходить! :lol:


Top
   
PostPosted: Sat Oct 13, 2012 11:32 am 
Offline

Joined: Wed Sep 15, 2010 7:22 pm
Posts: 101
Цитата: "может, подскажешь, как выбрать в 4-й функции шрифт №5 ?"

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

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


Top
   
PostPosted: Sat Oct 13, 2012 12:14 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Quote:
динамически менять эти четыре шрифта для каждого слота
Заморочки какие. А если надо одновременно пять кеглей ?


Top
   
PostPosted: Sat Oct 13, 2012 1:18 pm 
Offline
Mentor
User avatar

Joined: Tue Jan 15, 2008 11:27 am
Posts: 756
Serge wrote:
А если надо одновременно пять кеглей ?

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 249 posts ]  Go to page Previous 18 9 10 11 1217 Next

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