Сравнивать можно. И webkit парсит HTML и показывает его с CSS.
Также и Sciter, парсит HTML и показывает его с CSS. В своей версии и только те СSS фичи что для UI нужны.
Например эта вот дискуссия:
Видно что что-то в CSS не поддерживается, тем не менее содержимое ты видишь.
Фенечка в том что я могу Sciter доделать до уровня WebKit, но WebKit до уровня Sciter не дотянется никогда по многим причинам.
rendering speed (в два раза примерно), loading times (раз в 5-10), memory consumption (в 3-6 раз), какие-то функции вообще не сравнимы — нет аналогов в WebKit — не с чем сравнивать.
В части desktop UI касающейся Sciter (H-SMILE core) лучше чем WebKit.
Например отрендерить DOM элемент в popup окне:
WebKit не умеет в принципе. Или вот HTML в круглом окне:
WebKit тоже не умеет.
Бенчмарк это измерение какой-то конкретной функциональности, какой в данном контексте?
Производительность UI это комплексная метрика.
Скажем VSCode (сделан на ElectronJS) при старте запускает как минимум 4 процесса (даже не потока). Один исполняет HTML/CSS/JS, второй рендерит на экран + RPC между этим всем. Понятно что single process Sublime Text будет быстрее. И это так и есть.
То же самое и с Sciter который делает всё то же что и ElectronJS только в 10 раз меньше. Какие-то операции тоже в разы быстрее — рисование в DirectX напрямую в Sciter например.
автор хочет сделать нормальных JS, для закрытого проекта
Не делаю я JS. В смысле вообще. Я сделал Sciter Script для Sciter — он жил, живет и будет жить в Sciter Engine. В Sciter.JS будет использоваться стандарный JS с плюшками ( например native JSX как во взрослом Sciter и т.д. )
Потому что script там примерно 15% объема — остальное custom HTML/CSS rendering engine c DirectX, OpenGL, Vulkan graphic backends.
Sciter это HTML/CSS/tiscript — desktop UI engine.
Sciter.JS HTML/CSS/javascript — desktop UI engine — ElectronJS replacement, только в 10 меньше и для все платформ WinLinMac+Mobiles.
В качестве JavaScript могут использоваться в Sciter.JS как QuickJS++ (с моими патчами) так и V8.
озвученных денег, по моему опыту, не хватит ни на что.
Это так. Но есть еще сущесвующие customers как я уже сказал которые платят за подписку.
Sciter.JS планируется как BSD. Денег с BSD я не ожидаю. Вообще donation ware на таких проектах не работает.
kickstarter campaign, он на разработку именно Sciter.JS. Там нужны будут люди — как минимум еще два разработчика.
На сам Sciter денег лично мне вполне себе хватает от коммерческих пользователей. Открытие исходников самого Sciter это просто доп. мотивация для тех кому именно оно надо.
Более того, я (в том числе) её писал. Как Invited Expert @ W3C HTML5 WG и WHATWG.
Ты наверное не понял что я имею ввиду. Скажем у тебя есть HTML в кодировке UTF-8 на входе. Т.е. 50% твоего текста это ASCII. Зачем эти 50% вообще куда-то конвертировать?
Тебе нужно конвертировать содержимое text nodes. И некоторых атрибутов. И только. Зачем дурную работу делать?
Не ясна модель встраивания в другие языки. Поэтому и вопросы.
Если бы ты (можно без «вы»?) определил изначально периметр встраивания (API другими словами) то было бы наверное более понятно что оно такое будет.
Скажем весь Sciter API это вот эта структура github.com/c-smile/sciter-sdk/blob/master/include/sciter-x-api.h — там реально 40 функций (DOM related).
Это чистые C functions хотя написаны на C++. И то на чем они написаны вообще никого не волнует. И не должно. Далеко не все «структуры» вообще могут быть выставлены наружу. Это банально опасно. Только контролируемый периметр.
«есть чёткое понимание как всё делать»
У меня было это состояние лет так 14 назад. И более того был реальный опыт создания WYSIWYG редакторов что близко к HTML (и там и там DOM, parsing и всё такое). Реальность как всегда оказалась несколько далека от изначальной теории.
Как я понимаю до слов harfbuzz (и вообще RTL), writing script itemizer and shaper, и прочая ты еще не добрался. (сужу по описанной структуре parser. Кому нужны эти «Character token» и что это вообще?)
«я вообще ещё не говорил о рисовалке.» и "… дерева отрисовки. Все расчеты, перерасчёты и так далее."
Ну да, теоретически ты можешь рассчитать положение примитивных прямоугольных блоков, но для glyph positioning придется учитывать такие вещи как ClearType и другие механизмы которые доступны на конкретных платформах и которые являются частью rendering механизма. Это суровая практика, сиречь необходимость. Без понятия архитектуры rendering с самого начала и как те glyphs оказываются в GPU памяти что-то практическое сделать невозможно.
И еще, я ни в коем случае не хочу тут рисовать картину маслом «Умерщвление прекрасной гипотезы мерзким фактом». Можно написать HTML/CSS/script engine и одному, собственно sciter есть тому подтверждение. Но нужно изначально определить «а user кто?». Для чего это всё? Т.е. почему проект который сейчас использует WebKit или Sciter должен перейти на твой движок?
Если это для того чтобы сделать что-то типа HTML-to-PDF утилиты, то это одно. Для UI же… С его анимациями и рисованием на 4K мониторе full screen и c 60 FPS это совсем другое — как минимум layout engine должен взаимодействовать с rendering engine чтобы получать вектора glyphs и прочая. DrawText примитивы уже не работают на таких потоках данных и скоростях.
И еще по поводу языка. Sciter написан на «C c классами» по большому счету. Ибо это удобно — т.е. позволяет быстрее и что главное надежнее писать. (Sciter примерно 100 тыс LOC). Это всё важно для one-man-project. А Mozilla вообще пилит Rust для того чтобы писать Servo — ручное управление памятью для проектов такого масштаба даже для них оказалось суровой задачей.
И по поводу Open Source. Не советую обольщаться на эту тему.
Есть два типа проектов: небольшие утилиты и что-то типа Electron. Первые имеют смысл для Open Source. Вторые же… Ну вот реально никого не парит что там внутри — реально количество людей которые лезут в детали WebKit или Gecko исчисляется десятками на всём шарике. И вот собственно и вся аудитория для open-sourse-ности проектов такого уровня. Тем более в свете последних скандалов с NPM ( в Microsoft Visual Code пролезла закладка которая тырит Bitcoins ) народ оченно печально настроен.
То что мы видим в OpenSource это верхушка айсберга. Реально же 90% софта это проекты по месту — внутренних IT отделов компаний. Да и те же китайцы. Любят они OpenSource. Но вот не знаю ни одного OS проекта финансируемого ими. Нет таких. Не потому что они такие-сякие, а потому что через их firewall такие платежи не сделать. Да и вообще поток статей типа FOSS is free as in toilet в последнее время оптимизма никак не внушает.
Не сказал бы что обрезанная ибо HTML5 и CSS3 (избранные модули) поддерживаются практически в полном объеме.
Вот «полноценный движок на Си» сделать действительно крайне сложно. С это не тот язык на котором такие вещи удобно писать.
И желание «встраивать в любой язык программирования» тоже вызывает вопросы.
Сейчас Sciter встраиваем в C/C++, C#, Rust, Python и Go. и написан на C++. Embedding API тот, да, plain C ибо другой альтернативы нет.
Но на самом деле встраивание в язык это дело десятое. Вот встраивание в существующие десктоп системы и графику это важно.
Сейчас Sciter может работать на Windows (XP … 10) c Direct2D/DirectWrite (DirectX), Skia (OpenGL) и GDI+ (прости мя сирого, хоспидя). На Mac — CoreGraphics и OpenGL(Skia), Linux/GTK (cairo или Skia). На подходе Andorid (OpenGL) и iOS (CoreGraphics или OpenGL).
Skia и Direct2D это C++ и только. Ибо Skia можно интегрировать только в исходниках а это С++. А Direct2D это IUnknown со товарищи, т.е. C++ опять же.
Без Skia и Direct2D (т.е. hardware acceleration) делать rendering engine можно и не начинать. 4K мониторы это наше все теперь. А на них только H/W acceleration — других опций и нет.
Вот это «А display:inline указывает, что ширина прямоугольника...» смысла не имеет. У display:inline нет прямоугольника (border box в технических терминах). Элемент с display:inline содержащий текст это коллекция отдельных glyph boxes.
Ну вера это дело такое конечно.
Так-то Sciter он есть, и пробовать его никая религия не запрещает.
Писал я его сам.
Начинался Sciter еще в EverNote когда мы делали идею Стёпы Пачикова. Это вот вся EverNote команда в 2002-2003 году:
Где? Не вижу…
Сравнивать можно. И webkit парсит HTML и показывает его с CSS.
Также и Sciter, парсит HTML и показывает его с CSS. В своей версии и только те СSS фичи что для UI нужны.
Например эта вот дискуссия:
Видно что что-то в CSS не поддерживается, тем не менее содержимое ты видишь.
Фенечка в том что я могу Sciter доделать до уровня WebKit, но WebKit до уровня Sciter не дотянется никогда по многим причинам.
rendering speed (в два раза примерно), loading times (раз в 5-10), memory consumption (в 3-6 раз), какие-то функции вообще не сравнимы — нет аналогов в WebKit — не с чем сравнивать.
Например отрендерить DOM элемент в popup окне:
WebKit не умеет в принципе. Или вот HTML в круглом окне:
WebKit тоже не умеет.
Но части поддержки Web standards WebKit лучше. Просто в Sciter какие-то механизмы сделаны истоически по другому, например flexbox: terrainformatica.com/w3/flex-layout/flex-vs-flexbox.htm
Все базовые конструкции HTML5 в Sciter имплементированы. Я кстати участвовал в разработке HTML5 в W3C как invited expert.
А вообще осталось всего три движка которые умеют HTML/CSS более менее полно: WebKit, Gecko и h-smile core (движок Sciter)
Бенчмарк это измерение какой-то конкретной функциональности, какой в данном контексте?
Производительность UI это комплексная метрика.
Скажем VSCode (сделан на ElectronJS) при старте запускает как минимум 4 процесса (даже не потока). Один исполняет HTML/CSS/JS, второй рендерит на экран + RPC между этим всем. Понятно что single process Sublime Text будет быстрее. И это так и есть.
То же самое и с Sciter который делает всё то же что и ElectronJS только в 10 раз меньше. Какие-то операции тоже в разы быстрее — рисование в DirectX напрямую в Sciter например.
Да вроде на все вопросы ответил. Или нет?
Не делаю я JS. В смысле вообще. Я сделал Sciter Script для Sciter — он жил, живет и будет жить в Sciter Engine. В Sciter.JS будет использоваться стандарный JS с плюшками ( например native JSX как во взрослом Sciter и т.д. )
Потому что script там примерно 15% объема — остальное custom HTML/CSS rendering engine c DirectX, OpenGL, Vulkan graphic backends.
Sciter это HTML/CSS/tiscript — desktop UI engine.
Sciter.JS HTML/CSS/javascript — desktop UI engine — ElectronJS replacement, только в 10 меньше и для все платформ WinLinMac+Mobiles.
В качестве JavaScript могут использоваться в Sciter.JS как QuickJS++ (с моими патчами) так и V8.
Это так. Но есть еще сущесвующие customers как я уже сказал которые платят за подписку.
Далеко от реальной ситуации. Вот актуальные customers которые используют Sciter: sciter.com/#customers
Бенчмарки чего именно? Не ясно.
Ну вот скажем есть Sublime, а есть VSCode. Какие бенчмарки будут?
Sciter.JS планируется как BSD. Денег с BSD я не ожидаю. Вообще donation ware на таких проектах не работает.
kickstarter campaign, он на разработку именно Sciter.JS. Там нужны будут люди — как минимум еще два разработчика.
На сам Sciter денег лично мне вполне себе хватает от коммерческих пользователей. Открытие исходников самого Sciter это просто доп. мотивация для тех кому именно оно надо.
Более того, я (в том числе) её писал. Как Invited Expert @ W3C HTML5 WG и WHATWG.
Ты наверное не понял что я имею ввиду. Скажем у тебя есть HTML в кодировке UTF-8 на входе. Т.е. 50% твоего текста это ASCII. Зачем эти 50% вообще куда-то конвертировать?
Тебе нужно конвертировать содержимое text nodes. И некоторых атрибутов. И только. Зачем дурную работу делать?
А код я привел выше. Еще раз: www.codeproject.com/Articles/14076/Fast-and-Compact-HTML-XML-Scanner-Tokenizer
А зачем всё переводить в Unicode?
50% (условно) в HTML именно markup. Зачем эти 50% через конвертор-то гонять?
Как-то это не согласуется с заявленной целью «самый быстрый HTML-парсер c DOM.»
Не ясна модель встраивания в другие языки. Поэтому и вопросы.
Если бы ты (можно без «вы»?) определил изначально периметр встраивания (API другими словами) то было бы наверное более понятно что оно такое будет.
Скажем весь Sciter API это вот эта структура github.com/c-smile/sciter-sdk/blob/master/include/sciter-x-api.h — там реально 40 функций (DOM related).
Это чистые C functions хотя написаны на C++. И то на чем они написаны вообще никого не волнует. И не должно. Далеко не все «структуры» вообще могут быть выставлены наружу. Это банально опасно. Только контролируемый периметр.
«есть чёткое понимание как всё делать»
У меня было это состояние лет так 14 назад. И более того был реальный опыт создания WYSIWYG редакторов что близко к HTML (и там и там DOM, parsing и всё такое). Реальность как всегда оказалась несколько далека от изначальной теории.
Как я понимаю до слов harfbuzz (и вообще RTL), writing script itemizer and shaper, и прочая ты еще не добрался. (сужу по описанной структуре parser. Кому нужны эти «Character token» и что это вообще?)
«я вообще ещё не говорил о рисовалке.» и "… дерева отрисовки. Все расчеты, перерасчёты и так далее."
Ну да, теоретически ты можешь рассчитать положение примитивных прямоугольных блоков, но для glyph positioning придется учитывать такие вещи как ClearType и другие механизмы которые доступны на конкретных платформах и которые являются частью rendering механизма. Это суровая практика, сиречь необходимость. Без понятия архитектуры rendering с самого начала и как те glyphs оказываются в GPU памяти что-то практическое сделать невозможно.
И еще, я ни в коем случае не хочу тут рисовать картину маслом «Умерщвление прекрасной гипотезы мерзким фактом». Можно написать HTML/CSS/script engine и одному, собственно sciter есть тому подтверждение. Но нужно изначально определить «а user кто?». Для чего это всё? Т.е. почему проект который сейчас использует WebKit или Sciter должен перейти на твой движок?
Если это для того чтобы сделать что-то типа HTML-to-PDF утилиты, то это одно. Для UI же… С его анимациями и рисованием на 4K мониторе full screen и c 60 FPS это совсем другое — как минимум layout engine должен взаимодействовать с rendering engine чтобы получать вектора glyphs и прочая. DrawText примитивы уже не работают на таких потоках данных и скоростях.
И еще по поводу языка. Sciter написан на «C c классами» по большому счету. Ибо это удобно — т.е. позволяет быстрее и что главное надежнее писать. (Sciter примерно 100 тыс LOC). Это всё важно для one-man-project. А Mozilla вообще пилит Rust для того чтобы писать Servo — ручное управление памятью для проектов такого масштаба даже для них оказалось суровой задачей.
И по поводу Open Source. Не советую обольщаться на эту тему.
Есть два типа проектов: небольшие утилиты и что-то типа Electron. Первые имеют смысл для Open Source. Вторые же… Ну вот реально никого не парит что там внутри — реально количество людей которые лезут в детали WebKit или Gecko исчисляется десятками на всём шарике. И вот собственно и вся аудитория для open-sourse-ности проектов такого уровня. Тем более в свете последних скандалов с NPM ( в Microsoft Visual Code пролезла закладка которая тырит Bitcoins ) народ оченно печально настроен.
То что мы видим в OpenSource это верхушка айсберга. Реально же 90% софта это проекты по месту — внутренних IT отделов компаний. Да и те же китайцы. Любят они OpenSource. Но вот не знаю ни одного OS проекта финансируемого ими. Нет таких. Не потому что они такие-сякие, а потому что через их firewall такие платежи не сделать. Да и вообще поток статей типа FOSS is free as in toilet в последнее время оптимизма никак не внушает.
Из отличительных черт — не аллоцирует память в процессе работы. В смысле вообще. Классический finite state automata — pull parser.
История создания Sciter: sciter.com/10-years-road-to-sciter
«обрезанную версию движка для интерфейсов»
Не сказал бы что обрезанная ибо HTML5 и CSS3 (избранные модули) поддерживаются практически в полном объеме.
Вот «полноценный движок на Си» сделать действительно крайне сложно. С это не тот язык на котором такие вещи удобно писать.
И желание «встраивать в любой язык программирования» тоже вызывает вопросы.
Сейчас Sciter встраиваем в C/C++, C#, Rust, Python и Go. и написан на C++. Embedding API тот, да, plain C ибо другой альтернативы нет.
Но на самом деле встраивание в язык это дело десятое. Вот встраивание в существующие десктоп системы и графику это важно.
Сейчас Sciter может работать на Windows (XP … 10) c Direct2D/DirectWrite (DirectX), Skia (OpenGL) и GDI+ (прости мя сирого, хоспидя). На Mac — CoreGraphics и OpenGL(Skia), Linux/GTK (cairo или Skia). На подходе Andorid (OpenGL) и iOS (CoreGraphics или OpenGL).
Skia и Direct2D это C++ и только. Ибо Skia можно интегрировать только в исходниках а это С++. А Direct2D это IUnknown со товарищи, т.е. C++ опять же.
Без Skia и Direct2D (т.е. hardware acceleration) делать rendering engine можно и не начинать. 4K мониторы это наше все теперь. А на них только H/W acceleration — других опций и нет.
У меня это заняло два месяца этим летом.
Т.е. если привести это число к методике Windows (100% — загрузка всех ядер) то будет 1.5-3% что в общем согласуется с реальными цифрами.
Вот цифры на W10:
(там правда VS Code создает 6 процессов на это бедное окно, показан только rendering process)
Вот для сравнения Sciter c тем же Skia backend который использует Электрон.
Используется аналогичная по сложности структура экрана — редактор с подсветкой.
И для сравнения тот-же Sciter но c Direct2D backend: