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

I>>от кастомера пришел проект, десяток другой репов в которых есть всё. Каким чудом ты это в свою Вижлу засунешь ?
CC>Лехко! Я в вижлу запихивал ESX ядро, которое вообще scons собирает.

Это когда было ? Еще недавно вижла с трудом справлялась с жалким десятком тысяч файлов. Приходилось дробить на под-проекты, саб-репы и тд и тд.

Для фронтенда до недавних пор вообще никакой внятной IDE не было, по большому счету. Больше двадцати лет фронтенд был просто файликами которые кидали куда попало, как попало. При чем этим занимались и джависты, и дотнетчики, и питонщики, и пехапешники и вообще все кому не лень.
Вроде бы ИДЕ была и даже помогала, но вот убитые проекты убивались сидя в классной ИДЕ. Обычно у фулстеков-бакендов руки до фроненда не доходят, как правило. И если на проекте нет выделеного фроденд-девелопера, то начинается каша и содомия.

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

CS>В результате в HTMLayout я использовал AGG от Макса Шеманарева (земля ему пухом).

Потому что тебе было нужно сглаживание и полупрозрачность.


CS>Да и работал AGG быстрее чем тот "hardware accelerated GDI" (с) vdimas.

Опять неправда, т.е. всё вывернуто наизнанку. ))

GDI ускорял вполне конкретный набор команд — рисование линий, прямоугольников, залитых полигонов, эллипсов.
AGG имеет намного более широкое АПИ.
А уж для сглаженного рисования, действительно, необходим прямой доступ к низлежащим пикселям.
Поэтому, если заниматься сглаживанием на стороне CPU, как это делает AGG, то и пиксели должны располагаться в обычной памяти.


CS>Проблема в том что и AGG и GDI растеризация (что не есть BitBlt, sic!) это всегда O(N) complexity (N — количество пикселей на экране).
CS>Т.е. имеет крайне ограниченное применение в современных desktop.

Тоже неправда. Линии/прямоугольники/полигоны и т.д. рисуются в GDI одной командой, то бишь, O(1).

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

CS>В этом утверждении правда только в том что только функции семейства BitBlt ( т.е. трансфер bitmaps туда обратно ) еще как-то accelerated.
CS>Все остальное, типа LineTo, PolyBezierTo и пр. — нет.

Наоборот, начиная с Win98 — да. Достоверно accelerated.
Особенно это заметно было при заливке некоей области битмап-кистью или узорной кистью.


CS>Если же говорить про твой пример с WS_EX_LAYERED то рисование (GDI) там это всегда in-memory bitmap

Глупости опять.
Там рисование в off-screen bitmap, но где этот битмап располагается — зависит от карточки и драйвера.
Пример я показывал. Создаёшь CompatibleDC/CompatibleBitmap, рисуешь, потом вызываешь UpdateLayeredWindow вместо BitBlt. Обе операции хардварно ускорены.


CS>С Direct2D можно это устроить несколько более эффективно используя DirectX texture на ID3DXXDevice и CreateDxgiSurfaceRenderTarget сверху, т.е. на стороне GPU.

Точно так же, как это можно было это делать в DirectDraw через точно такие ф-ии GDI и быть 100%-но уверенным, что оперируешь с битмапом в видеопамяти.

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

CS>1. делать это на стороне CPU в bitmap, потом отправить ту bitmap (BitBlt) в видео память.
CS>2. разложить ту линию на два треугольника и попросить GPU нарисовать их в видеопамяти — у GPU процессоров много. Тупых, но много. Нарисует.

GPU умеет рисовать не только треугольники.
GPU выполняет произвольный код и рисует что угодно, хоть блюдечки с голубой каёмочкой одной командой. ))
Все зависит от драйвера, который инициализирует карточку некоей программой.


CS>Второе это то что делает Direct2D/DirectX и OpenGL когда им хорошо — есть соотв. hardware. И это называется hardware acceleration.

Понятно, что термин прижился, но по-факту никакого hardware acceleration нет. ))

Есть исполнение программы на процессорах видеокарточки, причем, эту программу можно подсовывать фактически любую (лишь бы корректную для данной карточки).

Просто OpenGL или DirectX-дрова кодируют вызовы своего АПИ в некую последовательность данных (описывающих команды) и отправляют их в буфер команд картейки как обычные данные. А уже ПО на картейке интерпретирует эти данные, т.е. на стороне карточки, считай, работает голимый интерпретатор. Это была одна из причин, почему появился Direct11 — чтобы улучшить всю эту тупую схему, потому что не справляется с большим потоком команд.


