Здравствуйте, CreatorCray, Вы писали:

P>>Десятки мегабайт.
CC>99МБ это тоже "десятки", нельзя ли более проверяемые цифры называть?

Читаем вместе ответ на твой вопрос:

P>>Атом справляется где то с сотней мб.
CC>Ок. А кто должен справляться но не справляется?

P>>Пример — никто в своём уме не пишет GUI игрушки на плюсах.
CC>Что ты понимаешь под "GUI игрушки"?

Известно что. Например, весь hud. Щас ты наверное скажешь, что "а на самом деле рендеринг на плюсах!!!!!!11111qqqqaaaa"

P>>Не стоит забывать, что бОльше всего багов и уязвимостей находится именно в нативном коде...
CC>Не стоит забывать что это твои фантазии, ничем не подкреплённые.

Это азбучные истины. Смысл разделения на скрипты и нативный код в т.ч. и мЕньшее количество уязвимостей.
В том же жээсе бОльшая часть уязвимостей на самом деле в нативной части. Собственно так со всеми скриптами.
В том же дотнете/джаве бОльше всего уязвимостей или в нативной части, или в связке с нативным кодом.

Загляни в списке CVE-xxxx-yyyyy, всё в открытом доступе. Берем линукс кернел, смотрим вместе, первые ссылки на сегодняшний день

A null pointer dereference issue was discovered in fs/io_uring.c in the Linux kernel before 5.15.62

drivers/scsi/stex.c in the Linux kernel through 5.19.9

An issue was discovered in the Linux kernel through 5.19.8. drivers/firmware/efi/capsule-loader.c has a race condition with a resultant use-after-free.

CC>>>Нет, икемфула, чтоб родить что либо сносно на вебе шевелящееся тоже понадобится квалификация.
P>>...при чем именно в том коде, который писали светила индустрии.
CC>на жабаскрипте, попрошу заметить

А я говорю о том, что странно видеть обилие уязвимостей в нативном коде, когда его писали светила индустрии.

P>> А вот дыры ОС, браузера, бд, итд не могут и по сей день пофиксить, хотя коду 20-30 и более лет.
CC>Какие именно? Или это опять так, для красного словца ляпнуто?

А тебе ктото запрещает CVE-XXXX-YYYYY посмотреть?

P>>Ога. Сколько у тебя лет опыта было, когда ты свой фремворк пилил? Довел до прода?
CC>Опыта в чём именно? В UI фреймворках считай никакого.

Всего опыта в разработке сколько было на плюсах?

P>>Логическая ошибка. Скитера не было "в каждой книге по программированию".
CC>То, что я написал тоже не было "в каждой книге по программированию"

А я пишу о том, что UI фремворк это хороший тренировочный материал, потому в книгах он встречался регулярно.
Я это проделывал и на паскале, и на ассемблере, и на Си, и на Си++, и Сишарпе.

P>>Твой фремворк кроме тебя кто нибудь тестировал? Кто, кроме тебя использовал, сколько команд?
CC>Я его под нужды своего личного проекта написал.

В таком случае странно использовать это как аргумент. У нас нет никакой возможности оценить качество твоего фремворка, как с т.з. кода, так и с т.з. заявленых возможностей, сроков, сложности сопровождения итд.
То есть, аргумент понятный исключительно одному тебе.

P>>Ты странный — когда я попросил привести парочку примеров где жээс глючит, ты мне сходу нахамил,
CC>Я писал про отдельные кривые сайты, где напихали скриптоты что они с трудом проворачиваются, а не про "жээс глючит". Так что это ты сам к себе претензии выдвигай, ибо обсуждать что либо в сценарии "сама придумала — сама обиделась" мне не интересно.

Ты или смысла слов не понимаешь, или не готов отвечать за свои слова:

Юг там, вьюноша. Впрочем судя по тону твоего вопроса ты и так хотел туда прогуляться.

Вот это прямое оскорбление, только завуалированое.

P>>Насколько я помню, фар рисует через что нибудь навроде ReadConsoleOutput и WriteConsoleOutput.
CC>А на экране оно святым духом появляется?

