Здравствуйте, ononim, Вы писали:
CS>>Модель драйверов что была в Windows XP умерла 10 лет назад. Поэтому причем тут "сожаление"? Никому не интересно, померла так померла. CS>>В актуальных ОС GDI не accelerated (в том смысле что в это вкладывается сейчас в DirectX, OpenGL, etc). С этим ты согласен? O>С этим да. Но топик-то — исторический.
Угу, коллега наконец открыл референсы по ф-иям драйвера GDI и его мир перевернулся. ))
Здравствуйте, vdimas, Вы писали:
V>Только double-buffer теперь один на окно, и всё окно получается — один битмап.
Откуда дровишки? Я вот глянул ради любопытства Spy'ем — у Excel 2010 — куча окошек: рибон, строка состояния, полосы прокрутки, рабочая область ...
Нет там и в помине одного окна.
Здравствуйте, Ikemefula, Вы писали:
CS>>Извиняюсь. Не обратил внимания. Это какой-то странный тренд в пост-СССР использовать серверные ОС для desktop. CS>>И еще при этом ожидать какого-то быстродействия от UI. Они ж для строго наоборот сделаны...
I>Сравнение некорректное. "генерация html джаваскриптом" и "примитивный рендеринг". В твоём случае рендеринг на общем фоне даже не будет заметен. Я загрузил твой пример на древней и хилой видюхе в gdi режиме скроллинг внятный, только первый раз подлагивает, потом всё само крутится.
При чем здесь "генерация html джаваскриптом" ?
Мы сравниваем CPU загрузку при kinetic scrolling (обычно исполняется с 60 FPS) + зависимость оной от размера окна (т.е. кол-ва пикселей).
I>В любом случае рендеринг html с простым тестом не сравнится по перформансу, так что сильно вряд ли ты свои идеи продемонстрируешь скитером.
Здравствуйте, c-smile, Вы писали:
CS>При чем здесь "генерация html джаваскриптом" ? CS>Мы сравниваем CPU загрузку при kinetic scrolling (обычно исполняется с 60 FPS) + зависимость оной от размера окна (т.е. кол-ва пикселей).
Кул, значит я неправильно тебя понял.
Померял у себя. Не знаю, правда, что там за кинетик, в чем его мулька
Итого
Расход памяти везде одинаковый, только гди версия долго очень заводится, слишком долго таблицу генерирует.
Я вижу, что d3d прокручивает очень плавно, гладко, а вот gdi наоборот, подлагивает и текст во время прокрутки трудно прочесть.
Ощущение, что все дело в количестве FPS и d3d тупо выдаёт больше.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, c-smile, Вы писали:
CS>>При чем здесь "генерация html джаваскриптом" ? CS>>Мы сравниваем CPU загрузку при kinetic scrolling (обычно исполняется с 60 FPS) + зависимость оной от размера окна (т.е. кол-ва пикселей).
I>Кул, значит я неправильно тебя понял.
I>Померял у себя. Не знаю, что там за кинетик.
Известно как "плавная прокрутка" в простонародье.
I>Итого I>sciter32 gdi 12%
Desktop size, X*Y = ? pixels
GDI:
Window quarter screen, CPU = ?
Window half screen, CPU = ?
Window full screen, CPU = ?
Direct2D (Windows 7 or 8 or 10):
Window quarter screen, CPU = ?
Window half screen, CPU = ?
Window full screen, CPU = ?
CS>GDI: CS>Window quarter screen, CPU = ? CS>Window half screen, CPU = ? CS>Window full screen, CPU = ?
CS>Direct2D (Windows 7 or 8 or 10): CS>Window quarter screen, CPU = ? CS>Window half screen, CPU = ? CS>Window full screen, CPU = ?
Итого
GDI — в районе 12% все три размера.
D2D — 6 9 11%
Шота непонятное со скитером, непонятно как результаты интерпретировать. С одной стороны варп всегда хуже всех, с другой стороны d2d всегда лучше, но gdi выдаёт константу, а d2d странную зависимость, хотя и гарантировано лучше gdi.
Мне кажется дело в фпс. d2d возможно выдаёт больше фпс, но это не объясняет линейную зависимость.
А есть возможность вывести время отрисовки одного фрейма и фпс ?
Здравствуйте, Evgeniy Skvortsov, Вы писали:
ES>Откуда дровишки? Я вот глянул ради любопытства Spy'ем — у Excel 2010 — куча окошек: рибон, строка состояния, полосы прокрутки, рабочая область ...
Куча
ES>Нет там и в помине одного окна.
Раньше даже каждая надпись была отдельным окошком класса STATIC.
А любое приложение магазина Windows открой, и там будет одно окошко класса Windows.UI.Core.CoreWindow.
В режиме десктопа это окошко еще будет дополнительно завёрнуто в FrameWindow, но это уже детали реализации оконного режима для AppStore-приложений. ))
Здравствуйте, vdimas, Вы писали:
V>>>Потом оно переехало на WTL и досвидан — все AX-контролы рисовались ручками. CC>>Дык всё равно GDI снизу было.
V>Только double-buffer теперь один на окно, и всё окно получается — один битмап.
Ужос, и почему в последнем офисе всё не так ? Скажем, тулбар, сделан по всем правилам тулбаров из девяностых. Статусбар — так же. Сайдбар — так же. Вот риббон и основная рабочая область отличаются. Ы ?
Здравствуйте, Ikemefula, Вы писали:
V>>Только double-buffer теперь один на окно, и всё окно получается — один битмап. I>Ужос, и почему в последнем офисе всё не так ? Скажем, тулбар, сделан по всем правилам тулбаров из девяностых.
Ага, спасибо.
I>Шота непонятное со скитером, непонятно как результаты интерпретировать. С одной стороны варп всегда хуже всех, с другой стороны d2d всегда лучше, но gdi выдаёт константу, а d2d странную зависимость, хотя и гарантировано лучше gdi.
Там не Sciter а Windows начинает прикручивать частоту WM_PAINT — не успевает GDI часто рисовать. I>А есть возможность вывести время отрисовки одного фрейма и фпс ?
Вот под спойлером текст примера (выводит FPS в window caption)
Код примера FPS
<html>
<head>
<title></title>
<style>
table {
behavior:column-resizer;
border:1dip solid red;
width:*;
height:*;
background:white;
border-spacing: 0;
border-collapse:collapse;
}
table > tbody
{
overflow:scroll;
height:100*;
}
th { border:1dip solid #ccc; padding:2dip; width:*; background:#eee;}
td { border:1dip solid #ccc; padding:2dip; width:*; }
</style>
<script type="text/tiscript">
// fast
event click $(#append-10000-html)
{
var tb = $(table>tbody);
var out = Stream.openString();
var st = (new Date()).valueOf();
for(var i in 10000)
out.$(<tr><td>{i}</td><td>foo</td><td>bar</td><td>zap</td><td>car</td><td>cdr</td></tr>);
tb.html = out.toString();
var et = (new Date()).valueOf();
$(#out).$content(10000 rows added in {et - st} ms);
}
function self.ready() {
var pticks = System.ticks;
var series = [100];
var n = 0;
// using paintBackground to catch moment of drawing
self.paintBackground = function(gfx) {
var ticks = System.ticks;
series.unshift(ticks - pticks);
pticks = ticks;
if( series.length > 32 )
series.length = 32; // but not more than 32
}
// forcing view to be drawn with WM_PAINT frequency
self.animate( function()
{
self.refresh();
if( ++n % 16 == 0 ) {
var averageDelta = series.reduce(:a, b: a + b ) / series.length;
view.windowCaption = String.$(FPS:{ 1000.0 / averageDelta });
}
return true; // keep animating
});
}
</script>
</head>
<body>
<button #append-10000-html>Set 10,000 rows by HTML</button>
<table fixedlayout>
<thead>
<tr><th>1</th><th>2</th><th>3</th><th>4</th><th>5</th><th>6</th></tr>
</thead>
<tbody>
</tbody>
</table>
<pre #out> </pre>
</body>
</html>
Результаты:
N = 3840 x 2160
GDI:
P = N / 4 -> 30 FPS
P = N / 2 -> 13 FPS
P = N -> 6.5 FPS
D2D
P = N / 4 -> 60 FPS
P = N / 2 -> 59 FPS
P = N -> 52 FPS
Т.е. GDI чисто O(N), D2D — близко к O(1) (у меня два Dell P2715Q прицеплено на одну карту (192 ppi), может кол-во video memory влиять на больших размерах).
Здравствуйте, c-smile, Вы писали:
CS>С верующими людьми не спорю ...
Дык в данном случае верующий получаешься ты.
У меня же есть результаты экспериментов.
Я даже пошёл на страшные жертвы и включил себе Aero theme. С прозрачностями, peek и прочими спецэффектами.
Sciter сколько жрал CPU + GPU на basic theme столько же жрёт на Aero, что впрочем ожидаемо — внутренний рендеринг никак от композитора не зависит. Единственный бенефит может быть что composite desktop блиттит конечный результат на экран без какой либо стыковки.
CS>Но как-то MSDN до сих пор в особых грехах не был замечен...
Не, они то нарочно в заблуждение не вводят. Но не обновить документацию после какого либо обновления вполне могут.
И ошибки были там, и смысл написаного был обратный тому, что делал код, просто потому что в доке очепятались.
Там тоже люди работают.
CS>WM_PAINT в Windows UI приходит 60 раз в секунду макс. поэтому FPS ограничен числом 60. Чаще и не надо — только батарею садить.
Меня интересует сколько msec занимает рендер одного кадра.
CS>Он заставляет окно перерисовываться с максимальной частотой и выводит частоту перерисовки в window caption. CS>Ты должен увидеть 60 +/- лапоть.
Пасиба, скрещу этот скрипт с таблицей и посмотрю.
Меня тут отправляют в бЫзнестрип, так что дома руки дойдут на поиграццо уже в июле.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
I>>>Поделись, откуда такая оценка что долго работать будет? CC>>С потолка вестимо. Предположение что бОльший объём работы будет выполняться дольше. I>Вот и проверь на досуге.
Досуга у меня столько нету это проверять просто так.
CC>>В первую очередь за счёт увеличения объёма оперативки которая пошла под дисковый кэш. Потом уже SSD, который больше важен при первом запуске, чтобы подсосать все данные в кэш. I>OMG! Вижла под проект создаёт гигантскую базу данных, размер которой превосходит все твои запасы оперативы.
Ты конкретно про что? Если ей родной интеллисенс придушить и пользоваться ассистом, который к слову работает получше встроенного то никаких баз в округе не образуется. Я в VMW несколько лет так жил и горя не знал.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, c-smile, Вы писали:
_>>Я видимо плохо сформулировал свою мысль, так что ты её совсем не понял. Попробую уточнить. Я же вроде сразу сказал, что полностью согласен с тем, что на рисование примитивов через шейдеры будет O(1), а у прямого рисования в память или GDI будет O(N). Нюанс совсем в другом: т.к. это совсем разные технологии, то постоянные коэффициенты перед этими "O" совсем разные. Причём у работы через шейдеры этот коэффициент очень даже не маленький (если считать по честному, как я уже говорил). Так что в абсолютных величинах это самое O(1) может оказаться затратнее чем O(N), у которого коэффициент совсем маленький. CS>Еще раз. Я с тобой не спорю что shader могут быть сколь угодно сложными (как и любые другие программы). CS>Я про другое. Загрузка shader в GPU это в принципе однократная операция — O(1) какой бы shader сложный не был. CS>И вызов shader с передачей параметров это тоже O(1) операция — не зависит от размера экрана. CS>Если на каждый DrawPolygon генерировать уникальный shader то есс-но это никому не надо. CS>В реале делается другое: CS>1. Создается объект Mesh путем tessellation того полигона с нужной pen и пр. Один раз. CS>2. Этот Mesh как набор треугольников отсылается на GPU для рисования — each frame (если polygon не менялся). И вообще без shaders. CS>Операция 2 есть O(1) в том смысле что не зависит от количества пикселей нарисованных на экране в результате. CS>В GDI все растеризовать приходится на каждый вызов DrawPolygon (если не озаботится созданием bitmap caches). CS>Собственно разница подходов Direct2D и GDI состоит в том что D2D это векторная графика — объекты агрессивно кэшируются как на стороне СPU (meshes) так и на стороне GPU — Texture2D и пр.
Что-то дискуссия начинает утомлять, потому что ты похоже не слышишь то, что я тебе говорю и пытаешься доказать мне очевидные вещи (с которыми я и не спорил), не замечая, что проблема совсем в другом. Давай для начала разберёмся с одним очевидным вопросом. Ты понимаешь, что алгоритм с асимптотической вычислительной сложностью O(1) вполне себе может работать медленнее алгоритма со сложностью O(N) (причём речь не о тупом фокусе типа поставить N=1, а о вполне себе больших значениях N)? Если ты не осознаёшь данный очевидный факт, то нам как бы и беседовать дальше бесполезно... Если же ты это нормально понимаешь и просто считаешь что подобная ситуация не относится к раскладу в отношение между GDI и DirextX, то уже можем спокойно и предметно побеседовать на эту тему. Например посчитать сколько переходов в режим ядра и обратно будет происходить при прорисовке одной и той же картинки с помощью этих двух технологий и т.п... )
_>>Вообще dpi — это термин из полиграфии (а для чтения книжек у людей всегда было фиксированное расстояние), который имеет весьма мутный смысл в остальной техники без указания её специфики (а точнее предполагаемого расстояния между пользователем и экраном). Правильным термином в данной области должен был бы быть скорее "угловой размер пикселя", но такое точно было бы трудно продать. CS>Это да. Вот тебе картинка из CSS spec где 1px это логический unit — 1/96 in, типа: CS>Image: pixel1.png CS>Так вот это нифига толком не работает. Проблема не в том на каком расстоянии ты читаешь. А в том сколько пикселей накрывает твой палец когда ты жмешь на кнопку на экране. CS>В этом случае тот distance есть 0.
Хы, а если у меня только курсор мыши и никаких пальцев? )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, c-smile, Вы писали:
_>Ты понимаешь, что алгоритм с асимптотической вычислительной сложностью O(1) вполне себе может работать медленнее алгоритма со сложностью O(N) (причём речь не о тупом фокусе типа поставить N=1, а о вполне себе больших значениях N)?
Да, при некотором фиксированном n O(1) может быть хуже чем O(n).
Но когда говорят в терминах big O notation и computational complexity то имеется ввиду именно функциональные зависимости — тенденции.
Скорее всего именно это меня сбивает в твоих рассуждениях.
Я говорю про алгоритм/принцип вообще, а ты по всей видимости говоришь про какую-то конкретную имплементацию стоящую перед твоими глазами.
Понятно что 100 даже тупых GPU процессоров сделают некую работу быстрее чем один CPU.
Понятно что есть исключения из этого всего. Исключения настолько очевидные что не стоят упоминания в приличном обществе.
Ну там принципиально алгоритм не распараллеливается или сложен для тупой GPUёвины.
Просто с настоящим кризисом закона Мура всё что мы можем делать это экстенсивно увеличивать кол-во GPU процессоров на карточках. Это куда графика движется.
Т.е. GPU это way to go.
_>Если же ты это нормально понимаешь и просто считаешь что подобная ситуация не относится к раскладу в отношение между GDI и DirextX, то уже можем спокойно и предметно побеседовать на эту тему. Например посчитать сколько переходов в режим ядра и обратно будет происходить при прорисовке одной и той же картинки с помощью этих двух технологий и т.п... )
"...переходов в режим ядра..." да пофигу на самом деле.
Тот же Direct2D какую-то работу по растеризации делает на стороне CPU если именно это эффективнее сделать именно там.
Никто же не говорит что рисовать можно только DirectX кодом и больше никак ...
CS>>Так вот это нифига толком не работает. Проблема не в том на каком расстоянии ты читаешь. А в том сколько пикселей накрывает твой палец когда ты жмешь на кнопку на экране. CS>>В этом случае тот distance есть 0.
_>Хы, а если у меня только курсор мыши и никаких пальцев? )))
А телевизор смотреть? Или у тебя забор стоит вокруг него с табличками "смотреть онли туточки" ?
У меня на встроенном видео (HD4600) на 3х FHD мониторах (это 3/4 от твоего размера по пикселам) — FPS 62.5, на GDI — так же как у тебя. Но я не про то... Клик на "Set 10,000 rows..." в D2D режиме и GDI режиме занимает существенно разное время (в GDI дольше). Мне показалось это немного странным...
Здравствуйте, Mystic Artifact, Вы писали:
MA>Здравствуйте, c-smile, Вы писали:
MA>У меня на встроенном видео (HD4600) на 3х FHD мониторах (это 3/4 от твоего размера по пикселам) — FPS 62.5, на GDI — так же как у тебя. Но я не про то... Клик на "Set 10,000 rows..." в D2D режиме и GDI режиме занимает существенно разное время (в GDI дольше). Мне показалось это немного странным...
Да в общем-то разница ожидаема. Это так суммарно ScriptItemize, ScriptShape, ScriptBreak из usp10.dll работают. Там все через font в HDC и вся остальная хрень из GDI.
Это на самом деле stress test. Никто такое дурное количество DOM элементов не делает в добром здравии ибо O(N) у всех layout алгоритмов.
Для больших таблиц используется sdk/samples/+vlist/vgrid.htm что есть virtual list со sliding window:
То ясно, что стресс и никто так не делает... Хотя... Бывает наколбасишь наколенке длинный репорт — хай браузер страдает.
Просто, почему-то в голову закралась мысль, что рендеринг/обсчёт происходит во время вставки этих элементов (но из кода ясно что вроде не должно ж!), что и побудило спросить. Сейчас уже стёр, попробовать не могу. Но твоего объяснения достаточно.
PS: Кстати в хроме беда с какой-то версии стала: обсчёт документа стал длиться неприлично долго, если домен с которого он грузиться оказывается в рендерере впервые (т.е. новая вкладка + ввели адрес). Всё лень зафилить. Хотя опять надо перепроверить, вдруг, в новом починили.