CS>Эти вот рекомендации они не от хорошей жизни: Scaling canvas using CSS transforms: CSS transforms are faster by using the GPU.

Ничего страшного. Развитие возможностей видеокарточек и дров к ним диктуется со стороны хоста. Если какую-то действительно востребованную функциональность надо будет ускорить, то выйдет и новое АПИ и новые соотв. дрова на картейки.

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

CS>>Если же говорить про твой пример с WS_EX_LAYERED то рисование (GDI) там это всегда in-memory bitmap

V>Глупости опять.
V>Там рисование в off-screen bitmap, но где этот битмап располагается — зависит от карточки и драйвера.
V>Пример я показывал. Создаёшь CompatibleDC/CompatibleBitmap, рисуешь, потом вызываешь UpdateLayeredWindow вместо BitBlt. Обе операции хардварно ускорены.

Слушай, ну хватит уже ...

Какой нахрен CompatibleBitmap и UpdateLayeredWindow ?

Тебе нужен DIB с альфаканалом в случае layered window. Другого способа рисования per-pixel alpha в layered windows не предусмотрено.

CompatibleBitmap создает DDB в котором альфканала нет по определению ибо это bitmap с разрядностью текущих установок видео-драйвера.

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

V>>Глупости опять.
V>>Там рисование в off-screen bitmap, но где этот битмап располагается — зависит от карточки и драйвера.
V>>Пример я показывал. Создаёшь CompatibleDC/CompatibleBitmap, рисуешь, потом вызываешь UpdateLayeredWindow вместо BitBlt. Обе операции хардварно ускорены.
CS>Какой нахрен CompatibleBitmap и UpdateLayeredWindow ?

А кто мешает тебе проверить в 5 строчек?


CS>Тебе нужен DIB с альфаканалом в случае layered window.

Не нужен.
https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms633556(v=vs.85).aspx

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


CS>Другого способа рисования per-pixel alpha в layered windows не предусмотрено.

А откуда взялось требование про per-pixel alpha?
Технология layered window появилась не для этого, а для полупрозрачности окон или прозрачности части окна.


CS>CompatibleBitmap создает DDB в котором альфканала нет по определению ибо это bitmap с разрядностью текущих установок видео-драйвера.

Верно.
Ты попробуй, все-таки. Потом продолжим.

Там же по ссылке:

The source DC should contain the surface that defines the visible contents of the layered window. For example, you can select a bitmap into a device context obtained by calling the CreateCompatibleDC function.

Напомню, что SelectObject для битмапов работает только для тех DC, которые были созданы через CreateCompatibleDC. Поэтому, у тебя и выхода другого нет, как воспользоваться тем сниппетом, который я давал чуть выше по обсуждению. ))

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

V>Здравствуйте, c-smile, Вы писали:

V>>>Глупости опять.
V>>>Там рисование в off-screen bitmap, но где этот битмап располагается — зависит от карточки и драйвера.
V>>>Пример я показывал. Создаёшь CompatibleDC/CompatibleBitmap, рисуешь, потом вызываешь UpdateLayeredWindow вместо BitBlt. Обе операции хардварно ускорены.
CS>>Какой нахрен CompatibleBitmap и UpdateLayeredWindow ?

CS>>Тебе нужен DIB с альфаканалом в случае layered window.

V>Не нужен.

Ты всё еще про UpdateLayeredWindow т.е. про окна с per-pixel alpha? Или плавно перешел на SetLayeredWindowAttributes окна?

Please remember that once SetLayeredWindowAttributes has been called on a layered window, subsequent UpdateLayeredWindow calls will fail until the layering style bit is cleared and set again

Вот тебе окно:


Как ты его собираешься рисовать?

CS>>Другого способа рисования per-pixel alpha в layered windows не предусмотрено.
V>А откуда взялось требование про per-pixel alpha?
V>Технология layered window появилась не для этого, а для полупрозрачности окон или прозрачности части окна.

Ну расскажи это Microsoft и как им надо было реализовывать это вот:


Всё на этом. То что ты когда-то имел дело с рисованием в Windows я понял. Но последние 10 лет — нет.
Поэтому ивиняюсь, но разговаривать дальше с тобой мне не на эту тему не интересно вообще.

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

I>Это когда было?
Последний раз в прошлом году.

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

