После моей последней публикации прошло немало времени. За это время многое изменилось и я хочу поделиться с вами достижениями в разработке.
О Проекте
Основная идея проекта заключается в его неприхотливости, а это значит:
— Возможность скомпилировать/установить на любом устройстве где есть Си
— Скорость работы
— Минимально возможное потребление ресурсов
Одним из конечных продуктов данной разработки является по-настоящему быстрый, лёгкий, полнофункциональный браузер.
Обо всём по порядку
Возможность скомпилировать/установить на любом устройстве где есть Си
Идея заключается не только в том, чтобы иметь возможность скомпилировать/установить на любой железке, ведь Си есть практически везде, но и иметь возможность подключить движок к другому языку программирования раскрывая для этого языка полный спектр API движка. Говоря проще, иметь возможность легко сделать binding (обвязку) для вашего языка программирования.
Что же нам дадут обвязки на других языках?
Простое и понятное API движка даст нам возможность напрямую работать с HTML Tree, CSS, Render Tree/Layers (Дерево отрисовки/слои) через наш любимый язык программирования, без использования JavaScript.
На практике это будет означать следующее:
- Высокая скорость доступа, создания, изменения элементов/слоёв.
- Лёгкость создания интерфейсов, игр, приложений через знакомый вам язык программирования с использованием всех возможностей HTML/DOM Events/CSS.
- Берём готовую обвязку для Perl и меняем её
- Добавляем в обработку тега script тип Perl: <script type="Per">
- Разбираем хтмл в Perl
- Когда парсер встречает тег 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 нельзя использовать «серебряную пулю». Везде нужен индивидуальный подход. Ну, и конечно же, всё это нельзя создать без полного понимания спецификаций и того, что в спецификации требуют.
Текущая структура проекта
На данный момент реализованны следующие части проекта:
- MyHTML — парсер HTML
- MyCSS — парсер CSS (Selectors, Values, Namespace, Property)
- 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) за исключением:
- Всех псевдо-элементов (pseudo-elements)
- :dir, :lang, :scope, «Time-dimensional Pseudo-classes», :drop
- :nth-column, :nth-last-column
Первые и вторые будут разрабатываться/добавляться по мере разработки движка. До третьих руки не дошли, но, конечно же, они так же будут реализованы в ближайшем будущем.
Будущее проекта
Оно (будущее) видится очень светлым. Проектом занимаюсь в рабочее время. Мой работодатель разрешил мне тратить всё рабочее время на проект, конечно, если что-то просят сделать приходится отвлекаться.
Сейчас, я приступил к созданию дерева отрисовки (Render Tree, Layers). То есть, уже в недалёком будущем можно будет получать рассчитанные метрики хтмл нод, такие как width, height, font-size, border-color и прочие.
Идей очень много, а «бензина» во мне ещё больше! Спасибо за внимание!
P.S.: Если у кого-нибудь возникнет желание помочь/поучаствовать в реализации проекта то можно смело писать на почту.
Ссылки:
» Modest
» Примеры Modest
» Примеры MyHTML
» Примеры MyCSS
» Обвязка MyHTML для Perl
Комментарии (81)
Fox_exe
12.09.2016 13:15+3Я так понимаю всё это сулит нам долгожданный браузер, способный держать больше 3х открытых вкладок, не вешая проц и не съжирая 10 гигов оперативки?
lastmac
12.09.2016 13:17+5Да, именно так, это одна из основных целей.
numitus2
12.09.2016 13:53+10К сожалению когда вы полностью реализуете совместимость с web-kit вы поймете, что вся память уходит на dom, и на скрипты.
lastmac
12.09.2016 13:54+5Хорошо, давайте посмотрим что получится в итоге.
rPman
12.09.2016 15:35-7Попробуйте не замахиваться на ВЕСЬ вебкит, в 99% случаев весь мир использует библиотеки вида jquery, достаточно будет добавить в них поддержку именно вашего браузера и большинству этого будет достаточно.
Лучше пусть будет быстро!
p.s. реализуйте в стандарте понятие пакетного менеджера, чтобы была возможность устанавливать общепринятые библиотеки на стороне клиента (и загружать их однократно, даже если они требуются в нескольких вкладках одновременно), т.е. владелец веб-сайта указывает свой репозитарий, с хешами пакетов, и на страницах указывает что то типа
import jquery < 18.2 >= 11.3;
а браузер загружает ее однократно и хранит в кеше, зато если понадобится другому сайту — достаточно будет идентификатора, версии и хеша, чтобы использовать уже загруженную (и проинициализированную)
HajaPura
12.09.2016 13:23Одним из конечных продуктов проекта сделать более быстрый HTML браузер, какие еще есть варианты вашего проекта? Не спроста же ваш работодатель так щедр
lastmac
12.09.2016 13:31+1В статье я пишу, что браузер это одно из направлений, он как бы логично «вытекает» из этой разработки.
Встраиваемость — это очень важный аспект разработки. Потому и нет зависимостей. Ведь HTML и DOM Events можно использовать не только в браузере. Благодаря тому, что он написан на Си его можно прикрутить к «любому месту». Соответственно получив полнофункциональный рендер хтмл на своем любимо языке программирования. То есть, тут отпадает JavaScript, ведь вы можете напрямую пользоваться АПИ движка. Можно использовать для создания интерфейсов, игр, да чего угодно в своей программе.
Работодатель у меня действительно хороший. Он адекватный и слушает, а главное слышит, то что ему говоришь.HajaPura
12.09.2016 13:37Все же без JS как связующего слоя между HTML5 API (Web Gl, Media Source Extension, Canvas) данный браузер будет «не очень» работать с сайтами которые все же имеют малейшие намеки на динамический контент. Или, к примеру, планируется интерпретатор JS в какой то нативный для платформы скриптовый язык? Что в вашем понимании есть АПИ движка?
lastmac
12.09.2016 14:01+2Вы немного не поняли. JS будет в браузере, как же без него. Речь о том, что движок можно прикрутить к вашей программе и использовать все его возможности напрямую, минуя JS. Тут речь не о браузере. А именно о том, чтобы использовать возможности HTML/DOM Event/CSS в какой либо программе. То есть, не для рисования страницы хабра, а для создания элементов на хтмл, интерфейсов и прочего.
mr_tron
12.09.2016 15:45+1А почему вы стесняетесь назвать имя то? Он даже на хабре есть https://habrahabr.ru/users/Ashmanov/
lastmac
12.09.2016 15:48+1Имени у меня не спрашивали, но и секрета тут нет. Работаю я в Крибрум, сижу на одном этаже между Инфовотч и Ашманов и Партнеры. Из чего так же можно сделать вывод, что главные у нас Игорь Ашманов и Наталья Касперская.
Fox_exe
12.09.2016 22:04Кстати, да, для встраиваемых систем (Техже телевизоров) и «Интернета вещей» — Идеальный вариант.
В своё время так сделали разрабы Opera — движок их браузера был весьма шустрый и досихпор встречается в некоторых телеках и плеерах (У которых начинка «так себе»)
kloppspb
12.09.2016 13:37Интересно. По скорости HTML::MyHTML уделывает Mojo::DOM почти в 40 раз. Вот сравнить бы ещё на корректность построения дерева…
lastmac
12.09.2016 13:41Если Mojo::DOM полностью проходит тесты на построение дерева то можно не беспокоиться о правильности построения дерева.
RPG18
12.09.2016 14:21Насколько помню Mojo написано на Perl без использования библиотек на Си.
kloppspb
13.09.2016 03:18Да, по-хорошему надо сравнивать с кем-то, у кого парсер тоже сишный. Самый быстрый из перловых модулей, наверное, HTML::Bare, с сишным ядром. Но и он проигрывает HTML::MyHTML. Правда, не в 40 раз, а всего в два, но тоже неплохо :)
lastmac
13.09.2016 10:46Удивительно тут то что HTML::Bare нельзя назвать html парсером, там нет правил построения дерева. Более того не понятно какой элемент чем является.
Вот взять такой хтмл:
<svg><desc><style><a>
Итог должен быть такой:
<html> <head> <body> <svg:svg> <desc:svg> <style> <-text>: <a>
То есть, тег в конце является текстом, это важно. При этом, парсер HTML::Bare ещё и в два раза отстает от полноценного MyHTML. Вот так и пишут всякое, а называют HTML парсерами, хотя они с ними и рядом не стояли.kloppspb
14.09.2016 13:41У них совсем другие задачи. 80% из них выглядят как-то так: «а дай-ка мне значение href у a, который находится внутри дива с классом foo» или «найди все p у который есть атрибут bar с любым значением». Ещё 20% — другая мелочёвка, с которой они тоже вполне справляются.
lastmac
14.09.2016 14:10Возможно да, но из примера выше ясно, что тот же тег «a» они не верно разберут и соответственно выдадут неверный ответ. Собственно, всё тоже самое можно делать и в myhtml или же использовать селекторы из modest (надо бы их к перлу прикрутить)
kloppspb
14.09.2016 14:27>всё тоже самое можно делать и в 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 тысяч разных страниц в сутки, на явные некорректности не нарывался. Может и повезло, конечно :)lastmac
14.09.2016 14:49cpan: https://metacpan.org/pod/HTML::MyHTML
В хтмл есть условия для каждого тега как и куда ему нужно быть вставленным в хтмл дерево или быть выбращенным при разных условиях. Если вы хотите итог такой же как в любом современном браузере то нужно использовать полноценный парсер, а если вам это не важно то любой простой токенизатор который находит элементы <...>.kloppspb
14.09.2016 15:02Ой, что-то прошлёпал. Странно, вроде у них с неймингом построже было. Во всяком случае когда я своё пытался приткнуть заставляли переделывать.
Как в браузере не надо. Но токенизатора не хватит, кроме поиска и манипуляции с деревом нужны. И вставка, и удаление, и замена атрибутов. Но в любом случае скорость MyHTML — это киллер фича даже в этом случае :)lastmac
15.09.2016 17:37В сишной версии есть всё связанное с работой с деревом: добавление, удаление, изменение. Катастрофически не хватает времени доделать обвязку для перла.
Azq2
12.09.2016 13:39Сейчас, я приступил к созданию дерева отрисовки (Render Tree, Layers). То есть, уже в недалёком будущем можно будет получать рассчитанные метрики хтмл нод, такие как width, height, font-size, border-color и прочие.
Т.е. прямо сейчас MyCSS нельзя использовать как замену LibCSS для получения рассчитанных color/background-color произвольной ноды?lastmac
12.09.2016 13:47Нет, сейчас нельзя. Сейчас, можно получить width, height (CSS). К сожалению я не могу сейчас позволить себе засесть за разработку всех свойств CSS. Хотя и делать там особо нечего. Мною было принято решение делать всё по мере надобности. Или же пока к проекту не подключится кто-то ещё кому можно объяснить как легко можно добавить обработчик того или иного свойства.
Могу вас заверить, что до момента появления поддержки всех CSS свойств осталось не так много времени.Azq2
14.09.2016 14:57А возможность добавлять свои свойства и обработчики без правки кода библиотеки — это будет?
В libcss это всё захардкорено внутри неё и нельзя просто так добавить что-то своё.
И это всё будет внутри mycss? Или в вашем проекте это уже часть modest?lastmac
14.09.2016 15:28Я размышляю об этом, и склоняюсь к мысли сделать для своих свойств какой-то префикс, вроде --mycss-*. Вот тогда можно будет динамически добавлять свои свойства и обработчики к ним. Но, меня остановили рассуждения о том, зачем это может понадобиться? Для чего это потом использовать? Я так и не придумал.
В Modest вшит myhtml и mycss. Но поддерживаются они оба, то есть код mycss идентичен коду его же в modest. В будущем они разойдутся (это надо для движка modest, без этого никак), но совместимость сохранится. Можно будет спокойно использовать код написанный на mycss в modest. Разработка специально идёт так чтобы можно было использовать парсер хтмл и цсс отдельно.Azq2
14.09.2016 15:43Одного только mycss (без modest) хватит для целей, что бы получить, например, цвет для любой ноды? Как я сейчас использую LibCSS для этого.
Там у него куча сalback'ов для работы с DOM деревом.
Я это имею ввиду.lastmac
14.09.2016 15:54Да, хватит, но тут нужно уточнить, свойства какие уже посчитанные или то, что указал пользователь в css файле?
То есть, font-size можно иметь посчитанный (он наследуется) или же тот что указали в css? В первом варианте это будет всегда число в пикселях (рассчитанное), а во втором то что указал пользователь: 10%, 30em и так далее.
В данный момент я работаю над поддержкой свойств border*, margin*, padding*, font*, display и прочие. Как я уже и говорил, добавляю свойства по мере надобности проекту Modest.
x512
12.09.2016 14:00+1На современных HTML страницах много JavaScript, а во все более набирающих популярность SPA их ОЧЕНЬ МНОГО, на порядок больше CSS кода и производительность в таком случае упирается в производительность JS (а точнее, зачастую в скорость манипуляции DOM через JS). Неужели вы планируете поддерживать JavaScript тоже? И даже если так, то затупы JS сведут все оптимизации с парсингом HTML/CSS в никуда.
lastmac
12.09.2016 14:14+2Привет! JS это отдельная, большая тема для разговора. В предыдущих статьях я писал, что планирую взять сторонний движок, надо понимать, что если я продолжу разработку один то меня просто не хватит на всё, это не реально. Пока я буду разрабатывать одну часть другая просто устареет. В спецификациях всё активно обновляется.
На данный момент я склоняюсь к использованию стороннего JS движка. Но решение я оттягиваю до последнего. Я жду решения людей которые в корне смогут изменить скорость разработки проекта. Соответственно будет и ответ на вопрос как оно там с JS.
Затупы JS — это затупы JS, ничего они не сведут на нет.x512
12.09.2016 15:12+9Дело в том, что SPA приложения практически не загружают HTML c сервера — они его генерируют через JS. Т.е. результирующую страницу вы не получите, пока не отработает весь JS код. В результате получается, что 90 процентов время загрузки страницы тратится на исполнение JS и его взаимодействию с DOM. Создание современного движка JS с поддержкой фич вроде async и генератов видится мне нетривиальной задачей даже для опытной команды. А подключение любого из современных движков JS будет и сложно и неэффективно, т.к. все они (SpiderMonkey, Edge, V8) разработаны с учетом использования из С++ кода и сами на нем же, очевидно, и написаны.
Так что я искренне вам рекомендую посмотреть на https://github.com/servo/servolastmac
12.09.2016 15:43+3Речь о том, что JS сам по себе не разбирает CSS или HTML и прочие компоненты, если конечно кто-то не использует разбор CSS/HTML написанный на JS, тут я ничего не сделаю.
А так, да, буквально все кто создает JS движки создают их под себя, тут вы правы.
Мне часто рекомендуют посмотреть на серво, более того даже звали туда работать. Но, к сожалению, или счастью, вынужден отказать.
Я вас услышал, спасибо.
Есть интересная тенденция, каждый раз когда я приступаю к разработке какого либо компонента мне говорят, что ничего не выйдет, ну или я не понимаю куда лезу. Проект открытый, каждый может увидеть что из этого выйдет.
lieff
12.09.2016 15:44У проектов предназначение все же разное как я вижу. Этот больше для эмбебеда и скорости парсинга, servo — надежность и использование GPU.
Например собрать servo на десктопе это одно, а под Ubuntu Phone\Sailfish\Pi\Emscripten\Кофеварку — совсем другое.
Про отсутствие JS, автор так же имеет ввиду встраевоемое применение, на например хром через electron встроен в десктопный Slack клиент.
Тут ты сам волен делать все что хочешь и взаимодействие напрямую может быть плюсом.
rPman
12.09.2016 15:29Из скриптов работа с DOM возможна? Как вы думаете, ваша реализация будет заметно быстрее любой другой из имеющихся в мире (gecko, webkit, presto, edge)?
Задумывались ли вы, какой из стандартов (точнее группы классов функцианальности) вы будете готовы реализовать?lastmac
12.09.2016 16:02Скрипты — это JS? Если да, то нет. JS там пока нет.
Про «лучше всех» я смогу ответить только когда появится первая стабильная версию отрисовщика. Но вообще, конечно, разработка ведется с расчетом на скорость и неприхотливость.
Последний вопрос, к сожаления, не понял. Можете пояснить?rPman
13.09.2016 23:56На совместимость с каким браузером вы хоте ли бы ориентироваться, те же префиксы CSS?
lastmac
14.09.2016 10:02Я ориентируюсь на спецификации, причем на «живые» спецификации. Всё, что связанно с CSS это draft. Всё что связанно с HTML это whatwg.org. Про CSS стоит отметить, что с обязательной оглядкой на «рекомендованные» спецификации.
CSS префиксы в браузерах — это не от хорошей жизни и использовать их не стоит. Создаются они по той причине, что какое-то свойство нужно, а спецификация не определилась ещё как оно должно отрабатывать, или же кто-то из гигантов вводит своё свойство которое потом перетекает в спецификацию.
Отвечая на вопрос прямо, — поддерживать префиксы сторонних браузеров я не буду. По сути, в спецификациях уже всё определенно. Более того современные движки, такие как webkit, уходят от использования префиксов.
Моя цель реализовать качественный движок/браузер опережающий современные в нескольких направлениях: скорость, ресурсы, гибкость (неприхотливость). Впрочем, Modest так и переводится: скромный, неприхотливый.
И конечно же, надо понимать, что проект большой и сложный, и одним человеком такое не пишется. Точнее, пишется, но до определенной стадии. Но и в этом вопросе есть лучи света.
Durimar123
12.09.2016 18:52-1Скорее всего автор не очень понимает в чем сложность.
Быстрый парсер это конечно хорошо, но это самая простая часть задачи.
Интересует, как автор планирует отрисовывать хотя бы линию «на любом устройстве где есть Си»?
не говоря уже о взаимодействии с системой: реакция на scroll commands, select, copy и т.д.lieff
12.09.2016 19:17+2Не факт что не понимает,
https://github.com/lexborisov/Modest/blob/master/examples/font/glyph_metrics.c
вот этой инфы мне достаточно, чтобы прикрутить к этому nanovg и отрисовать везде, где работает GLES.
lastmac
13.09.2016 00:30+3Тысяча извинений, если я где-то указал, что собираюсь рисовать на любой железке. И если вы на это укажите то я незамедлительно исправлю. А если там нет дисплея? В файл писать? А в какой? PNG, JPG? Или я пишу о расчетах на любой железке? Возможно я и правда ничего не понимаю, столько вопросов.
Durimar123
13.09.2016 10:38>открытый движок HTML-рендера на «голом» Си
>Возможность скомпилировать/установить на любом устройстве где есть Си
Может мы по разному понимаем слово «рендерер» или слово «устройство»?
Дело в том что парсер CSS + HTML это ~ 5% задачи, да и то только потому, что HTML не строгий язык, поэтому основная сложность парсинга это парсить багнутые HTMLы также как парсит их Explorer, а он даже нормальные HTMLы парсит багованно и большинство рентереров вынужденны поддерживать эти баги, что бы юзеры не вопили, что Explorer показывает правильно, а ты нет. А объяснять им, что все наоборот, бессмысленно.
В проем если твое слово «рендер» означает только парсинг, то все нормально — пока визуальной части нет, юзеры разницы и не увидят :)lastmac
13.09.2016 11:33+5Давайте всё же на вы. Рендер — это расчет, расчет всего до состояния «взял и нарисовал» + рисование в файл (по возможности), а вот браузер это уже отрисовка всего на экран со всеми полагающимися плюшками. Вы же понимаете, что рендер создается не зависимо от железки. На «любой железке» свой способ рисовать, вот кто этой самой железкой владеет тот и будет рисовать.
Вы спецификации читали? Почему вы говорите, что основная сложность это парсить битый хтмл? Вы думаете текущий парсер (MyHTML) не умеет верно это парсить? IE тянет только свои древние баги, к которым пользователи привыкли. И думается мне, что они уже 100 раз не рады что когда-то эти баги допустили. Более того, их новый движок, вроде, этих багов уже с собой не тащит. Я не знаю случаев где хром или фф поддерживали бы баги ие, то есть то чего нет в спецификации, а вот из-за прихоти угодить ие.
Я более не буду с вами спорить. Отвечу в вашем же манере, что я считаю грубым, — Скорее всего вы не очень понимаете о чём пишете.Durimar123
13.09.2016 12:08Вот — как я и предполагал проблема в слове «рендерер HTML» для меня это отрисовка и UI. А для вас это расчет параметров из HTML + CSS.
Не путайте людей, то что вы пишите это не редерер, это DOM — дерево объектов, возможно с ссылками на подходящие CSS стили.
А сам по себе DOM вряд ли кому-то нужен.lastmac
13.09.2016 12:13+3Простите, но путаете людей тут только вы. DOM — это DOM. Я говорю, более того я делаю, рендер HTML, если слова Render Tree/Layers вам что-то говорят то вы должны понимать. Я делаю довольно сложную «штуку», а DOM это малая часть этой «штуки».
Durimar123
13.09.2016 12:43+1Что-то вы меня запутали. Если рендер это отрисовка, а Tree/Layers это дерево/слои. То какое дерево и какие слои вы отрисовываете? и куда?
«RenderHtml» это разве не отрисовка боксов, бордюров, текста, имеджей и т.д.? Что должен делать ваш рендер HTML?alibertino
14.09.2016 09:01-1А вы не путайтесь. Render и show или display — разные слова. Это расчет модели (положения элементов, их цвета и т.д.), а где она будет отображаться и как, другой вопрос.
Durimar123
14.09.2016 14:47+2Ре?ндеринг (англ. rendering — «визуализация») — термин в компьютерной графике, обозначающий процесс получения изображения
В прочем я уже понял, что данный проект имеет весьма косвенное отношение к HTML Browser, но остальные поняли автора именно так — парень делает с нуля HTML viewer!
Хотя по его же словам от делает «довольно сложную «штуку»». (забавные слова для программиста)
А зачем эта «сложная штука» нужна и что она будет делать в итоге, он так и не сказал.alibertino
14.09.2016 14:59Ну все верно, получение изображения, а не отображение его на конкретном устройстве. Парень все сказал, есть разные области отвественности, кто-то рендерит, а кто-то выводит на конкретный экран или в файл, например.
И для чего нужно, сто раз уже написано, для поддержки быстрого HTML на всех на свете устройствах, от часов до стиральных машин.Durimar123
14.09.2016 15:08+2«Получение изображения, но не отображение..»
«Он рендерит, но не выводит ...»
Я правильно не понял твои слова? :)
Кто-то может мне объяснить, что на выходе дает этот модуль?
yogurt1
13.09.2016 00:15+1Интересный проект. Реально ли сделать аналог PhantomJS, но для вашего движка?
lastmac
13.09.2016 00:24Спасибо! Да, конечно, но лишь когда будет реализован JS и ещё не мало чего. В PhantomJS всегда раздражал тот факт, что нужно дождаться окончания полной загрузки страницы (выполнение всех скриптов и прочего). То есть, он может позволить себе висеть до 10-20 секунд прежде чем ему можно будет что-то отработать. Возможно там уже что-то поменялось, но раньше это был webkit с которым ты общаешься через JS. Я же хочу предоставить пользователю полный контроль, начиная от HTML дерева заканчивая Redner Tree с простым и понятным API.
stychos
13.09.2016 00:54+3Ни перед чем не останавливайтесь! Снимаю шляпу.
lookid
13.09.2016 13:22-1Ему останавливаться не перед чем. Там даже рендера и js нет. Это пишется за пару недель на OpenGL + scenegraph. Он пытается делать то, как раньше руками с нуля писали UI для игр. И делали это вполне успешно 1.5 человека.
Holms
13.09.2016 10:41на это смотрели? Весьма достойный конкурент.
lastmac
13.09.2016 11:04Привет, только вот вчера смотрел. Сложно с кем-то мёртвым конкурировать «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, крайне странно. Так же не понятно насколько покрывает спецификацию эта штука и какой версии.
AirWorker
14.09.2016 05:22Очень впечатляет! Мне кажется мало кто понимает то, насколько этот проект в случае успеха изменит мир.
lookid
14.09.2016 13:06-3Ничего он не изменит. Автор получит через 2-3 года клон IE 1.0, и всё. У тебя «нефтяной» максимализм, типа вот щас-щас вотчучуть и заживем, пендосы саснут, ря! Лучшебы автор V8 в 10 раз ускорил или еще чего. Или рендер у хрома, раз он его пишет.
lastmac
14.09.2016 14:35+7Не люблю отвечать на подобные комментарии, но исключение надо делать иногда.
Вы видимо знающий человек в этой области. Ведь вы утверждаете, что полтора человека это могут сделать (где-то выше утверждали), то вот чётко уверены, что через два-три года будет клон IE 1.0. Вы и исходники все посмотрели, и спецификации все почитали, и знаете как всё устроено?
Вообще, как можно писать, что я получу IE 1.0 через два года когда уже все новое написано и разрабатывается по последним спецификациям. Я даже слов подобрать не могу, это какой-то абсурд. Вы тролль?
Зачем мне идти и помогать гуглу, фаерфоксу? Там работают люди, программисты и прочие, которые получают за свою работу деньги, как и я собственно, а тут я должен всё бросить, и помогать какой-то зарубежной компании — зачем? Тем более в том продукте стратегию разработки которого я не разделяю с ними. Вы вот чем занимаетесь? Почему вы не помогаете гуглу? Вы видимо большой специалист в этой сфере, помогите гуглу, а то вдруг не успеете и он закроет проект.
Crazy_as
15.09.2016 07:12-1День добрый.
Не подскажете, на чем GUI пишется? Будет ли порт под мобильные платформы?
Спасибо.lastmac
15.09.2016 17:42Простите, но я не делаю ГУИ. В статье всё написанно по этому поводу. А вот когда речь зайдет о браузере тогда и можно будет ответить на этот вопрос.
lastmac
15.09.2016 17:44А на мобильный платформах есть Си? Или вы хотите обвязку под конкретный язык? В статье все, вроде бы, написано.
azsx
Не совсем понятно, что в итоге делает Ваш парсер.
оффтопик
Если Вам интересно, я делаю поисковую систему по html кодам, имеется база 10+млн страниц. Удобно, что сразу в базе.
lastmac
Привет!
Это уже не парсер. А отрисовщик (Render) HTML. То есть, в итоге он будет считать хтмл и отдавать результат расчетов как современные браузеры. Он включает в себя несколько парсеров (HTML, CSS, FONT и ещё будут добавляться) + разные возможности CSS модулей.
Спасибо! Для тестирования я использую commoncrawl.org — там можно получить миллиарды хтмл страниц с разными кодировками и языками.