Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Вот тот самый спидуп I>>Image: image_22.png
НС>Это если разве что для VS 2008 актуально. У современных студий сей флажок включен искаропки.
Браво, кэп! Что, по твоему, значит фраза "Всего 5 лет назад..." ?
Здравствуйте, Ikemefula, Вы писали:
НС>>Это если разве что для VS 2008 актуально. У современных студий сей флажок включен искаропки. I>Браво, кэп! Что, по твоему, значит фраза "Всего 5 лет назад..." ?
Здравствуйте, c-smile, Вы писали:
_>>Это безусловно верно. Но я намекаю на другой нюанс. Что если считать затраты на рисование с помощью шейдеров по честному (т.е. учитывать не только конечную функцию, инициирующую рисование, но и все подготовительные этапы), то их честный O(1) во многих случаях может оказаться больше чем O(N) из тупого рисования в память. CS>Еще раз, мы говорим про задачу UI rendering. Т.е. 2D в основном. Скажем за минимальный джентльменский набор можно использовать <canvas> CS>Что в этом случае значит по-честному? И где там ты видишь O(N) complexity? CS>Все что я могу представить это tessellation сложных shapes. Но это ни разу не O(N pixels) задача в общем случае.
Я видимо плохо сформулировал свою мысль, так что ты её совсем не понял. Попробую уточнить. Я же вроде сразу сказал, что полностью согласен с тем, что на рисование примитивов через шейдеры будет O(1), а у прямого рисования в память или GDI будет O(N). Нюанс совсем в другом: т.к. это совсем разные технологии, то постоянные коэффициенты перед этими "O" совсем разные. Причём у работы через шейдеры этот коэффициент очень даже не маленький (если считать по честному, как я уже говорил). Так что в абсолютных величинах это самое O(1) может оказаться затратнее чем O(N), у которого коэффициент совсем маленький.
_>>Ну вообще то dpi имеет довольно слабое отношение к числу пикселей на экране. Скажем у больших 4K телевизоров очень маленький dpi, но при этом очень много пикселей. CS>Когда говорят про high-DPI проблемы то сравнивают два монитора одного размера, скажем 21-inch, один 96 ppi второй 300 ppi. У второго пикселей в 8-10 раз больше.
Причём этот второй не нужен в принципе. Точнее даже не просто не нужен, а скорее вреден, потому как от его использования будет создаваться впечатление, что нет особой разницы между FHD и UHD контентом (речь естественно про реальные фотки, фильмы и т.п., а не про случаи криворукого рисования GUI и т.п.).
_>>Далее, если уж говорить про dpi, то тут надо ещё понимать, что во многих случаях высокий dpi имеет только маркетинговый смысл, т.к. его использование выходит за реальные возможности человеческого глаза по распознаванию углового размера — чистый развод покупателей. CS>Это к делу не относится. Тем не менее пользователи, особенно на мобильных девайсах когда экран ближе, выбирают девайсы с большим dpi. Экран ближе к глазам и 96 dpi пиксели различимы невооруженным глазом.
Да, а вот у телефонов смысл в более высоком чем у мониторов dpi имеется. Так же как и у мониторов он должен быть выше чем у телевизоров, а у тех в свою очередь выше проекторов.
Вообще dpi — это термин из полиграфии (а для чтения книжек у людей всегда было фиксированное расстояние), который имеет весьма мутный смысл в остальной техники без указания её специфики (а точнее предполагаемого расстояния между пользователем и экраном). Правильным термином в данной области должен был бы быть скорее "угловой размер пикселя", но такое точно было бы трудно продать.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Это если разве что для VS 2008 актуально. У современных студий сей флажок включен искаропки. I>>Браво, кэп! Что, по твоему, значит фраза "Всего 5 лет назад..." ?
НС>Всего 5 лет назад на дворе была 2012 студия
Ты лучше перестань додумывать то, что не говорилось.
I>Поделись, откуда такая оценка что долго работать будет?
С потолка вестимо. Предположение что бОльший объём работы будет выполняться дольше.
I> В нормальной ИДЕ при наличии памяти и SSD долго работать как раз таки не будет. I>Find Usage работает шустро на SSD, и очень плохо — на обычном веники. I> Просекаешь, за счет чего прогресс произошел ?
В первую очередь за счёт увеличения объёма оперативки которая пошла под дисковый кэш. Потом уже SSD, который больше важен при первом запуске, чтобы подсосать все данные в кэш.
Здравствуйте, Ikemefula, Вы писали:
I>>>Если рефакторинг работает долго, как ты сказал CC>>Ох дюд. Хватит мучать сову. I>Если ты отзываешь свои слова, то я конечно это принимаю
Хватит мучать сову. Ты сейчас споришь сам с собой, с придуманными тобой заявлениями.
I>ИДЕ это продуктивити тул, принципиально он _ничего_ не меняет, исключительно продуктивность повышает. Для таких тулов, т.е. продуктивити вообще, перформанс это приоритет нумер 1. I>Ты сам то подумай — нахрена нужна ИДЕ если эти серьёзные функции тормозить будут безбожно ?
Ты что сказать то хотел?
I>>>Idea давно уже 64 бита. CC>>И помогло это ей? I>Разумеется.
И как же?
Здравствуйте, Ikemefula, Вы писали:
I>Идея понятна ? Видишь, чего автор статьи предлагает сделать ?
Сколько лет прошло, а ты ничуть не изменился. Всё так же не понимаешь про что речь.
Здравствуйте, Ikemefula, Вы писали:
I>То есть, в твоём случае рисование шрифтов не является BottleNeck
Ну ты ж нихрена не понял в написанном. Похоже вообще не читал.
I> ну нарисуешь не за 10мс, а за 100мс или даже за 500мс, что с того?
С того что лагает при обновлении данных. Которые случаются не 60 раз в секунду, но всё равно разница заметна.
I> А вот когда 60fps, вот тут то и видно, кто на самом деле шрифты быстро рисует.
Мало текста нарисовать много мощи не надо.
Много текста внезапно рисуется долго.
Здравствуйте, CreatorCray, Вы писали:
CC>Мне ж не надо каждый кадр рендерить одно и то же, мне надо быстро нарисовать кадр с большим колвом разного чёткого текста а уже получившийся битмап потом можно скроллить как угодно.
Что происходит у тебя:
1. Создается DDB или DIB bitmap размера больше scrollable area. Размером X для 96 ppi и размером 4*X для 200ppi (большинство современных UHD мониторов).
2. С пом. TextOut (скажем) ты рисуешь на том bitmap — растеризуешь свой стафф на X или 4*X количество пикселов. Это чисто O(N) операция.
3. Каждый вызов TextOut это a) парсинг текста ( вызов ScriptItemize ) и нахождение glyphs и их layout ( ScriptShape ).
4. Scrolling той bitmap (BitBlt с 60 FPS).
Если что-то в процессе scrolling поменялось то п.2 и 3 надо делать по новой.
Что происходит в sciter:
1. DOM parsing , compilation text to glyph vectors для каждого элемента. Один раз.
2. Glyphs transfer to GPU. Один раз.
3. Scrolling — GPU command to draw glyph vectors (that are on GPU already) with needed offsets. 60 FPS.
Т.е. bitmaps в памяти вообще не используются (в общем случае).
Если что-то обновляется в процессе scrolling то только эти части проходят п. 1 и 2.
Что ты сделал не так (скорее всего):
Ты попытался использовать DirectWrite так же как TextOut. Т.е. на каждую строку создавать IDWriteTextLayout по новой на каждый WM_PAINT.
И вот это концептуально не верно — куча дурной работы.
CC>Воткнул щас в скроллер perfcounter: BitBlt буфера, который в разы больше чем экран выполняется ~4.87 avg msec на 3440х1440, что более чем достаточно.
BitBlt не проблема. Проблема в наполнении bitmap и в том что эти времена в квадратичной зависимости от DPI.
CC>Все D2D/DW text rendering примеры что я видел очень конкретно заикались на сравнительно небольшом колве текста в сравнении с тем, что мне было надо. CC>Но хуже всего было то, что на небольших размерах шрифта и стандартном DPI они рисовали плохо читаемое мыло. CC>Вот тут интересный анализ как например WPF рендерит шрифты: CC>http://community.sharpdevelop.net/blogs/dsrbecky/archive/2011/09/04/WPF-text-rendering-performance.aspx
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, c-smile, Вы писали:
_>>>Это безусловно верно. Но я намекаю на другой нюанс. Что если считать затраты на рисование с помощью шейдеров по честному (т.е. учитывать не только конечную функцию, инициирующую рисование, но и все подготовительные этапы), то их честный O(1) во многих случаях может оказаться больше чем O(N) из тупого рисования в память. CS>>Еще раз, мы говорим про задачу UI rendering. Т.е. 2D в основном. Скажем за минимальный джентльменский набор можно использовать <canvas> CS>>Что в этом случае значит по-честному? И где там ты видишь O(N) complexity? CS>>Все что я могу представить это tessellation сложных shapes. Но это ни разу не O(N pixels) задача в общем случае.
_>Я видимо плохо сформулировал свою мысль, так что ты её совсем не понял. Попробую уточнить. Я же вроде сразу сказал, что полностью согласен с тем, что на рисование примитивов через шейдеры будет O(1), а у прямого рисования в память или GDI будет O(N). Нюанс совсем в другом: т.к. это совсем разные технологии, то постоянные коэффициенты перед этими "O" совсем разные. Причём у работы через шейдеры этот коэффициент очень даже не маленький (если считать по честному, как я уже говорил). Так что в абсолютных величинах это самое O(1) может оказаться затратнее чем O(N), у которого коэффициент совсем маленький.
Еще раз. Я с тобой не спорю что shader могут быть сколь угодно сложными (как и любые другие программы).
Я про другое. Загрузка shader в GPU это в принципе однократная операция — O(1) какой бы shader сложный не был.
И вызов shader с передачей параметров это тоже O(1) операция — не зависит от размера экрана.
Если на каждый DrawPolygon генерировать уникальный shader то есс-но это никому не надо.
В реале делается другое:
1. Создается объект Mesh путем tessellation того полигона с нужной pen и пр. Один раз.
2. Этот Mesh как набор треугольников отсылается на GPU для рисования — each frame (если polygon не менялся). И вообще без shaders.
Операция 2 есть O(1) в том смысле что не зависит от количества пикселей нарисованных на экране в результате.
В GDI все растеризовать приходится на каждый вызов DrawPolygon (если не озаботится созданием bitmap caches).
Собственно разница подходов Direct2D и GDI состоит в том что D2D это векторная графика — объекты агрессивно кэшируются как на стороне СPU (meshes) так и на стороне GPU — Texture2D и пр.
_>Вообще dpi — это термин из полиграфии (а для чтения книжек у людей всегда было фиксированное расстояние), который имеет весьма мутный смысл в остальной техники без указания её специфики (а точнее предполагаемого расстояния между пользователем и экраном). Правильным термином в данной области должен был бы быть скорее "угловой размер пикселя", но такое точно было бы трудно продать.
Это да. Вот тебе картинка из CSS spec где 1px это логический unit — 1/96 in, типа:
Так вот это нифига толком не работает. Проблема не в том на каком расстоянии ты читаешь. А в том сколько пикселей накрывает твой палец когда ты жмешь на кнопку на экране.
В этом случае тот distance есть 0.
Здравствуйте, c-smile, Вы писали:
CS>2. С пом. TextOut (скажем) ты рисуешь на том bitmap — растеризуешь свой стафф на X или 4*X количество пикселов. Это чисто O(N) операция. CS>3. Каждый вызов TextOut это a) парсинг текста ( вызов ScriptItemize ) и нахождение glyphs и их layout ( ScriptShape ).
CS>1. DOM parsing , compilation text to glyph vectors для каждого элемента. Один раз. CS>2. Glyphs transfer to GPU. Один раз.
Концептуально разница на самом деле небольшая. И там и там надо препроцессить примерно одно и то же. В одном случае мы генерим пучок пикселей, в другом — примитивы для рендеринга.
В моём use case при небольшом экранном размере шрифта отрисовать его на месте в битмапу видимо получается дешевле чем наплодить примитивов для рендера в видюхе.
Будет время я эксперимента ради экспортну графику в какой нить вектор и отдельно попробую нарисовать то же самое через D2D и через GDI, чисто сравнить.
CS>3. Scrolling — GPU command to draw glyph vectors (that are on GPU already) with needed offsets. 60 FPS.
В GDI этот этап — просто паннинг готовой картинки.
CS>Если что-то обновляется в процессе scrolling то только эти части проходят п. 1 и 2.
Дык то же самое получается: поменялись данные, надо все пересчитать.
CS>Ты попытался использовать DirectWrite так же как TextOut. Т.е. на каждую строку создавать IDWriteTextLayout по новой на каждый WM_PAINT.
Обижаешь, всё кэшировалось.
После того как layout посчитан все widgets препроцесснуты и надо только сказать им Render, который ничего нового не создаёт.
Что на GDI что на D2D, который выкошен уже.
Здравствуйте, CreatorCray, Вы писали:
CC>Концептуально разница на самом деле небольшая. И там и там надо препроцессить примерно одно и то же. В одном случае мы генерим пучок пикселей, в другом — примитивы для рендеринга.
Да нет же. В моем случае объем работы не зависит от количества пикселей на экране. В твоем — O(N).
CC>Будет время я эксперимента ради экспортну графику в какой нить вектор и отдельно попробую нарисовать то же самое через D2D и через GDI, чисто сравнить.
Скачай sciter sdk. Запусти либо bin/32/sciter.exe либо bin/64/sciter.exe — в зависимости от разрядности своего приложения.
Вот ниже тупой тест (в реалии используются virtual tables/lists), сохрани его в html файл и открой в sciter.
Нажми на кнопку "Set 10,000 rows by HTML" — он создаст 10,000 рядов с 6ю ячейками в каждом ряду = 70,000 DOM элементов с текстом.
Проскролируй мышой — там работает kinetic scroll с 60 FPS. Скажи CPU consumption. Теперь на той же машине сделай то же самое в своем приложении.
И скажи цифры что у тебя получатся. И OS.
<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);
}
</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>
Здравствуйте, c-smile, Вы писали:
CS>Да нет же. В моем случае объем работы не зависит от количества пикселей на экране. В твоем — O(N).
У тебя тоже O(N), просто N другое.
CC>>Будет время я эксперимента ради экспортну графику в какой нить вектор и отдельно попробую нарисовать то же самое через D2D и через GDI, чисто сравнить. CS>Скачай sciter sdk. Запусти либо bin/32/sciter.exe либо bin/64/sciter.exe — в зависимости от разрядности своего приложения.
Угу. Это чудо ниасилило простой текстовый файл показать — показывало пустой белый экран пока не наудалял строк чтоб стало менее ~500.
CS>Вот ниже тупой тест (в реалии используются virtual tables/lists), сохрани его в html файл и открой в sciter. CS>Нажми на кнопку "Set 10,000 rows by HTML" — он создаст 10,000 рядов с 6ю ячейками в каждом ряду = 70,000 DOM элементов с текстом. CS>Проскролируй мышой — там работает kinetic scroll с 60 FPS. Скажи CPU consumption.
Это не интересно. Мне интересно сколько msec потратится на одновременный рендеринг их всех.
CS>И скажи цифры что у тебя получатся. И OS.
Дома попробую.
Здравствуйте, CreatorCray, Вы писали:
CC>У тебя тоже O(N), просто N другое.
Спасибо, посмеялся. Не знаю поможет ли
CC>>>Будет время я эксперимента ради экспортну графику в какой нить вектор и отдельно попробую нарисовать то же самое через D2D и через GDI, чисто сравнить. CS>>Скачай sciter sdk. Запусти либо bin/32/sciter.exe либо bin/64/sciter.exe — в зависимости от разрядности своего приложения. CC>Угу. Это чудо ниасилило простой текстовый файл показать — показывало пустой белый экран пока не наудалял строк чтоб стало менее ~500.
Дык sciter он для html Если хочешь plaintext то есть специальный viewer / editor: sdk/samples/plaintext-editor/ или если хочешь еще syntax highlighting то sdk/samples/+colororizer/show-master-css.htm
CC>Это не интересно. Мне интересно сколько msec потратится на одновременный рендеринг их всех.
Зачем всех-то? И куда собственно рендеринг?
CS>>И скажи цифры что у тебя получатся. И OS. CC>Дома попробую.
Здравствуйте, c-smile, Вы писали:
CS>Проскролируй мышой — там работает kinetic scroll с 60 FPS. Скажи CPU consumption. Теперь на той же машине сделай то же самое в своем приложении. CS>И скажи цифры что у тебя получатся. И OS.
У меня для тебя плохие новости.
Я переделал твой тест чтобы получить картинку, близкую к тому, что надо рендерить мне. Развернул окошко на полный экран: 3440x1440.
\bin\64\sciter.exe сожрал 100 метров обычной памяти, 70 метров видеопамяти, при скроллинге жрёт целиком 1 CPU (i5-2500, 3.3Gz) и 25% GPU (GTX 970).
При этом скролл весьма заметно лагает. На глаз так FPS 15-20.
Увы, честный FPS оно нигде не показывает, так что хз сколько оно там тратит времени на рендеринг.
Sciter как то со щрифтами плохо умеет работать. Потому как срать оно хотело на CSS font-family и font-size. Вывернулся через <font> но в px оно размер не понимает, да и в целом какой то пц рисует если <font> поставить повыше.
Мой GDI рендерер тратит на рендеринг такой же сетки (45х67, что помещается во viewport sciter-a) ~42.5 msec avg.
OC: Win 2008 R2 x64, видеодрова обновлялись примерно месяц назад.
вот код (колво колонок подогнано чтоб влазить в мой размер монитора с примерной шириной как рендерится у меня):
<html>
<head>
<title></title>
<style>
table {
behavior:column-resizer;
border:1dip solid black;
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 y in 100)
{
out.$(<tr>);
for(var x in 45)
out.$(<td><font face="Arial">${x * y}.00</font></td>);
out.$(</tr>);
}
tb.html = out.toString();
var et = (new Date()).valueOf();
$(#out).$content(100 rows added in {et - st} ms);
}
</script>
</head>
<body>
<button #append-10000-html>Set 10,000 rows by HTML</button>
<table fixedlayout>
<thead>
</thead>
<tbody>
</tbody>
</table>
<pre #out> </pre>
</body>
</html>
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, c-smile, Вы писали:
CS>>Проскролируй мышой — там работает kinetic scroll с 60 FPS. Скажи CPU consumption. Теперь на той же машине сделай то же самое в своем приложении. CS>>И скажи цифры что у тебя получатся. И OS.
CC>У меня для тебя плохие новости. CC>Я переделал твой тест чтобы получить картинку, близкую к тому, что надо рендерить мне. Развернул окошко на полный экран: 3440x1440. CC>\bin\64\sciter.exe сожрал 100 метров обычной памяти, 70 метров видеопамяти, при скроллинге жрёт целиком 1 CPU (i5-2500, 3.3Gz) и 25% GPU (GTX 970). CC>При этом скролл весьма заметно лагает. На глаз так FPS 15-20.
OS?
CC>Sciter как то со щрифтами плохо умеет работать. Потому как срать оно хотело на CSS font-family и font-size. Вывернулся через <font> но в px оно размер не понимает, да и в целом какой то пц рисует если <font> поставить повыше.
Здравствуйте, c-smile, Вы писали:
CS>Ну не обманывай.
[...] CS>Ты можешь показать screenshot sciter окна по умолчанию — как он появляется после запуска. Интересует backend и OS.
OS у него была названа.
Ты серьёзно обвиняешь в обмане?
Здравствуйте, c-smile, Вы писали:
CS>Дык sciter он для html
<html><body><pre> ... </pre></body></html> чем не HTML?
CC>>Это не интересно. Мне интересно сколько msec потратится на одновременный рендеринг их всех. CS>Зачем всех-то?
Затем что дешевле паннить буфер чем это всё перерисовывать каждый раз. Что собственно в моём тесте и наблюдаем.
CS>И куда собственно рендеринг?
В back buffer, куда оно и так в любом случае рендерится.
Здравствуйте, c-smile, Вы писали:
CS>OS?
Дык написано жеж!
CC>OC: Win 2008 R2 x64
CC>>Sciter как то со щрифтами плохо умеет работать. Потому как срать оно хотело на CSS font-family и font-size. Вывернулся через <font> но в px оно размер не понимает, да и в целом какой то пц рисует если <font> поставить повыше. CS>Ну не обманывай.
Слющай да, я может и не умею его готовить но протрахался минут 20 пихая font-family везде где только можно с нулевым эффектом. Потом когда через <font face="Arial"> завелось пытался задать размеры и тоже как то фигня получалась.
Даже когда подгонкой получил что то похожее тот щрифт что он рисует ну никак на Arial не похож который я вижу даже в том же charmap.
CS>Это что? Windows XP?
W7 server.
CS>Ты можешь показать screenshot sciter окна по умолчанию — как он появляется после запуска. Интересует backend и OS.
Это что ли?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, c-smile, Вы писали:
CS>>Ну не обманывай. N>[...] CS>>Ты можешь показать screenshot sciter окна по умолчанию — как он появляется после запуска. Интересует backend и OS.
N>OS у него была названа.
Я не знаю desktop OS по имени Windows 2008.
На всём что ниже Windows 7 Sciter по умолчанию использует GDI+ т.е. чистый CPU rendering по определению.
N>Ты серьёзно обвиняешь в обмане?
Да, потому что он зачем-то проводит тесты на server OS которая не использует display hardware acceleration.
В чем смысл таких тестов в свете обсуждаемых проблем? Подогнать результаты?
Если хочешь plaintext то есть специальный viewer / editor: sdk/samples/plaintext-editor/ или если хочешь еще syntax highlighting то sdk/samples/+colororizer/show-master-css.htm 
