Здравствуйте, c-smile, Вы писали:
_>>Я говорю не про какую-то свою конкретную имплентацию, а наоборот про тот факт, что без чёткого описания конкретной задачи и точного описания решения невозможно сказать какой алгоритм будет эффективнее — недостаточно знания асимптотической сложности для ответа на данный вопрос. Это и есть мой основной посыл в данной дискуссии. CS>Мы обсуждаем имплементацию некой абстрактной DrawLine(p1,p2, color, width) которая в случае DirectX/OpenGL есть опять же некая абстрактная FillQuad(p1,p2,p3,p4,color). CS>FillQuad это "атомарная" операция для DirectX и OpenGL и O(1) для CPU сколько бы там pixels не нарисовалось в результате.
Да, это O(1) по пикселям, но операция совсем не атомарная. Даже если посчитать, что компиляция шейдеров, их линковка, активация и запрос идентификаторов атрибутов происходит где-то заранее (т.е. у нас тупо программка умеющая только линии рисовать, без всяких эффектов, текстур и т.п. — для них то потребуется переключение на другие шейдеры), то всё равно операция не будет атомарной, т.к. потребуются как минимум отдельные шаги на создание и загрузку массива атрибутов вершин (в данном случае координат) и только потом будет отдельный шаг инициирующий рендеринг. И это ещё даже без возможности указания цвета и других возможных атрибутов (там возможно понадобятся отдельные массивы).
CS>Понятно что не все Direct2D функции настолько просто переводятся в вызовы FillMesh и FillQuad. Но базовый архитектурный принцип для Direct2D это именно быть O(1) для CPU.
Мы же вроде уже обсудили, что факт асимптотической сложности O(1) совершенно не гарантирует, что алгоритм будет исполняться быстрее, чем O(N).
_>>Так я как бы не против GPU. Собственно я в своих проектах всю графику рисую через OpenGL и моя основная GUI библиотека (Qt) делает аналогично. Но как раз поэтому я вполне себе в курсе того факта, что у рисования через GPU есть свои неудобные нюансы. CS>Нюансы (a.k.a. implementation details), да. CS>И кстати Qt из-за того что она/он/оно приколочено гвоздями к OpenGL будет послабже чем Direc2D/DirectX.
1. В Qt используется даже не OpenGL, а OpenGL ES и за счёт этого единый код отрисовки работает не только на Windows/OSX/Linux, но и на Android/iOS и даже на устройствах вообще без ОС (но с наличием OpenGL ES ускорителя).
2. Насчёт того, что OpenGL послебее DirectX — это мягко говоря сомнительное высказывание. Достаточно взглянуть например на такие https://www.slideshare.net/CassEveritt/approaching-zero-driver-overhead материалы (там ближе к концу есть и результаты измерений).
3. При этом если всё же по каким-то причинам (например у OpenGL есть некие нюансы с RDP) хочется использовать под виндой именно DirectX драйверы к карте, для этих целей у нас есть библиотечка ANGLE от Гугла, которая реализует полноценный OpenGL ES интерфейс поверх Direct3D. Эту библиотеку используют и основные браузеры и Qt (качество опции при сборке под винду) и ещё много другого серьёзного ПО. Однако в моих проектах она не пошла, потому что никакого принципиального изменения производительности от переключения на неё я не увидел, а вот некоторые специфические возможности полноценного OpenGL потерялись (например нативный OpenGL умеет многопоточную работу, когда в одних потоках идёт загрузка данных в некий контекст, а в других рендеринг в том же контексте, а в ANGLE это перестаёт работать).
CS>У sciter есть как Direct2D так и Skia(исп. OpenGL) backends — сравнивать приходится постоянно. Не думаю что Skia (google) и rasterizer в Qt как-то уж сильно отличаются.
Кстати у Skia помнится был бэкенд в виде ANGLE — можешь легко сравнить производительность с Direct2D. Да, а ещё я смотрю у Skia появился бэкенд и поверх Vulkan — в теории это должен быть быстрее всего! )
CS>В OpenGL какие-то проблемы с renderbuffer — offline buffered rendering в отдельных случаях нужен. Я обсуждал возможную имплементацию Push/PopLayer с Mikko Mononen (автор NanoVG), он был даже что-то сделал. Но он сказал что "OpenGL's renderbuffer sucks".
Просто не надо тащить в OpenGL подходы из 2D графики — оно всё же ориентируется в первую очередь на 3D и шейдеры, а не на рисование квадратиков на экране. Т.е. последнее тоже без проблем, но надо понимать как это сделать оптимальнее, а не в стиле рисований из GDI.
_>>Не пофигу, потому что переход в режим ядра — это весьма и весьма тяжело. И этого дела при рисование через GPU гораздо больше, чем при рисование в память (где оно собственно только одно финальное). CS>И в том и в том случае пересылка (переход в режим ядра?) делается условно говоря один раз: CS>- Direct2D -> пересылка vertex data (not dependent on number of pixels — O(1)) CS>- GDI -> пересылка bitmap data (dependent on number of pixels — O(N))
См. первый абзац данного сообщения — у DirectX очевидно не один раз. )
CS>У жены-орлицы понимаешь дальнозоркость, а у меня близорукость. Т.е. она видит на телевизоре "отдельные лампочки". Что-бы ей было нормально с того дивана (ака забор) его смотреть должен быть high-DPI device. CS>Иначе телевизор надо уносить фиг знает куда чтобы "угловой размер отдельных лампочек" уменьшить. Но в этом случае я его смотреть не смогу. CS>Т.е. high-DPI это суровая правда семейной жизни.
Хы, так если там достаточный DPI, чтобы она не видела пикселей, то в таком случае ты со своей близорукостью просто не будешь видеть половину детализации. ))) Так что это не вариант решения проблемы — надо или очки носить или корректировать зрение.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, c-smile, Вы писали:
_>>>Я говорю не про какую-то свою конкретную имплентацию, а наоборот про тот факт, что без чёткого описания конкретной задачи и точного описания решения невозможно сказать какой алгоритм будет эффективнее — недостаточно знания асимптотической сложности для ответа на данный вопрос. Это и есть мой основной посыл в данной дискуссии. CS>>Мы обсуждаем имплементацию некой абстрактной DrawLine(p1,p2, color, width) которая в случае DirectX/OpenGL есть опять же некая абстрактная FillQuad(p1,p2,p3,p4,color). CS>>FillQuad это "атомарная" операция для DirectX и OpenGL и O(1) для CPU сколько бы там pixels не нарисовалось в результате.
_>Да, это O(1) по пикселям, но операция совсем не атомарная. Даже если посчитать, что компиляция шейдеров, их линковка, активация и запрос идентификаторов атрибутов происходит где-то заранее (т.е. у нас тупо программка умеющая только линии рисовать, без всяких эффектов, текстур и т.п. — для них то потребуется переключение на другие шейдеры), то всё равно операция не будет атомарной, т.к. потребуются как минимум отдельные шаги на создание и загрузку массива атрибутов вершин (в данном случае координат) и только потом будет отдельный шаг инициирующий рендеринг. И это ещё даже без возможности указания цвета и других возможных атрибутов (там возможно понадобятся отдельные массивы).
Да пофигу. Всё это вышеизложенное не зависит от кол-ва пикселей т.е. как ты и сказал — O(1).
Важно то что если оно рисует на 2000*1600 то и на 4000*3200 оно будет рисовать с тем же FPS (CPU consumption).
CS>>Понятно что не все Direct2D функции настолько просто переводятся в вызовы FillMesh и FillQuad. Но базовый архитектурный принцип для Direct2D это именно быть O(1) для CPU.
_>Мы же вроде уже обсудили, что факт асимптотической сложности O(1) совершенно не гарантирует, что алгоритм будет исполняться быстрее, чем O(N).
_>>>Так я как бы не против GPU. Собственно я в своих проектах всю графику рисую через OpenGL и моя основная GUI библиотека (Qt) делает аналогично. Но как раз поэтому я вполне себе в курсе того факта, что у рисования через GPU есть свои неудобные нюансы. CS>>Нюансы (a.k.a. implementation details), да. CS>>И кстати Qt из-за того что она/он/оно приколочено гвоздями к OpenGL будет послабже чем Direc2D/DirectX.
_>1. В Qt используется даже не OpenGL, а OpenGL ES и за счёт этого единый код отрисовки работает не только на Windows/OSX/Linux, но и на Android/iOS и даже на устройствах вообще без ОС (но с наличием OpenGL ES ускорителя). _>2. Насчёт того, что OpenGL послебее DirectX — это мягко говоря сомнительное высказывание. Достаточно взглянуть например на такие https://www.slideshare.net/CassEveritt/approaching-zero-driver-overhead материалы (там ближе к концу есть и результаты измерений). _>3. При этом если всё же по каким-то причинам (например у OpenGL есть некие нюансы с RDP) хочется использовать под виндой именно DirectX драйверы к карте, для этих целей у нас есть библиотечка ANGLE от Гугла, которая реализует полноценный OpenGL ES интерфейс поверх Direct3D. Эту библиотеку используют и основные браузеры и Qt (качество опции при сборке под винду) и ещё много другого серьёзного ПО. Однако в моих проектах она не пошла, потому что никакого принципиального изменения производительности от переключения на неё я не увидел, а вот некоторые специфические возможности полноценного OpenGL потерялись (например нативный OpenGL умеет многопоточную работу, когда в одних потоках идёт загрузка данных в некий контекст, а в других рендеринг в том же контексте, а в ANGLE это перестаёт работать). _>Кстати у Skia помнится был бэкенд в виде ANGLE — можешь легко сравнить производительность с Direct2D. Да, а ещё я смотрю у Skia появился бэкенд и поверх Vulkan — в теории это должен быть быстрее всего! )
ANGLE существует потому как OpenGL (а особенно OpenGL ES) это subset DirectX функциональности. В любом случае это доп. layer который скорости не прибавляет.
DirectX работает быстрее не только из-за того что драйвера лучше но також из-за лучшей архитектуры. Stateful OpenGL это просто ужас для multithreading и pipeline интеграции.
CS>>В OpenGL какие-то проблемы с renderbuffer — offline buffered rendering в отдельных случаях нужен. Я обсуждал возможную имплементацию Push/PopLayer с Mikko Mononen (автор NanoVG), он был даже что-то сделал. Но он сказал что "OpenGL's renderbuffer sucks".
_>Просто не надо тащить в OpenGL подходы из 2D графики — оно всё же ориентируется в первую очередь на 3D и шейдеры, а не на рисование квадратиков на экране. Т.е. последнее тоже без проблем, но надо понимать как это сделать оптимальнее, а не в стиле рисований из GDI.
"не надо тащить" а приходится, это вот:
<div style="opacity:0.7">
... more stuff here ...
</div>
иначе как сначала в буфер отрисовать, а потом уже это буфер с opacity вывести не поучается. В результате и Skia и Qt вынуждены имплементировать две параллельные pipeline : и CPU и GPU имплементацию всех примитивов. Что- радости не добавляет. Т.е. и Skia и Qt могут внезапно из O(1) стать O(N) если "дезигнеру" transparency вступит в голову.
К слову NanoVG это чистая GPU <canvas>/2d graphics имплементация, можно сравнить со Skia и Qt по размеру.
Re[7]: Что на самом деле произошло с Windows Vista
Здравствуйте, c-smile, Вы писали:
CS>Смотри: имеем сейчас native имплементации HTML/CSS которые работают на существующем железе. Но вот для C# (Java, whatever) имплементации HTML/CSS нужно железо в разы (а во сколько раз кстати?) лучше.
Мне думается, что железо и так давно готово. А вот рантаймы и библиотеки — нет.
В C#/Java/whatever мы упираемся в критические ограничения рантаймов в большей степени, при этом нэйтив кроме того, что обладает традиционно лучшей кодогенерацией, так и "flexibility", т.к. критичные компоненты (GC) имеют специальную заточку, а не что-то среднее по палате.
Т.е. для имплементации браузера "A"-класса, на managed платформе, имхо, нужно:
— иметь возможность решать все вопросы с GC кардинально (но на практике — никто не будет заменять одно на другое, да и будет ли выигрыш);
— для плавных анимаций: сборка мусора должна выполняться максимально быстро. Можно часто, но быстро, например в пределах 6ms, оставляя 10ms для других работ в кадре. И при этом ещё нужно уметь её чётко шедулить. Афаик, добиться и первого и второго довольно трудно в традиционных managed платформах. В противовес этому, blink шедулит сборку мусора V8 именно на основе статистики сборки мусора и старается её выполнить в такой момент, который не оборвёт кадр.
Выдумки:
— (opt) finalizers нужны, но например, при закрытии документа финализаторы для определённых типов не нужны. Хотя это наверное экономия на спичках.
— (opt) работа under memory pressure не должна приводить к судорожным попыткам найти чего бы нам там можно было бы освободить, что в условиях ещё и активного своппинга лишь подымает ненужны страницы, и в итоге полезной работы вообще никакой не делается. При этом источник memory pressure может быть иное приложение пользователя. Многопроцессные браузеры кстати неплохо выигрывают тут, благодаря установке low/idle приоритета для таких субпроцессов. Но, т.к. мы говорим ещё и о встраивамом движке — я рассматриваю нормальный in-process flow.
— (продолжение предыдущего) я бы предпочёл разделять кучи отдельно, по документам, с прицелом на возможность грохать кучу целиком, так и "замораживать" работу с ней, если она не нужна. Ну т.е. типичный пример: в браузере открыто тучка вкладок. Но видна только одна. Если на background страницах нет никаких таймеров/скриптинга/поллинга, то у нас просто не должно быть никаких оснований обращаться к куче. На x86 это может быть спорно, но на x64 — в рамках одного процесса, проблем с этим не должно быть.
Короче говоря, текущие рантаймы даже близко ничего подобного не предлагают, и не будут, т.к. заточены совсем на другое.
Имхо, .NET GC справится с типичной нагрузкой реальных/вменяемых веб страниц с контентом довольно легко. Пруфов нет. А с анимациями — нет, не справится, т.к. шедулить его так как нужно в общем случае невозможно. Как и нет второстепенных ручек, навроде политики роста кучи и т.п. Если прикрутить скриптинг типа V8 — то возникает вопрос — нафига дотнет.
А от "managed" языка нужно:
— возможность эффективно/удобно выделять объекты на стэке, а не только в куче. (Я считаю, что C++ код честно говоря зачастую чрезмерно полагается на это, делая свою работу в итоге странноватым образом, но тем не менее, отрицать необходимость такой возможности глупо, даже в CoreCLR Span<T> фактически завязан на это). Ни у C#, ни у Java вменяемой замены этому нет: первый со своими структурами в общем-то это делает, но это не совсем удобно. Второй может что-то оптимизировать, но оптимизиации... могут быть, а могут и не быть = нет никаких гарантий. Пока в целом (для дотнета/C#) видно только робкие подвижки в эту сторону.
— возможность нормально интегрироваться с C кодом. (PInvoke — это ненормально, JNI — это античеловечно. Гуманно поступают те, кто позволяют сделать #include с набором предварительно заданных дефайнов).
— возможность нормально интегрироваться с C++ кодом, в API которого учавствуют хотя бы не сложные шаблоны (т.е. без магии, но всё же шаблоны). Иначе перестанут быть доступны библиотеки наподобии Skia или V8, может ещё чего полезное. Даже если представить, что доступно C API из коробки — надо ещё проверять, насколько оно юзабельно/эффективно. Ну или искать замену библиотекам, что... В принципе, супер компилятор тут не нужен, скажем если положиться на LLVM, то можно вполне эффективно использовать собственные прослойки для работы с таким. Но ведь именно на статическую линковку и приличную оптимизацию времени линковки, положиться и нельзя. Увы.
— опять возвращаясь к GC: возможность применять GC только к интересующим объектам, и "не платить" за него, когда он не нужен. Даже если этих мест где GC строго противопоказан ограниченное количество — с этим прийдётся что-то делать. Опять же, не думаю, что это краеугольный камень, в C# мы даже можем нечто подобного достичь, честные указателями у нас всё таки есть. Но это опять из области ненормальностей, да и фактически с потерей всех плюсов языка. Ну и вообще, похоже все хотят такую фичу в своих любимых языках.
В рантайме безусловно должен быть приличный JIT или возможность AOT (с хорошим качеством). .NET тут традиционно пролетает от слова совсем.
В идеальном мире, половина пунктов, не нужна, весь код у нас написан на том же самом языке и нет сторонних библиотек и т.п. Но, т.к. по факту этого нет... Намного более предсказуемый результат будет у C++. Что в целом мы и видим.
Но, повторю свой посыл: имхо, возможностей текущих рантаймов и железа должно хватать за глаза для контенто-содержащих страниц. "Странички" навроде fishie и прочие пёрлы — это что-то не то, на мой взгляд. Но... браузеры теперь обыязаны заниматься и этим. Серьёзно же пилить движок, который будет "сливать" конкуретнам — думаю смысла нет, поэтому никто опять таки серьёзно даже и не пробует. Сейчас он даже на electron-е делают приложения, которым нафиг не впилось 90% возможностей движка. А невменяемый размер + форсированная многопроцессность + часто далеко не хороший UI, а это никого не останавливает. Вот GitKraken при старте показывает окошко логина: на это он тратит 5 процессов, в сумме 36+11+14+33+17=111 потоков, и в сумме 460Mb памяти, и то я думаю где-то подвирает... Да самый примитивный рендерер на .NET (безусловно с неравными общими характеристиками) будет в разы лучше, чем это. Что в прочем Sciter и демонстрирует. С другой стороны, в том же GitKraken "Login via GitHub" подозреваю сделано в большей степени как раз благодаря "честности" и полновесности нижележащей "веб платформы". Но, я лично, всё равно решительно против многопроцессности, когда она не оправдана, а она оправдана только для приложений работающих с неизвестным контентом.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, c-smile, Вы писали:
V>>>Тоже неправда. Линии/прямоугольники/полигоны и т.д. рисуются в GDI одной командой, то бишь, O(1).
CS>>
CS>>... the BitBlt API was hardware accelerated and most other GDI operations were not.
V>Это ошибочная цитата и тебе уже не раз об этом говорилось.
Эта цитата еще более ошибочна для этой глубины спора. ))
Тебе сразу же и указали чуть ли не в первом ответе, что ускорение открутили только в Висте.
А так-то, по твоей же ссылке написано — GDI ускорял даже вывод текста.
Ну и я уже давал ссылки на описание технологий ускорения вывода текста в GDI через ресурсы карточки.
Здравствуйте, Ikemefula, Вы писали:
I>Тебя очень трудно понимать, потому что пишешь обрывками и твои сообщения большей частью невозможно перепроверить.
Судя по чуши, которую ты пишешь в ответ ты вообще не читаешь что я пишу.
I>А вот совсем недавно ты наскакивал на GDI+
Я нигде и никогда не "наскакивал на GDI+".
I> и привел в подтверждение своих слов ссылку на этот самый WPF. сходи и прочитай наконец внимательно что в том посте написано.
I>И как теперь понимать твои заявления ?
Перечитать ещё раз, внимательно, не додумывая.
Здравствуйте, Ikemefula, Вы писали:
I>То есть, фактически получается так, что вы с c-smile говорили каждый про своё, про GDI и GDI+. Поздравляю.
Казалось бы, если написано GDI значит речь про GDI. Если написано GDI+ значит речь про GDI+.
У тебя что, fuzzy parser что ли? Читаем А понимаем как Z?
Здравствуйте, Ikemefula, Вы писали:
I>у тебя аномальный результат и непонятно чем его можно объяснить.
Лично мне хочется понять конкретно почему он такой аномальный.
Что ты тут делаешь мне непонятно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[8]: Что на самом деле произошло с Windows Vista
Здравствуйте, Mystic Artifact, Вы писали:
MA> Я как-то так и не увидел толковых попыток HTML/CSS renderers на managed языках вообще (да и на нэйтиве их не так уж много).
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, Mystic Artifact, Вы писали:
MA>> Я как-то так и не увидел толковых попыток HTML/CSS renderers на managed языках вообще (да и на нэйтиве их не так уж много).
R>https://htmlrenderer.codeplex.com/ (о производительности)
Но как-то сразу увиделось что делать это в managed code — нереально, много дурной работы для GC.
GC хорош когда относительно мало объектов — т.е. в качестве memory manager верхнего уровня.
Ну вот никому не нужен managed компонент который к толпе managed business layer объектов еще добавляет на порядок больше всякой фигни типа List<Word>. Это кроме того что там еще несколько крайне спорных архитектурных решений...
Вообще делать html/css rendering (a.k.a. много дурной работы) component только для .NET представляется рискованным бизнес-занятием. Для упражнения разве что...
Re[9]: Что на самом деле произошло с Windows Vista
Здравствуйте, rudzuk, Вы писали:
MA>> Я как-то так и не увидел толковых попыток HTML/CSS renderers на managed языках вообще (да и на нэйтиве их не так уж много).
R>https://htmlrenderer.codeplex.com/ (о производительности)
Я видел его давненько, и всё что насмотрел уже забыл. Поэтому остаётся вопрос насколько он толково реализован?
Re[9]: Что на самом деле произошло с Windows Vista
Obviously I didn't have any desired performance goal I wanted to reach, I don't really believe developer can really have those, I stopped when the code performance felt right for what it does and the profiler showed code that was either not easy or impossible to optimize.
I do believe Html Renderer can be optimized more as its algorithm breaks the html into words, computes layout and draws each word separately. Merging words into block by style will probably improve performance but it will require going much deeper into the code and gaining 10 msec for that is just not worth it.
Т.е. на определённом моменте автор решил, что оно работает приемлимо. Поэтому, сравнивать это с нэйтивами с целью ответить на вопрос готово ли железо и/или платформа — не честно.
Здравствуйте, c-smile, Вы писали:
CS>GC хорош когда относительно мало объектов — т.е. в качестве memory manager верхнего уровня.
Всё таки это не совсем корректно. Время работы GC прямопропорционально числу живых объектов. Соответственно верхний потолок определяется исключительно железом.
UPD: Просто непонятно что такое "мало" объектов. Кому-то это тысячи, кому-то несколько миллионов.
CS>Ну вот никому не нужен managed компонент который к толпе managed business layer объектов еще добавляет на порядок больше всякой фигни типа List<Word>. Это кроме того что там еще несколько крайне спорных архитектурных решений... CS>Вообще делать html/css rendering (a.k.a. много дурной работы) component только для .NET представляется рискованным бизнес-занятием. Для упражнения разве что...
Я то в целом с тобой согласен, и я не знаю как ты подобные вещи реализуешь в Sciter, но приблизительно подобные вещи я и имел ввиду под толковостью реализаций + лидеры явно не отличаются наивностью в реализациях. Поэтому не вижу смысла в прямом сравнении. Да и в целом — думаю, что в этом вопросе, более чем достаточно мнения человека с опытом (т.е. твоего), и на этом остановиться.
Здравствуйте, Mystic Artifact, Вы писали:
MA>Здравствуйте, c-smile, Вы писали:
CS>>Смотри: имеем сейчас native имплементации HTML/CSS которые работают на существующем железе. Но вот для C# (Java, whatever) имплементации HTML/CSS нужно железо в разы (а во сколько раз кстати?) лучше. MA> Мне думается, что железо и так давно готово. А вот рантаймы и библиотеки — нет.
В общем-то дело не в рантаймах и библиотеках.
В принципе можно было бы и в WPF написать html/css renderer сопоставимый с тем же sciter.
Загнать rendering tree representation в blob (byte[]) чтобы GC и не думал весь этот кошмар трогать. Ну и всякое такое.
Просто это никому не надо — не business-viable никак — проект большой и делать его для в общем-то нишевой технологии... Денег на это никто не даст.
Еше раз: .NET работает хорошо когда он манипулирует эффективными components не создающим нагрузку на GC.
MA> — для плавных анимаций: сборка мусора должна выполняться максимально быстро. Можно часто, но быстро, например в пределах 6ms, оставляя 10ms для других работ в кадре. И при этом ещё нужно уметь её чётко шедулить.
Не понял я этого вот щаз... Для плавных анимаций нужно в принципе только уметь быстро рисовать.
Если быстро не получается то приходится использовать в CSS translate3d() trick. (На самом деле крайне вредный совет)
В этом случае browser вынужден загонять элемент в 3D texture (image buffer) и анимировать контент как один image — трансформации текстур GPU умеют делать хорошо.
В iOS кстати все stock анимации это именно манипуляции с OpenGL текстурами или что-то аналогичное. Сам по себе набор CoreGraphics (graphics в iOS, MacOS) это штука не сильно лучше чем GDI+ , т.е. чистый CPU rasterizer.
Re[9]: Что на самом деле произошло с Windows Vista
Здравствуйте, c-smile, Вы писали:
MA>> — для плавных анимаций: сборка мусора должна выполняться максимально быстро. Можно часто, но быстро, например в пределах 6ms, оставляя 10ms для других работ в кадре. И при этом ещё нужно уметь её чётко шедулить. CS>Не понял я этого вот щаз... Для плавных анимаций нужно в принципе только уметь быстро рисовать. CS>Если быстро не получается то приходится использовать в CSS translate3d() trick. (На самом деле крайне вредный совет) CS>В этом случае browser вынужден загонять элемент в 3D texture (image buffer) и анимировать контент как один image — трансформации текстур GPU умеют делать хорошо. CS>В iOS кстати все stock анимации это именно манипуляции с OpenGL текстурами или что-то аналогичное. Сам по себе набор CoreGraphics (graphics в iOS, MacOS) это штука не сильно лучше чем GDI+ , т.е. чистый CPU rasterizer.
Эээ... Меня переклинило на тот неудобный случай, когда кадр готовится JS и генерирует кучу мусора на куче. Поэтому мусор собирать всё же необходимо, но на любом попавшемся idle этого лучше не делать, т.к. это с высокой вероятностью порвёт кадр (хотя хромы несколько лет назад так и делали, и думаю многих это вообще не парило). Т.е. да — нужно уметь быстро рисовать И не мешать этому сборкой мусора. Сейчас блинк занят шедулингом сборки кучи V8, когда эвристики ему говорят, что он может уложиться в выделенное время, + судя по всему отобрали возможность у GC шуршать до победного конца.
Здравствуйте, CreatorCray, Вы писали:
I>>То есть, фактически получается так, что вы с c-smile говорили каждый про своё, про GDI и GDI+. Поздравляю. CC>Казалось бы, если написано GDI значит речь про GDI. Если написано GDI+ значит речь про GDI+.
Казалось бы, если речь про скитер, то там может быть только gdi+ а не gdi. А теперь перечитай и себя, и c-smile.
Здравствуйте, CreatorCray, Вы писали:
I>>у тебя аномальный результат и непонятно чем его можно объяснить. CC>Лично мне хочется понять конкретно почему он такой аномальный.
Лично ты обвиняешь в вранье, некомпетенции, вешаешь ярлыки и много чего еще. У меня это не ассоциируется с "хочется понять". Посмотри, какие у тебя аргументы в адрес того же c-smile
CC>Что ты тут делаешь мне непонятно.
Здравствуйте, CreatorCray, Вы писали:
I>>А вот совсем недавно ты наскакивал на GDI+ CC>Я нигде и никогда не "наскакивал на GDI+".
Ога. Посмотри чего ты писал про скитер и какого сорта у тебя аргументы были.
I>> и привел в подтверждение своих слов ссылку на этот самый WPF. CC> сходи и прочитай наконец внимательно что в том посте написано.
Вместе почитаем, не возражаешь ?
Все D2D/DW text rendering примеры что я видел очень конкретно заикались на сравнительно небольшом колве текста в сравнении с тем, что мне было надо.
Но хуже всего было то, что на небольших размерах шрифта и стандартном DPI они рисовали плохо читаемое мыло.
Вот тут интересный анализ как например WPF рендерит шрифты:
Здравствуйте, c-smile, Вы писали:
CS>Да пофигу. Всё это вышеизложенное не зависит от кол-ва пикселей т.е. как ты и сказал — O(1). CS>Важно то что если оно рисует на 2000*1600 то и на 4000*3200 оно будет рисовать с тем же FPS (CPU consumption).
Ну так а если у тебя один алгоритм будет рисовать и UHD и FHD кадр за 50 мс (твоё любимое O(1)), а другой будет рисовать UHD за 100 мс и FHD за 25 мс (то самое ужасное O(N)), то какой ты станешь использовать? )))
CS>ANGLE существует потому как OpenGL (а особенно OpenGL ES) это subset DirectX функциональности. В любом случае это доп. layer который скорости не прибавляет.
Конечно же не прибавляет, но и особо не убавляет, т.к. это у нас C++ и все функции в стиле обёрток (а таких там большинство) просто исчезают после прохода оптимизатора. Собственно из реально алгоритмических кусков там наверное только транслятор из одного языка шейдеров в другой, но он обычно отрабатывает на этапе инициализации приложения.
По сути Skia+ANGLE==Direct2D. А вот кто из них эффективнее зависит от их внутренних алгоритмов использования GPU — я таких замеров не видел.
CS>DirectX работает быстрее не только из-за того что драйвера лучше но також из-за лучшей архитектуры. Stateful OpenGL это просто ужас для multithreading и pipeline интеграции.
Это ты какую-то ерунду написал. Эти два API боролись между собой уже очень давно и в разные периоды (версии) то один был лучше, то другой. Если мы возьмём последние API доступные для самой популярной десктопной ОС в данный момент (сейчас это у нас Windows7), то окажется, что OpenGL будет эффективнее (похоже что ты не посмотрел слайды, ссылку на которые я тебе кинул в предыдущем сообщение, а это был очень серьёзный материал). Если говорить о самой последней версии DirectX, то она стал заметно лучше за счёт "приближения" к железу (по типу Mantle). Но это всё уже нее имеет никакого значения, потому что вышел Вулкан, который наверняка со временем выкинет всех остальных (и OpenGL и OpenGL ES и DirectX и Mantle). Хотя бы потому, что он при такой же производительности обзавёлся поддержкой всех производителей GPU (и мобильных и десктопных) и всех ведущих OS.
_>>Просто не надо тащить в OpenGL подходы из 2D графики — оно всё же ориентируется в первую очередь на 3D и шейдеры, а не на рисование квадратиков на экране. Т.е. последнее тоже без проблем, но надо понимать как это сделать оптимальнее, а не в стиле рисований из GDI. CS>"не надо тащить" а приходится, это вот: CS>
CS><div style="opacity:0.7">
CS> ... more stuff here ...
CS></div>
CS>
CS>иначе как сначала в буфер отрисовать, а потом уже это буфер с opacity вывести не поучается. В результате и Skia и Qt вынуждены имплементировать две параллельные pipeline : и CPU и GPU имплементацию всех примитивов. Что- радости не добавляет. Т.е. и Skia и Qt могут внезапно из O(1) стать O(N) если "дезигнеру" transparency вступит в голову.
Эм, я что-то не понял, по твоему у GPU есть какие-то проблемы с отображением прозрачности или что? )
Кстати у меня прямо сейчас перед руками проектик на Qt, в котором множество различных контролов (у которых нет собственного фона) рисуются поверх реалтаймого FHD видео. И не наблюдается ни малейших проблем даже на самых убогих процессорах и gpu (в не топовых момобильниках). А на десктопе вообще загрузка CPU в пару процентов. )))
CS>К слову NanoVG это чистая GPU <canvas>/2d graphics имплементация, можно сравнить со Skia и Qt по размеру.
Ты немного не сравнимые библиотеки называешь. Т.е. есть смысл сравнивать NanoVG (один бэкенд) с Cairo (десятки различных бэкендов), QPaintEngine (два основных бэкенда) из Qt, Skia (два основных бэкенда). И тогда уж брать NanoGUI в роли сравниваемого с GTK, Qt и т.п. Хотя в любом случае все эти Nano проекты совсем не тянут на сравнение с подобными монстрами индустрии. )))
Так вот, каких то сравнений по производительности Skia или NanoVG я не видел. А вот сравнений 2D бэкенда Qt с Cairo, GDI и графикой WPF я в прошлые годы видел не мало. И помнится по тем тестам OpenGL рендерер Qt обходил GDI и WPF в разы, а Cairo на порядок. )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, c-smile, Вы писали:
CS>>Да пофигу. Всё это вышеизложенное не зависит от кол-ва пикселей т.е. как ты и сказал — O(1). CS>>Важно то что если оно рисует на 2000*1600 то и на 4000*3200 оно будет рисовать с тем же FPS (CPU consumption).
_>Ну так а если у тебя один алгоритм будет рисовать и UHD и FHD кадр за 50 мс (твоё любимое O(1)), а другой будет рисовать UHD за 100 мс и FHD за 25 мс (то самое ужасное O(N)), то какой ты станешь использовать? )))
DrawQuad в DirectX на 2000*1600 и 4000*3200 дисплеях рисуется за одно и то же время (если карта держит оба resolution).
Меня (на стороне CPU) не парит какой алгоритм использует та неонка GPU для того. И то и то одно и то же время и кол-во команд занимает.
_>По сути Skia+ANGLE==Direct2D. А вот кто из них эффективнее зависит от их внутренних алгоритмов использования GPU — я таких замеров не видел.
К сожалению нет. Skia изменяет состояние OpenGL (и соотв. ANGLE). Поэтому с DirectX я вот такое https://sciter.com/sciter-and-directx/
провернуть могу а с OpenGL только путем создания отдельных потоков для каждой pipeline (sciter и 3D scene).
Очень уж OpenGL древний.
CS>>DirectX работает быстрее не только из-за того что драйвера лучше но також из-за лучшей архитектуры. Stateful OpenGL это просто ужас для multithreading и pipeline интеграции.
_>Это ты какую-то ерунду написал. Эти два API боролись между собой уже очень давно и в разные периоды (версии) то один был лучше, то другой. Если мы возьмём последние API доступные для самой популярной десктопной ОС в данный момент (сейчас это у нас Windows7), то окажется, что OpenGL будет эффективнее (похоже что ты не посмотрел слайды, ссылку на которые я тебе кинул в предыдущем сообщение, а это был очень серьёзный материал). Если говорить о самой последней версии DirectX, то она стал заметно лучше за счёт "приближения" к железу (по типу Mantle). Но это всё уже нее имеет никакого значения, потому что вышел Вулкан, который наверняка со временем выкинет всех остальных (и OpenGL и OpenGL ES и DirectX и Mantle). Хотя бы потому, что он при такой же производительности обзавёлся поддержкой всех производителей GPU (и мобильных и десктопных) и всех ведущих OS.
Ну так уж и "ерунду".
Драйвер OpenGL на Windows 7 — ужас и тем все сказано. На Windows 10 кстати OpenGL работает на в пример лучше.
Поэтому появился Vulcan который использует ту же архитектуру (по большому счету) что и DirectX.
Поэтому Vulcan и DirectX 12 показывают одни и те же результаты.
_>>>Просто не надо тащить в OpenGL подходы из 2D графики — оно всё же ориентируется в первую очередь на 3D и шейдеры, а не на рисование квадратиков на экране. Т.е. последнее тоже без проблем, но надо понимать как это сделать оптимальнее, а не в стиле рисований из GDI. CS>>"не надо тащить" а приходится, это вот: CS>>
CS>><div style="opacity:0.7">
CS>> ... more stuff here ...
CS>></div>
CS>>
CS>>иначе как сначала в буфер отрисовать, а потом уже это буфер с opacity вывести не поучается. В результате и Skia и Qt вынуждены имплементировать две параллельные pipeline : и CPU и GPU имплементацию всех примитивов. Что- радости не добавляет. Т.е. и Skia и Qt могут внезапно из O(1) стать O(N) если "дезигнеру" transparency вступит в голову.
_>Эм, я что-то не понял, по твоему у GPU есть какие-то проблемы с отображением прозрачности или что? )
А давай проверим твое знание Qt
Представим что тебе нужно имплементировать метод
QWidget::setOpacity(0.0 ... 1.0)
Твои действия (можно словами) ?
CS>>К слову NanoVG это чистая GPU <canvas>/2d graphics имплементация, можно сравнить со Skia и Qt по размеру.
_>Ты немного не сравнимые библиотеки называешь. Т.е. есть смысл сравнивать NanoVG (один бэкенд) с Cairo (десятки различных бэкендов), QPaintEngine (два основных бэкенда) из Qt, Skia (два основных бэкенда). И тогда уж брать NanoGUI в роли сравниваемого с GTK, Qt и т.п. Хотя в любом случае все эти Nano проекты совсем не тянут на сравнение с подобными монстрами индустрии. )))
В Cairo backends хорошо если 10% общего кода занимают поэтому замнем сказанное выше.
А вот кстати про Cairo, GTK и Gnome...
Все эти Compiz и Metacity со товарищи они H/W accelerated. Но содержимое окна это bitmap в памяти.
Т.е. Cairo (штатный graphics в Gnome 3) нифига не accelerated — рисует также как и GDI+ и CoreGraphics — в текстуру окна.
А про OpenGL в окне Gnome лучше вообще не говорить — тоска смертная. В Sciter на Linux/GTK Skia/OpenGK тоже можно запустить. Но лучше не надо.
А с анимациями — нет, не справится, т.к. шедулить его так как нужно в общем случае невозможно. Как и нет второстепенных ручек, навроде политики роста кучи и т.п. Если прикрутить скриптинг типа V8 — то возникает вопрос — нафига дотнет. 
Да самый примитивный рендерер на .NET (безусловно с неравными общими характеристиками) будет в разы лучше, чем это. Что в прочем Sciter и демонстрирует. 
сходи и прочитай наконец внимательно что в том посте написано.