CS>>>Тебе нужен DIB с альфаканалом в случае layered window.
V>>Не нужен.
CS>Ты всё еще про UpdateLayeredWindow т.е. про окна с per-pixel alpha?

Нет, я про т.н. "ключевой цвет". Выбираешь некий ключевой цвет, например фиолетовый, и те области картинки, которые должны быть прозрачными, заполняешь этим цветом. Но тут нет никакого per-pixel alpha, разумеется.


CS>Или плавно перешел на SetLayeredWindowAttributes окна?

Кто куда перешел?
Обе этих ф-ии предназначены для работы с layered window.


CS>Вот тебе окно:
CS>Image: sciter-tooltip.png
CS>Как ты его собираешься рисовать?

Я знаю как минимум 4 разных способа, а ты? )
Например, через DrawThemeParentBackground.


V>>Технология layered window появилась не для этого, а для полупрозрачности окон или прозрачности части окна.
CS>Ну расскажи это Microsoft и как им надо было реализовывать это вот:
CS>Image: IC79040.gif

И это я могу сделать минимум 4-мя разными способами.
* В том числе через UpdateLayeredWindow + ключевой цвет (выделил в своём процитированном).

* Можно еще указать регион окну.

* А ещё можно рисовать прямо в DC десктопа поверх всех окон. Например, когда делал drag&drop и при этом тащил вслед за курсором некую картинку — то так и делал.


CS>Всё на этом. То что ты когда-то имел дело с рисованием в Windows я понял. Но последние 10 лет — нет.
CS>Поэтому ивиняюсь, но разговаривать дальше с тобой мне не на эту тему не интересно вообще.

Оригинально, однако...
Задать (наконец-то!) вопросы по-существу и тут же объявить, что ответы не интересуют. ))

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

I>Можно.

Жду.

I>У тебя какие то обиды детские ко мне

Перешел на личности — слил.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Можно.

НС>Жду.

А что тебе еще остаётся ? Все уже оговорено.

I>>У тебя какие то обиды детские ко мне

НС>Перешел на личности — слил.

Констатирую факты.

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

CS>Вот тебе окно:
CS>Image: sciter-tooltip.png

CS>Как ты его собираешься рисовать?

А что здесь за сложность ? В конце девяностых-начале нулевых был ажно бум вот таких вот апликачек. Рисовали обычно через задание региона окну, прямо в дц десктопа и транспарент-окна. Это работало даже в Win2000 и может даже NT4.
Что принципиально изменилось за последние 10 лет ?

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

I>>>Можно.
НС>>Жду.
I>А что тебе еще остаётся ? Все уже оговорено.

Т.е. все таки не будет. ЧТД.

I>>>У тебя какие то обиды детские ко мне
НС>>Перешел на личности — слил.
I>Констатирую факты.

Слива.

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

I>>Это когда было?
CC>Последний раз в прошлом году.

Сколько там файлов и строчек кода ? Вот скажем, обо что мне встанет переименовать какой нибудь класс который используется чуть не везде ?

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

I>Сколько там файлов и строчек кода?
Ахз, я не помню уже. Дохрена. Возьми ядро BSD — будет примерно тот же порядок.

I> Вот скажем, обо что мне встанет переименовать какой нибудь класс который используется чуть не везде?
Такого я не делал. Думаю что долго.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>>>Можно.
НС>>>Жду.
I>>А что тебе еще остаётся ? Все уже оговорено.

НС>Т.е. все таки не будет. ЧТД.

Будет или нет зависит от профита. Или ты думал "а докажи" это классная такая игра на все времена и возрасты ?

I>>>>У тебя какие то обиды детские ко мне
НС>>>Перешел на личности — слил.
I>>Констатирую факты.

НС>Слива.

Скукота. Никакого разнообразия.

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

I>>Сколько там файлов и строчек кода?
CC>Ахз, я не помню уже. Дохрена. Возьми ядро BSD — будет примерно тот же порядок.

I>> Вот скажем, обо что мне встанет переименовать какой нибудь класс который используется чуть не везде?
CC>Такого я не делал. Думаю что долго.

То есть, большей частью функций IDE пользоваться всё равно не выйдет. Правильно ? А если комп послабее, памяти поменьше то и вовсе тухло будет.
Собтсвенно прорыв в ИДЕ случился благодаря SSD и x64. То есть, совсем недавно. Просекаешь ?

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

I>Здравствуйте, c-smile, Вы писали:

CS>>Вот тебе окно:
CS>>Image: sciter-tooltip.png

CS>>Как ты его собираешься рисовать?

I>А что здесь за сложность ? В конце девяностых-начале нулевых был ажно бум вот таких вот апликачек. Рисовали обычно через задание региона окну, прямо в дц десктопа и транспарент-окна. Это работало даже в Win2000 и может даже NT4.

Какой еще регион? Там альфа-канал, или ты не заметил. Тени и АА borders.

I>Что принципиально изменилось за последние 10 лет ?

Side bar слева:



Или Windows Fluent:



Забей на GDI, не знал он про альфа и GPU и знать не будет. Паровоз ушел. Direct2D , DirectComposition это наше всё на ближайшее будущее.

I>>А что здесь за сложность ? В конце девяностых-начале нулевых был ажно бум вот таких вот апликачек. Рисовали обычно через задание региона окну, прямо в дц десктопа и транспарент-окна. Это работало даже в Win2000 и может даже NT4.
CS>Какой еще регион? Там альфа-канал, или ты не заметил. Тени и АА borders.
Я делал еще на XP фичу — полупрозрачная рамка с градиентом прозрачности вокруг заданных окон _других_ приложений (отвечая на вопрос нафиг надо: завернутых в наш app virtualization sandbox). SetWinEventHook + UpdateLayeredWindow с битмапкой с альфа каналом. Было написано за пол дня, работало like a charm — создавались четыре окошка, которые облепляли заданное и на которые натягивались автогенеренные битмапы с альфа каналом.
По поводу аппаратного ускорения этого дела. Тут вопрос неоднозначный. Факт в том что DrvAlphaBlen вызываался в ХР для любых source битмапов, а не только для DDB. Требование быть ассоциированным с DDB относится только к destination DC. И ускорять при желании он тоже мог операции даже если второй битмап имел формат не идентичный экранному. И это делалось в реальности, доказательства этому -соседний пример из DDK2003, а точнее функция vAlphaBlendDownload в нем которая тем и занимается что берет битмап с альфа-каналом и скармливает его в железо с запросом сделать альфабленд с экранным регионом (альфабленд с не экранными destination-битмапами не ускорялся, а скармливался в софтварный EngAlphaBlend).

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

I>>>А что здесь за сложность ? В конце девяностых-начале нулевых был ажно бум вот таких вот апликачек. Рисовали обычно через задание региона окну, прямо в дц десктопа и транспарент-окна. Это работало даже в Win2000 и может даже NT4.
CS>>Какой еще регион? Там альфа-канал, или ты не заметил. Тени и АА borders.

O>Я делал еще на XP фичу — полупрозрачная рамка с градиентом прозрачности вокруг заданных окон...

Мы же говорили про regions, SetWindowRgn() в частности. С его помощью полупрозрачность не получить.

А про "четыре окошка". Да, это как это всегда делалось. И делается. Вот например Visual Studio до сих пор glow рисует четырьмя VisualStudioGlowWindow с WS_EX_LAYERED:




O>По поводу аппаратного ускорения этого дела. Тут вопрос неоднозначный. Факт в том что DrvAlphaBlen вызываался в ХР для любых битмапов, а не только для DDB. И ускорять при желании он тоже мог операции даже если второй битмап имел формат не идентичный экранному.

Еще раз. В DDB нет понятия альфаканала как сущности. По определению. Если у тебя экран 16-bit цвета то где там в том compatible bitmap будет альфа? Для AlphaBlend в DC должен быть выбран DIB ( device independent bitmap с 32 bit на пиксел и с premultiplied alpha в старшем байте). DIB это bitmap в обычной памяти, см. ppvBits в CreateDIBSection.

Т.е. для того чтобы пользовать AlphaBlend ты тот DIB должен заполнить как-то, т.е. исполнить rasterization всех примитивов в памяти т.е. с помощью CPU (GDI, GDI+, AGG, etc.). Никакой per primitive hardware acceleration как ты понимаешь в этом случае не будет — физически невозможно в современных архитектурах. Т.е. для high-dpi monitors GDI это смэрть ибо там рисование O(N).

Единственное место для H/W acceleration это заброс той битмап из памяти в video memory. Т.е. фактически древний как дерьмо мамонта механизм DMA или подобного.

И это не есть hardware acceleration в смысле того что под этим понимают в DirectX, OpenGL. Вот всякие shaders и прочая — это оно.