Нас интересует не внутреннее устройство этих функций, а сложности рендеринга на стороне приложения.
UI в таком духе, как в ФАР, используя эти функции, это уровень лабораторной работы примерно 2й-3й курс, когда только начинают Winapi изучать.

P>>Что ты там считать собрался, если количество знаков в ширину-высоту известно заранее, размер шрифта задан заранее?
CC>Расчёт положения это банальная арифметика, операция сложения, начальная школа. Отрисовка глифов шрифта занимает на порядки больше ресурсов чем эта ерундистика.

Именно. И ФАР ничем таким не занимается, т.к. это консольное приложение. Все что он делает, это посылает туда сюда буферы вида "строка"-"цвет фон-символ".

P>>И отличия в рендеринге ты не видишь, да?
CC>Отличия микроскопические, так что не интересно. В IDE для кода точно так же используется моноширинный шрифт, так что ты сейчас просто очередную сову мучаешь.

Ровно наоборот — в консоли сложность рендеринга считай равняется сложности склейки строк. IDE рисует совсем не так, как фар.
А теперь смотрим вместе, сколько когда занимает рендеринг в той же Сцинтилле — по самой скромной оценке десятки килобайт кода. И там много разных нюансов.

P>>Это все еще низкоуровневый рендеринг, тк мы оперируем примитивами — строка, координаты, хендл, итд. Высокоуровневые примитивы — текст+ стили.
CC>Если для тебя это низкоуровневый то у меня для тебя пачка забавных новостей.
CC>Нет, это ещё не низкий уровень.

Текст+стили — это высокий. Всё остальные — низкий.
Очевидно, в твоем TextOutput ничего высокоуровнего нет и быть не может.

P>>Сравни "нарисуй строку по координатам с цветом в такой то хендл"
CC>Сравни рисование строки на уровне изменения цвета конкретных пикселей в памяти — вот это уже низкий уровень.

Низкость-высокость это про уровень абстракций прежде всего. Высокий уровень это такой, когда бы рисуем в единицах абстракций пользователя, то есть, текст, стили, итд. Все остальное — низкий.

P>>Нужен внятный рендеринг, что бы выглядело красиво, глаза не уставали. Большинство рендереров этого не умеют.
CC>В pdf.js нету своего рендеринга, тупо используются функции браузера.

Снова Мистер Осведомленность Кто мешает тебе открыть страничку
https://mozilla.github.io/pdf.js/web/viewer.html
и кликнуть правой кнопкой мыши на странице? Появляется "Save image". А если вбить в devtools document.querySelectorAll('canvas'), то увидишь кучку канвасов, каждый из которых соответствует какой то странице на экране
Кто, по твоему, создает эти картинки?

на самом деле в pdf.js два рендерера
1. изображение, обычная 2D графика, canvas растет отсюда
2. текстовый слой, для селекшна, поиска и тд. Рендерится DOM-дерево.

Собственно, если присмотреться, то видно, что pdf.js дает довольно качественную картинку — это не просто швыряние текста.
А если порыться в исходниках, то можно найти вот такое
https://github.com/mozilla/pdf.js/blob/master/src/core/font_renderer.js

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

P>>Далее, нужна частичная подгрузка, чтобы не всасывать все 20000 страниц (не знаю, зачем верстают такие книги)
CC>Это вообще встроенная фича формата PDF

И давно у тебя формат сам себя загружает? Обычно это делает конкретная либа, которая или грузит всё, или по частям. И вот большинство идут по варианту "грузить всё" т.е. предполагают что документ обычно небольшой.

P>>>>Пока что никто не смог обогнать акробат адобовский, ни на чем.
CC>>>Foxit, не?
P>>Проект длился много лет и закончился в 17м после n версий на 4х платформах. Что там было на тот момент с фокситом, я не помню.
CC>Ты так и не ответил на вопрос.

На какай именно? Чем закончилась проверка Foxit я не в помню. Остановились на pdf.js для мака/винды и еще по одному для ios и android, не помню какие. Проект то был аналог Киндла — магазин, библиотека, приложение для чтения разных форматов, заметки, редактирование, лицензии, подписки, итд, а не просто открывалка для пдф.