Modest — разработка открытого движка HTML рендера на «голом» Си

    Всем привет! Меня зовут Александр Борисов и я разрабатываю Modest — открытый движок HTML-рендера на «голом» Си без использования внешних зависимостей (далее движок). Сразу хочется пояснить, что значит «без внешних зависимостей» — весь код пишется с нуля, код нигде не заимствован.

    После моей последней публикации прошло немало времени. За это время многое изменилось и я хочу поделиться с вами достижениями в разработке.

    О Проекте


    Основная идея проекта заключается в его неприхотливости, а это значит:

    — Возможность скомпилировать/установить на любом устройстве где есть Си
    — Скорость работы
    — Минимально возможное потребление ресурсов

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

    Обо всём по порядку


    Возможность скомпилировать/установить на любом устройстве где есть Си

    Идея заключается не только в том, чтобы иметь возможность скомпилировать/установить на любой железке, ведь Си есть практически везде, но и иметь возможность подключить движок к другому языку программирования раскрывая для этого языка полный спектр API движка. Говоря проще, иметь возможность легко сделать binding (обвязку) для вашего языка программирования.

    Что же нам дадут обвязки на других языках?

    Простое и понятное API движка даст нам возможность напрямую работать с HTML Tree, CSS, Render Tree/Layers (Дерево отрисовки/слои) через наш любимый язык программирования, без использования JavaScript.

    На практике это будет означать следующее:

    1. Высокая скорость доступа, создания, изменения элементов/слоёв.
    2. Лёгкость создания интерфейсов, игр, приложений через знакомый вам язык программирования с использованием всех возможностей HTML/DOM Events/CSS.

    Более того, я пошёл дальше и протестировал следующее
    Сразу оговорюсь, что это лишь эксперимент, зачем оно в жизни так может понадобиться не ясно, но сделать можно.

    1. Берём готовую обвязку для Perl и меняем её
    2. Добавляем в обработку тега script тип Perl: <script type="Per">
    3. Разбираем хтмл в Perl
    4. Когда парсер встречает тег script с типом Perl то он выполняет этот код в текущем интерпретаторе


    Скрипт на Perl получился такой:
    use utf8;
    use strict;
    use warnings;
    
    use HTML::MyHTML::Fun;
    
    my $html = q~
    <div>
    	<span>text</span>
    </div>
    
    <script type="Perl">
        # $MyHTML_TREE global var
    	my $nodes = $MyHTML_TREE->get_elements_by_tag_name("span");
    	
    	foreach my $node (@$nodes) {
    		$node->delete($MyHTML_TREE);
    	}
    </script>
    
    <span>footer</span>
    ~;
    
    # parse HTML
    my $myhtml = HTML::MyHTML->new(MyHTML_OPTIONS_DEFAULT, 1);
    my $tree = $myhtml->new_tree();
    
    $myhtml->parse($tree, MyHTML_ENCODING_UTF_8, $html);
    
    

    Результат обработки:

    <html>
    	<head>
    	<body>
    		<div>
    		<script type="Perl">
                <-text>: ...
    		<span>
    			<-text>: footer
    


    Скорость работы

    Ждать никто не любит, а я особенно. Один из ключевых моментов разработки — это обеспечение быстрой обработки той или иной части HTML/CSS/Render. К примеру, среднее время обработки типичной хтмл страницы равна 0.001 сек., то есть 1мс, а это 1000 страниц в секунду. Разбор CSS файла bootstrap и его селекторов обходится в 1.5мс. На данный момент мы имеем самый быстрый полноценный парсер HTML и CSS. И это не предел.

    Минимально возможное потребление ресурсов

    Если, со скоростью работы всё более или менее понятно, то вот с потреблением ресурсов всё значительно сложнее. Спецификации обычно «советую/требуют» всё хранить в памяти. Точнее не так, все рассуждения идут так, словно у нас уже всё под рукой, всё создано.

    В чём же это проявляется?

    Возьмём, к примеру, спецификацию CSS синтаксиса. Она нам говорит, что мы должны создать токены на каждый символ/последовательность символов и разложить их по группам, создать группы токенов. Говоря прямо, — мы должны создавать токены на каждый символ не входящий в общие правила токенизации (delim-token), а так же на каждые: ";", ":", "(", ")", "," и прочие, полный список правил можно увидеть тут.

    Согласитесь, что создавать токен на каждую запятую или точку с запятой довольно расточительное занятие. При этом, стоит отметить, что в правилах токенизации символов присутствуют условия вроде таких: имея текущий символ посмотрите, что следующие Н равны Х, иначе создайте Y.

    Позже, когда все токены будут созданы их нужно разобрать. То есть, из последовательности созданных токенов выделить группы. И именно эти группы используют модули CSS, которых не мало.

    Вот тут и начинается интересное. Мы должны полностью соответствовать спецификации, но сделать так чтобы не создавать токены на каждый чих. Не мало читая спецификации и раздумывая о том, как не создавать «лишних» токенов и экономить память, сформировались следующие условия:

    1) Разбор CSS должен поддерживать куски (chunks), то есть разбор потока (stream parsing). Этого спецификация не требует, но это важно для дальнейшего развития. 

    Именно из-за этого условия мы не знаем когда закончится поток данных, для нас он бесконечный. То есть, в любой момент времени мы гарантированно имеем только текущий и все предыдущие символы, но понятия не имеем что дальше, и соответственно не можем посмотреть по условию «если пришел символ А то смотрим есть ли дальше открывающая скобка».

    2) Не создаем все токены, создаём только один, который в дальнейшем будет постоянно перезаписываться. В любой момент времени, мы имеем только один токен, текущий токен. Соответственно, мы не можем посмотреть предыдущий или следующий токен, их нет. По началу это казалось проблемой, так как в спецификации не мало условий вроде «если пришел токен Х, то смотрите следующие три токена, и если они не H то тогда Y».

    Всё выше описанное реализовано в MyCSS. Уже сейчас MyCSS успешно разбирает селекторы и некоторые CSS свойства потребляя минимальное количество памяти. Соответственно, если мы постоянно не ходим за «кусочками» памяти, то и скорость у нас возрастает значительно.

    И в довесок ко всему выше сказанному, парсер MyCSS сохранил понятность, гибкость, лёгкость в дальнейшей разработке модулей к нему.

    К слову, в MyHTML всё реализовано ровно наоборот. Там упор на создание токенов и дальнейшую работу с ними. Это наглядно показывает, что в таком деле как написание отрисовщика HTML нельзя использовать «серебряную пулю». Везде нужен индивидуальный подход. Ну, и конечно же, всё это нельзя создать без полного понимания спецификаций и того, что в спецификации требуют.

    Текущая структура проекта


    На данный момент реализованны следующие части проекта:

    1. MyHTML — парсер HTML
    2. MyCSS — парсер CSS (Selectors, Values, Namespace, Property)
    3. MyFONT — парсер .otf и .fft файлов. Получение метрик для глифов: width, height, baseline, x-height и прочие. Стоит отметить, что тут речь идёт о размерах символов, как в браузерах. Смотрите пример.

    О селекторах


    Писать отдельную статью о селекторах я не вижу смысла, а похвастаться хочется. Уже сейчас можно использовать селекторы для нахождения нод в дереве:

    div > :nth-child(2n+1):not(:has(a))
    

    или списком церез запятую

    .header, :nth-child(2n+2 of div:not([id])) >> :not(:has(> [class ~= "bukabyaka" i]))
    

    Работают они довольно шустро. Выше, первый, приведенный селектор на типичной статье хабра отрабатывает за 0.00015 сек., то есть за 0.15мс, и находит 247 элементов. В это время входит разбор CSS, разбор и создание селекторов, поиск по дереву. Можно создать селектор заранее и использовать многократно, что позволит уменьшить время работы.

    На данный момент, поддерживаются все селекторы из спецификации четверной версии (Selectors 4) за исключением:

    1. Всех псевдо-элементов (pseudo-elements)
    2. :dir, :lang, :scope, «Time-dimensional Pseudo-classes», :drop
    3. :nth-column, :nth-last-column

    Первые и вторые будут разрабатываться/добавляться по мере разработки движка. До третьих руки не дошли, но, конечно же, они так же будут реализованы в ближайшем будущем.

    Будущее проекта


    Оно (будущее) видится очень светлым. Проектом занимаюсь в рабочее время. Мой работодатель разрешил мне тратить всё рабочее время на проект, конечно, если что-то просят сделать приходится отвлекаться.

    Сейчас, я приступил к созданию дерева отрисовки (Render Tree, Layers). То есть, уже в недалёком будущем можно будет получать рассчитанные метрики хтмл нод, такие как width, height, font-size, border-color и прочие.

    Идей очень много, а «бензина» во мне ещё больше! Спасибо за внимание!

    P.S.: Если у кого-нибудь возникнет желание помочь/поучаствовать в реализации проекта то можно смело писать на почту.

    Ссылки:

    » Modest
    » Примеры Modest
    » Примеры MyHTML
    » Примеры MyCSS
    » Обвязка MyHTML для Perl
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 81

      +1
      Не совсем понятно, что в итоге делает Ваш парсер.
      оффтопик
      Если Вам интересно, я делаю поисковую систему по html кодам, имеется база 10+млн страниц. Удобно, что сразу в базе.
        0
        Привет!

        Это уже не парсер. А отрисовщик (Render) HTML. То есть, в итоге он будет считать хтмл и отдавать результат расчетов как современные браузеры. Он включает в себя несколько парсеров (HTML, CSS, FONT и ещё будут добавляться) + разные возможности CSS модулей.

        Спасибо! Для тестирования я использую commoncrawl.org — там можно получить миллиарды хтмл страниц с разными кодировками и языками.
        +3
        Отличный проект, поддержим автора!
          0
          Спасибо!
          +3
          Я так понимаю всё это сулит нам долгожданный браузер, способный держать больше 3х открытых вкладок, не вешая проц и не съжирая 10 гигов оперативки?
            +5
            Да, именно так, это одна из основных целей.
              +10
              К сожалению когда вы полностью реализуете совместимость с web-kit вы поймете, что вся память уходит на dom, и на скрипты.
                +5
                Хорошо, давайте посмотрим что получится в итоге.
                  –7
                  Попробуйте не замахиваться на ВЕСЬ вебкит, в 99% случаев весь мир использует библиотеки вида jquery, достаточно будет добавить в них поддержку именно вашего браузера и большинству этого будет достаточно.

                  Лучше пусть будет быстро!

                  p.s. реализуйте в стандарте понятие пакетного менеджера, чтобы была возможность устанавливать общепринятые библиотеки на стороне клиента (и загружать их однократно, даже если они требуются в нескольких вкладках одновременно), т.е. владелец веб-сайта указывает свой репозитарий, с хешами пакетов, и на страницах указывает что то типа
                  import jquery < 18.2 >= 11.3;
                  а браузер загружает ее однократно и хранит в кеше, зато если понадобится другому сайту — достаточно будет идентификатора, версии и хеша, чтобы использовать уже загруженную (и проинициализированную)
              –2
              Хм, Firefox 24 (ESR) + NoScript, 409 вкладок, 913M/372M (virt/res), загрузка ЦП < 10%, ЧЯДНТ (кроме пользования устаревшей версии браузера)?
                +7
                NoScript
              0
              Одним из конечных продуктов проекта сделать более быстрый HTML браузер, какие еще есть варианты вашего проекта? Не спроста же ваш работодатель так щедр
                +1
                В статье я пишу, что браузер это одно из направлений, он как бы логично «вытекает» из этой разработки.
                Встраиваемость — это очень важный аспект разработки. Потому и нет зависимостей. Ведь HTML и DOM Events можно использовать не только в браузере. Благодаря тому, что он написан на Си его можно прикрутить к «любому месту». Соответственно получив полнофункциональный рендер хтмл на своем любимо языке программирования. То есть, тут отпадает JavaScript, ведь вы можете напрямую пользоваться АПИ движка. Можно использовать для создания интерфейсов, игр, да чего угодно в своей программе.

                Работодатель у меня действительно хороший. Он адекватный и слушает, а главное слышит, то что ему говоришь.
                  0
                  Все же без JS как связующего слоя между HTML5 API (Web Gl, Media Source Extension, Canvas) данный браузер будет «не очень» работать с сайтами которые все же имеют малейшие намеки на динамический контент. Или, к примеру, планируется интерпретатор JS в какой то нативный для платформы скриптовый язык? Что в вашем понимании есть АПИ движка?
                    +2
                    Вы немного не поняли. JS будет в браузере, как же без него. Речь о том, что движок можно прикрутить к вашей программе и использовать все его возможности напрямую, минуя JS. Тут речь не о браузере. А именно о том, чтобы использовать возможности HTML/DOM Event/CSS в какой либо программе. То есть, не для рисования страницы хабра, а для создания элементов на хтмл, интерфейсов и прочего.
                    +1
                    А почему вы стесняетесь назвать имя то? Он даже на хабре есть https://habrahabr.ru/users/Ashmanov/
                      +1
                      Имени у меня не спрашивали, но и секрета тут нет. Работаю я в Крибрум, сижу на одном этаже между Инфовотч и Ашманов и Партнеры. Из чего так же можно сделать вывод, что главные у нас Игорь Ашманов и Наталья Касперская.
                      0
                      Кстати, да, для встраиваемых систем (Техже телевизоров) и «Интернета вещей» — Идеальный вариант.
                      В своё время так сделали разрабы Opera — движок их браузера был весьма шустрый и досихпор встречается в некоторых телеках и плеерах (У которых начинка «так себе»)
                        +1
                        Вместе с JerryScript :)
                          0
                          Спасибо за наводку!
                            0
                            Есть ещё Duktape, крутая штука для встраивания.
                      0
                      Интересно. По скорости HTML::MyHTML уделывает Mojo::DOM почти в 40 раз. Вот сравнить бы ещё на корректность построения дерева…
                        0
                        Если Mojo::DOM полностью проходит тесты на построение дерева то можно не беспокоиться о правильности построения дерева.
                          0

                          Насколько помню Mojo написано на Perl без использования библиотек на Си.

                            0
                            Да, по-хорошему надо сравнивать с кем-то, у кого парсер тоже сишный. Самый быстрый из перловых модулей, наверное, HTML::Bare, с сишным ядром. Но и он проигрывает HTML::MyHTML. Правда, не в 40 раз, а всего в два, но тоже неплохо :)
                              0
                              Удивительно тут то что HTML::Bare нельзя назвать html парсером, там нет правил построения дерева. Более того не понятно какой элемент чем является.

                              Вот взять такой хтмл:
                              <svg><desc><style><a>
                              

                              Итог должен быть такой:
                              <html>
                              	<head>
                              	<body>
                              		<svg:svg>
                              			<desc:svg>
                              				<style>
                              					<-text>: <a>
                              


                              То есть, тег в конце является текстом, это важно. При этом, парсер HTML::Bare ещё и в два раза отстает от полноценного MyHTML. Вот так и пишут всякое, а называют HTML парсерами, хотя они с ними и рядом не стояли.
                                0
                                У них совсем другие задачи. 80% из них выглядят как-то так: «а дай-ка мне значение href у a, который находится внутри дива с классом foo» или «найди все p у который есть атрибут bar с любым значением». Ещё 20% — другая мелочёвка, с которой они тоже вполне справляются.
                                  0
                                  Возможно да, но из примера выше ясно, что тот же тег «a» они не верно разберут и соответственно выдадут неверный ответ. Собственно, всё тоже самое можно делать и в myhtml или же использовать селекторы из modest (надо бы их к перлу прикрутить)
                                    0
                                    >всё тоже самое можно делать и в myhtml

                                    Вот как раз и смотрю :) Но что сразу в минус (это к качеству работы уже отношения не имеет): нет в CPAN. Да и название такое там могут завернуть…

                                    Что касается разбора, то я плотно работал только с HTML::Tree и Mojo::DOM.

                                    Первый вообще пример разбирает так:
                                    html(tag)->{ [head(tag)->style(tag)], [body(tag)->a(tag)] }.

                                    Второй так:
                                    svg(tag)->desc(tag)->style(tag)->a(tag)

                                    Но это никак до сих не мешает решать задачи типа тех, про которые писал. Чуть посложней, конечно, но что-то вроде. Объёмы перелопачиваемых данных — до 10 тысяч разных страниц в сутки, на явные некорректности не нарывался. Может и повезло, конечно :)
                                      0
                                      cpan: https://metacpan.org/pod/HTML::MyHTML

                                      В хтмл есть условия для каждого тега как и куда ему нужно быть вставленным в хтмл дерево или быть выбращенным при разных условиях. Если вы хотите итог такой же как в любом современном браузере то нужно использовать полноценный парсер, а если вам это не важно то любой простой токенизатор который находит элементы <...>.
                                        0
                                        Ой, что-то прошлёпал. Странно, вроде у них с неймингом построже было. Во всяком случае когда я своё пытался приткнуть заставляли переделывать.

                                        Как в браузере не надо. Но токенизатора не хватит, кроме поиска и манипуляции с деревом нужны. И вставка, и удаление, и замена атрибутов. Но в любом случае скорость MyHTML — это киллер фича даже в этом случае :)
                                          0
                                          В сишной версии есть всё связанное с работой с деревом: добавление, удаление, изменение. Катастрофически не хватает времени доделать обвязку для перла.
                          0
                          Сейчас, я приступил к созданию дерева отрисовки (Render Tree, Layers). То есть, уже в недалёком будущем можно будет получать рассчитанные метрики хтмл нод, такие как width, height, font-size, border-color и прочие.


                          Т.е. прямо сейчас MyCSS нельзя использовать как замену LibCSS для получения рассчитанных color/background-color произвольной ноды?
                            0
                            Нет, сейчас нельзя. Сейчас, можно получить width, height (CSS). К сожалению я не могу сейчас позволить себе засесть за разработку всех свойств CSS. Хотя и делать там особо нечего. Мною было принято решение делать всё по мере надобности. Или же пока к проекту не подключится кто-то ещё кому можно объяснить как легко можно добавить обработчик того или иного свойства.

                            Могу вас заверить, что до момента появления поддержки всех CSS свойств осталось не так много времени.
                              0
                              А возможность добавлять свои свойства и обработчики без правки кода библиотеки — это будет?
                              В libcss это всё захардкорено внутри неё и нельзя просто так добавить что-то своё.

                              И это всё будет внутри mycss? Или в вашем проекте это уже часть modest?
                                0
                                Я размышляю об этом, и склоняюсь к мысли сделать для своих свойств какой-то префикс, вроде --mycss-*. Вот тогда можно будет динамически добавлять свои свойства и обработчики к ним. Но, меня остановили рассуждения о том, зачем это может понадобиться? Для чего это потом использовать? Я так и не придумал.

                                В Modest вшит myhtml и mycss. Но поддерживаются они оба, то есть код mycss идентичен коду его же в modest. В будущем они разойдутся (это надо для движка modest, без этого никак), но совместимость сохранится. Можно будет спокойно использовать код написанный на mycss в modest. Разработка специально идёт так чтобы можно было использовать парсер хтмл и цсс отдельно.
                                  0
                                  Одного только mycss (без modest) хватит для целей, что бы получить, например, цвет для любой ноды? Как я сейчас использую LibCSS для этого.
                                  Там у него куча сalback'ов для работы с DOM деревом.
                                  Я это имею ввиду.
                                    0
                                    Т.е. получить набор стилей для конкретной ноды с учётом всех приоритетов и инлайновых стилей.
                                      0
                                      Да, всё это можно будет получить для конкретной ноды. Но всё это уже не mycss, а modest. Именно над этим и работаю. Создаю Render Tree.
                                      0
                                      Да, хватит, но тут нужно уточнить, свойства какие уже посчитанные или то, что указал пользователь в css файле?
                                      То есть, font-size можно иметь посчитанный (он наследуется) или же тот что указали в css? В первом варианте это будет всегда число в пикселях (рассчитанное), а во втором то что указал пользователь: 10%, 30em и так далее.

                                      В данный момент я работаю над поддержкой свойств border*, margin*, padding*, font*, display и прочие. Как я уже и говорил, добавляю свойства по мере надобности проекту Modest.
                              +1
                              На современных HTML страницах много JavaScript, а во все более набирающих популярность SPA их ОЧЕНЬ МНОГО, на порядок больше CSS кода и производительность в таком случае упирается в производительность JS (а точнее, зачастую в скорость манипуляции DOM через JS). Неужели вы планируете поддерживать JavaScript тоже? И даже если так, то затупы JS сведут все оптимизации с парсингом HTML/CSS в никуда.
                                +2
                                Привет! JS это отдельная, большая тема для разговора. В предыдущих статьях я писал, что планирую взять сторонний движок, надо понимать, что если я продолжу разработку один то меня просто не хватит на всё, это не реально. Пока я буду разрабатывать одну часть другая просто устареет. В спецификациях всё активно обновляется.

                                На данный момент я склоняюсь к использованию стороннего JS движка. Но решение я оттягиваю до последнего. Я жду решения людей которые в корне смогут изменить скорость разработки проекта. Соответственно будет и ответ на вопрос как оно там с JS.

                                Затупы JS — это затупы JS, ничего они не сведут на нет.
                                  +9
                                  Дело в том, что SPA приложения практически не загружают HTML c сервера — они его генерируют через JS. Т.е. результирующую страницу вы не получите, пока не отработает весь JS код. В результате получается, что 90 процентов время загрузки страницы тратится на исполнение JS и его взаимодействию с DOM. Создание современного движка JS с поддержкой фич вроде async и генератов видится мне нетривиальной задачей даже для опытной команды. А подключение любого из современных движков JS будет и сложно и неэффективно, т.к. все они (SpiderMonkey, Edge, V8) разработаны с учетом использования из С++ кода и сами на нем же, очевидно, и написаны.

                                  Так что я искренне вам рекомендую посмотреть на https://github.com/servo/servo
                                    +3
                                    Речь о том, что JS сам по себе не разбирает CSS или HTML и прочие компоненты, если конечно кто-то не использует разбор CSS/HTML написанный на JS, тут я ничего не сделаю.
                                    А так, да, буквально все кто создает JS движки создают их под себя, тут вы правы.

                                    Мне часто рекомендуют посмотреть на серво, более того даже звали туда работать. Но, к сожалению, или счастью, вынужден отказать.
                                    Я вас услышал, спасибо.

                                    Есть интересная тенденция, каждый раз когда я приступаю к разработке какого либо компонента мне говорят, что ничего не выйдет, ну или я не понимаю куда лезу. Проект открытый, каждый может увидеть что из этого выйдет.
                                      0
                                      У проектов предназначение все же разное как я вижу. Этот больше для эмбебеда и скорости парсинга, servo — надежность и использование GPU.
                                      Например собрать servo на десктопе это одно, а под Ubuntu Phone\Sailfish\Pi\Emscripten\Кофеварку — совсем другое.
                                      Про отсутствие JS, автор так же имеет ввиду встраевоемое применение, на например хром через electron встроен в десктопный Slack клиент.
                                      Тут ты сам волен делать все что хочешь и взаимодействие напрямую может быть плюсом.
                                  +1
                                  Да лучше поучить Rust и присоединиться к проекту Servo https://servo.org/
                                    0
                                    Из скриптов работа с DOM возможна? Как вы думаете, ваша реализация будет заметно быстрее любой другой из имеющихся в мире (gecko, webkit, presto, edge)?
                                    Задумывались ли вы, какой из стандартов (точнее группы классов функцианальности) вы будете готовы реализовать?
                                      0
                                      Скрипты — это JS? Если да, то нет. JS там пока нет.
                                      Про «лучше всех» я смогу ответить только когда появится первая стабильная версию отрисовщика. Но вообще, конечно, разработка ведется с расчетом на скорость и неприхотливость.
                                      Последний вопрос, к сожаления, не понял. Можете пояснить?
                                        0
                                        На совместимость с каким браузером вы хоте ли бы ориентироваться, те же префиксы CSS?
                                          0
                                          Я ориентируюсь на спецификации, причем на «живые» спецификации. Всё, что связанно с CSS это draft. Всё что связанно с HTML это whatwg.org. Про CSS стоит отметить, что с обязательной оглядкой на «рекомендованные» спецификации.

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

                                          Отвечая на вопрос прямо, — поддерживать префиксы сторонних браузеров я не буду. По сути, в спецификациях уже всё определенно. Более того современные движки, такие как webkit, уходят от использования префиксов.

                                          Моя цель реализовать качественный движок/браузер опережающий современные в нескольких направлениях: скорость, ресурсы, гибкость (неприхотливость). Впрочем, Modest так и переводится: скромный, неприхотливый.

                                          И конечно же, надо понимать, что проект большой и сложный, и одним человеком такое не пишется. Точнее, пишется, но до определенной стадии. Но и в этом вопросе есть лучи света.
                                      –1
                                      Скорее всего автор не очень понимает в чем сложность.
                                      Быстрый парсер это конечно хорошо, но это самая простая часть задачи.
                                      Интересует, как автор планирует отрисовывать хотя бы линию «на любом устройстве где есть Си»?

                                      не говоря уже о взаимодействии с системой: реакция на scroll commands, select, copy и т.д.
                                        +2
                                        Не факт что не понимает,
                                        https://github.com/lexborisov/Modest/blob/master/examples/font/glyph_metrics.c
                                        вот этой инфы мне достаточно, чтобы прикрутить к этому nanovg и отрисовать везде, где работает GLES.
                                          –10
                                          Тебе этого достаточно чтобы на хабре об этом комментарий написать.
                                          +3
                                          Тысяча извинений, если я где-то указал, что собираюсь рисовать на любой железке. И если вы на это укажите то я незамедлительно исправлю. А если там нет дисплея? В файл писать? А в какой? PNG, JPG? Или я пишу о расчетах на любой железке? Возможно я и правда ничего не понимаю, столько вопросов.
                                            0
                                            >открытый движок HTML-рендера на «голом» Си
                                            >Возможность скомпилировать/установить на любом устройстве где есть Си

                                            Может мы по разному понимаем слово «рендерер» или слово «устройство»?

                                            Дело в том что парсер CSS + HTML это ~ 5% задачи, да и то только потому, что HTML не строгий язык, поэтому основная сложность парсинга это парсить багнутые HTMLы также как парсит их Explorer, а он даже нормальные HTMLы парсит багованно и большинство рентереров вынужденны поддерживать эти баги, что бы юзеры не вопили, что Explorer показывает правильно, а ты нет. А объяснять им, что все наоборот, бессмысленно.

                                            В проем если твое слово «рендер» означает только парсинг, то все нормально — пока визуальной части нет, юзеры разницы и не увидят :)
                                              +5
                                              Давайте всё же на вы. Рендер — это расчет, расчет всего до состояния «взял и нарисовал» + рисование в файл (по возможности), а вот браузер это уже отрисовка всего на экран со всеми полагающимися плюшками. Вы же понимаете, что рендер создается не зависимо от железки. На «любой железке» свой способ рисовать, вот кто этой самой железкой владеет тот и будет рисовать.

                                              Вы спецификации читали? Почему вы говорите, что основная сложность это парсить битый хтмл? Вы думаете текущий парсер (MyHTML) не умеет верно это парсить? IE тянет только свои древние баги, к которым пользователи привыкли. И думается мне, что они уже 100 раз не рады что когда-то эти баги допустили. Более того, их новый движок, вроде, этих багов уже с собой не тащит. Я не знаю случаев где хром или фф поддерживали бы баги ие, то есть то чего нет в спецификации, а вот из-за прихоти угодить ие.

                                              Я более не буду с вами спорить. Отвечу в вашем же манере, что я считаю грубым, — Скорее всего вы не очень понимаете о чём пишете.
                                                0
                                                Вот — как я и предполагал проблема в слове «рендерер HTML» для меня это отрисовка и UI. А для вас это расчет параметров из HTML + CSS.
                                                Не путайте людей, то что вы пишите это не редерер, это DOM — дерево объектов, возможно с ссылками на подходящие CSS стили.

                                                А сам по себе DOM вряд ли кому-то нужен.
                                                  +3
                                                  Простите, но путаете людей тут только вы. DOM — это DOM. Я говорю, более того я делаю, рендер HTML, если слова Render Tree/Layers вам что-то говорят то вы должны понимать. Я делаю довольно сложную «штуку», а DOM это малая часть этой «штуки».
                                                    +1
                                                    Что-то вы меня запутали. Если рендер это отрисовка, а Tree/Layers это дерево/слои. То какое дерево и какие слои вы отрисовываете? и куда?

                                                    «RenderHtml» это разве не отрисовка боксов, бордюров, текста, имеджей и т.д.? Что должен делать ваш рендер HTML?
                                                      –1
                                                      А вы не путайтесь. Render и show или display — разные слова. Это расчет модели (положения элементов, их цвета и т.д.), а где она будет отображаться и как, другой вопрос.
                                                        +2
                                                        Ре́ндеринг (англ. rendering — «визуализация») — термин в компьютерной графике, обозначающий процесс получения изображения

                                                        В прочем я уже понял, что данный проект имеет весьма косвенное отношение к HTML Browser, но остальные поняли автора именно так — парень делает с нуля HTML viewer!
                                                        Хотя по его же словам от делает «довольно сложную «штуку»». (забавные слова для программиста)
                                                        А зачем эта «сложная штука» нужна и что она будет делать в итоге, он так и не сказал.
                                                          0
                                                          Ну все верно, получение изображения, а не отображение его на конкретном устройстве. Парень все сказал, есть разные области отвественности, кто-то рендерит, а кто-то выводит на конкретный экран или в файл, например.
                                                          И для чего нужно, сто раз уже написано, для поддержки быстрого HTML на всех на свете устройствах, от часов до стиральных машин.
                                                            +2
                                                            «Получение изображения, но не отображение..»
                                                            «Он рендерит, но не выводит ...»

                                                            Я правильно не понял твои слова? :)

                                                            Кто-то может мне объяснить, что на выходе дает этот модуль?
                                          +1
                                          Интересный проект. Реально ли сделать аналог PhantomJS, но для вашего движка?
                                            0
                                            Спасибо! Да, конечно, но лишь когда будет реализован JS и ещё не мало чего. В PhantomJS всегда раздражал тот факт, что нужно дождаться окончания полной загрузки страницы (выполнение всех скриптов и прочего). То есть, он может позволить себе висеть до 10-20 секунд прежде чем ему можно будет что-то отработать. Возможно там уже что-то поменялось, но раньше это был webkit с которым ты общаешься через JS. Я же хочу предоставить пользователю полный контроль, начиная от HTML дерева заканчивая Redner Tree с простым и понятным API.
                                              0

                                              Там Qt WebKit, который можно расширять из C++.

                                          • UFO just landed and posted this here
                                              0
                                              Спасибо вам!
                                                –1
                                                Ему останавливаться не перед чем. Там даже рендера и js нет. Это пишется за пару недель на OpenGL + scenegraph. Он пытается делать то, как раньше руками с нуля писали UI для игр. И делали это вполне успешно 1.5 человека.
                                                0
                                                Блин, было бы супер, если бы его можно было приспособить для browser-less консольной прогонки тестов UI. Сейчас это phantomjs — но он ужасно медленный.
                                                  0
                                                  Думается мне, как только движок достигнет адекватного состояния то это само собой возникнет.
                                                  0
                                                  на это смотрели? Весьма достойный конкурент.
                                                    0
                                                    Привет, только вот вчера смотрел. Сложно с кем-то мёртвым конкурировать «HTMLayout is not supported anymore, please use Sciter instead. Sciter is a superset of HTMLayout and works on Windows, Mac OS X and Linux». Да и сравнения там с FF 1.0 и IE 6.0, крайне странно. Так же не понятно насколько покрывает спецификацию эта штука и какой версии.
                                                    0
                                                    Могу только пожелать удачи!
                                                      0
                                                      Спасибо!
                                                      0
                                                      Очень впечатляет! Мне кажется мало кто понимает то, насколько этот проект в случае успеха изменит мир.
                                                        –3
                                                        Ничего он не изменит. Автор получит через 2-3 года клон IE 1.0, и всё. У тебя «нефтяной» максимализм, типа вот щас-щас вотчучуть и заживем, пендосы саснут, ря! Лучшебы автор V8 в 10 раз ускорил или еще чего. Или рендер у хрома, раз он его пишет.
                                                          +7
                                                          Не люблю отвечать на подобные комментарии, но исключение надо делать иногда.
                                                          Вы видимо знающий человек в этой области. Ведь вы утверждаете, что полтора человека это могут сделать (где-то выше утверждали), то вот чётко уверены, что через два-три года будет клон IE 1.0. Вы и исходники все посмотрели, и спецификации все почитали, и знаете как всё устроено?

                                                          Вообще, как можно писать, что я получу IE 1.0 через два года когда уже все новое написано и разрабатывается по последним спецификациям. Я даже слов подобрать не могу, это какой-то абсурд. Вы тролль?

                                                          Зачем мне идти и помогать гуглу, фаерфоксу? Там работают люди, программисты и прочие, которые получают за свою работу деньги, как и я собственно, а тут я должен всё бросить, и помогать какой-то зарубежной компании — зачем? Тем более в том продукте стратегию разработки которого я не разделяю с ними. Вы вот чем занимаетесь? Почему вы не помогаете гуглу? Вы видимо большой специалист в этой сфере, помогите гуглу, а то вдруг не успеете и он закроет проект.
                                                        –1
                                                        День добрый.
                                                        Не подскажете, на чем GUI пишется? Будет ли порт под мобильные платформы?
                                                        Спасибо.
                                                          0
                                                          Простите, но я не делаю ГУИ. В статье всё написанно по этому поводу. А вот когда речь зайдет о браузере тогда и можно будет ответить на этот вопрос.
                                                            0
                                                            А на мобильный платформах есть Си? Или вы хотите обвязку под конкретный язык? В статье все, вроде бы, написано.

                                                          Only users with full accounts can post comments. Log in, please.