Здравствуйте, vdimas, Вы писали:
V>>>Наверно потому что то, чего сейчас служит D2D, раньше называлось DirectDraw? CC>>Да всё равно как называлось. Гуй на нём в те времена никому в голову не приходило делать. V>Т.е. делали без прихождения в голову! V>Мощно задвинул! )))
Без GUI нет стандартных контролов.
Указанный тобой getDC() у surface это только начиная с Windows 7, то есть зверски поздно. До этого делать гуй поверх DirectDraw означало делать закат солнца вручную, рисуя все контролы самому. Или у тебя есть магический ход для более ранних версий?
The God is real, unless declared integer.
Re[23]: Что на самом деле произошло с Windows Vista
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Sharov, Вы писали:
K>>>> Вопрос упирается только в наличие эффективного jit/ngen CC>>>Jit сразу идёт в лес просто потому что у него банально нет времени и ресурсов генерировать эффективный код.
S>>Это, интересно, с чего вдруг? CC>Потому что он "in time". CC>Он просто не может себе позволить уйти спать на минуту и сожрать гиг памяти чтоб произвести качественный код, как offline compiler c WPO.
Почему сразу гиг? А только hotpath оптимизировать нельзя? А делать это итеративно (тут, наверное, уже все сложнее)?
Кнопки, переключатели, крутилки, индикаторы, скролл-бары — всё своё.
Да и нет никаких "стандартных контролов" под OpenGL или DirectX — везде идут некие либы или сам пишешь.
Ну разве что АПИ WinRT изкаробки даёт контролы для DirectX, но там тоже всё очень завуалировано, знаешь ли, не так просто нарисовать свой контрол (неоправданно большая трудоёмкость). Иногда дешевле иметь свою простую инфраструктуру с 0-ля и рисовать свои контролы в десяток строк или меньше.
N>Указанный тобой getDC() у surface это только начиная с Windows 7, то есть зверски поздно.
Речь была о DirectDraw, а он вышел лет 20 назад.
Как раз беда в том, что D2D появился слишком поздно. До этого DirectDraw уже много лет был объявлен как deprecated, хотя прекрасно работал все годы. Но часть его ф-ий перенесли в D3D, поэтому, в 2000-х годах было много обсуждений из разряда "подскажите, как лучше выводить видео на экран в своих программах — через DirectShow, DirectDraw или DirectX Graphics (D3D)". Я пробовал выводить через все перечисленные способы, загрузка проца была одинаковой. Т.е., "под капотом" там происходило примерно одно и то же.
N>До этого делать гуй поверх DirectDraw означало делать закат солнца вручную, рисуя все контролы самому.
Во-первых, не так уж и самому. Можно прямо через системные АПИ рисовать части контролов (DrawFrameControl), подавая как параметр HDC.
В WinXP это АПИ было обновлено, я этой фигней тоже маялся — рисовал контролы через высокоуровневые вызовы uxtheme.dll
(DrawThemeBackground, DrawThemeEdge и т.д.)
N>Или у тебя есть магический ход для более ранних версий?
Можно более конкретный вопрос?
Так-то у меня тут лежит архив уже примерно 15 лет, где грид рисуется ручками как раз через uxtheme: http://files.rsdn.org/21096/dataGrid.zip
Рисует примерно так:
Рамка грида, заголовки столбцов, чекбоксы — это всё рисуется через uxtheme.
Там же лежит свой таб-контрол (бо который идёт от MFC — это какой-то садизм, а не таб-контрол).
Тоже со своей прорисовкой:
Аналогично, рисуется в текущей теме.
Т.е., в случае DirectDraw получаешь HDC у DirectDraw-поверхности, затем делаешь такие же точно вызовы для рисования, и у тебя DirectX-приложение будет рисоваться в текущей установленной теме. В Висте и Win7 это АПИ было еще совсем чуть-чуть расширено, но и от времён WinXP проги прекрасно себя рисуют в текущей теме Win7, Win8, Win10, если для рисования используют указанные ф-ии.
Здравствуйте, Ops, Вы писали:
Ops>Мелочевка, в моем примере такая же была. На ползунок или крутилку много не надо
На задний фон плагина зато много надо, там обычно нехилая такая картинка.
И да, ты бы эта, покрутил бы крутилку. ))
У ней тень, у ней ребра. У крутилки часто идёт весь пакет анимации на все её положения (ну или от ребра к ребру как минимум) — это обычно одна текстура с покадровкой.
Ops>а когда их несколько одинаковых, саму текстуру не требуется дублировать, просто отрисовать иначе.
ОМГ ))
Ну конечно, одну текстуру пользуют в нескольких местах.
Ops>Так какие-то ненужные текстуры от силы в четверти случаев
Нужные, нужные. Поверь. ))
Чтобы тебе заплатили за твой VST-плагин, он должен быть профессиональным во всём — как в звучании, в удобстве пользования, так и в "профессиональном" своём внешнем виде.
Обычно убогими идут только бесплатные плагины от вчерашних студентов.
Здравствуйте, CreatorCray, Вы писали:
C>>>Нет, ну тут надо выбирать одно из двух: или старый код работает на новых CPU, или переписываем всё каждую итерацию микроархитектуры. K>>Байт-код позволяет переложить это на плечи разработчика рантайма. CC>Для этого рантайм должен распухнуть до монструозных размеров всемогутера.
В современном Андроиде живет такойй примерно рантайм.
Сейчас он при инсталляции переводит байт-код в нейтивный с учётом конкретной железки.
Но он же один на устройство, такой рантайм, т.е. это не принципиально.
К тому же, бинарь оптимизирующего компилятора весит единицы метров, это копейки по современным меркам.
Любая вшивая свистелка весит не меньше. ))
Re[21]: Что на самом деле произошло с Windows Vista
Здравствуйте, Cyberax, Вы писали:
C>>>Нет, ну тут надо выбирать одно из двух: или старый код работает на новых CPU, или переписываем всё каждую итерацию микроархитектуры. K>>Байт-код позволяет переложить это на плечи разработчика рантайма. C>Не позволяет, так как на практике все варианты переносимого JIT-транслируемого байт-кода не достигают скорости нативного.
Речь не о JIT, речь об AOT.
Re[20]: Что на самом деле произошло с Windows Vista
Здравствуйте, netch80, Вы писали:
N>У Intel было две потрясающие возможности убрать весь старый хлам — переходы 16->32 и особенно 32->64. Обе возможности она бездарно протеряла. (Ну, во втором AMD помогла, но тут они близнецы.)
Вот именно что. Если бы AMD не навредила, то была бы сейчас архитектура IA64 в мейнстриме.
Re[18]: Что на самом деле произошло с Windows Vista
Здравствуйте, alex_public, Вы писали:
_>Он имеет в виду, что скомпилированный по этой технологии сегодня бинарник не сможет использовать возможности гипотетического AVX3. И в этом смысле он прав — это очевидный недостаток данного подхода, отсутствующий при применение байт-кода. Хотя недостаток не очень серьёзный, т.к. нет никаких проблем в перекомпиляции ПО при выходе нового поколения процессоров. Проблема может быть разве что у пользователей некого заброшенного проекта. )))
Во-во. Т.е. каждый проект надо "сторожить" на предмет выпуска нового железа.
MS сейчас "сторожит" такие проекты автоматически в своём магазине, бо компилит дотнетные магазинные приложения в нейтив сама в облаке.
Re[21]: Что на самом деле произошло с Windows Vista
Здравствуйте, CreatorCray, Вы писали:
CC>Wut?
Подумай своей головой, а не транслируй догмы, и ты поймёшь всё сам.
CC>Допустим возьмём С. Куда уже проще?
Ну дык он и переносим с минимальными проблемами. По крайней мере в своей "статической" части, которая не опирается на сервисы ОС.
Если что, я это по своему опыту знаю — у меня один codebase работал на МКшках Cortex-M0+, M3, M4 и M7. Под ним только был небольшой файлик HALа, где прописываются специфичные для конкретной железки моменты (базовые адреса периферии, тактовая частота, работа с DMA и т.п.).
CC>HAL это Hardware Abstraction Layer CC>Родилась она как идея обеспечить одинаковый базовый API для работы ядра под разным железом.
Thank you, Captain Obvious!
CC>Можно, но при этом довольно сильно потеряв в эффективности этого кода. CC>Тыж понимаешь, и на brainfuck можно писать программы. Вот только сначала придётся сложные конструкции разбить на туеву хучу простых а потом эти простые собрать обратно в сложные.
Херня на постном масле. Поинтересуйся на досуге, сколько команд реализовано в современных RISC-процах, ну или микрокоманд в x86-совместимых (которые внутри тоже RISC уже очень давно — целую вечность по меркам индустрии), и тогда ты поймёшь, какую же ерунду только что сказал. В реальности CISC-процы чудовищно неэффективны, т.к. в любой момент времени бОльшая часть его блоков простаивает. И даже суперскалярность с гипертредингом не спасает.
Поэтому все эти SSE100500 — рак. Будущее — за комбинированными системами с программируемыми блоками, которые "на ходу" можно перенастроить под текущие нужды. Сейчас такие есть только в мире ARM, но после покупки Интелом Альтеры активно циркулируют слухи о том, что и x86/FPGA гибрид не за горами.
CC>ngen в это же ничем не лучше компилятора, вот только пространство для манёвра у него хуже, потому что он видит простые команды, тогда как должно быть что то типа AST. Но если заморачиваться с AST то почему бы не взять тогда сразу сурсы и использовать готовые компиляторы?
А ты подумай и сам ответь на свой вопрос. КО быть как-то не хочется.
Здравствуйте, alex_public, Вы писали:
_>Развитие архитектуры вроде как совсем не буксует. Более того, в последние годы это по сути единственный работающий способ, способный увеличивать производительность процессоров на универсальных задачах (а не только на узком классе задач, поддающихся лёгкому распараллеливанию).
Оно не просто буксует — оно встало колом и никуда не движется. Или ты из тех, кто считает 7-gen i7 новой архитектурой по сравнению с 6-gen i7?
Здравствуйте, netch80, Вы писали:
N>Например, тем, что это работает, а байткод с докомпиляцией — далеко не всегда. Ограничения же могут быть лицензионные — ставить компилятор уровня icc на каждую машину это... мнэээ... дорого.
Если реализовать его как сервис ОС, то думается мне, что МС с Интелом договорятся. Тем более, что это будет объективно выгодно обеим сторонам.
Здравствуйте, Cyberax, Вы писали:
C>Нет, они заменяются линкером при запуске, так что оверхеда не больше, чем при обычном вызове функции.
Но инлайна не будет. О чём товарищ выше и сокрушался.
Здравствуйте, alex_public, Вы писали:
_>Собственно данная оптимизация имеет смысл только во вполне определённом случае: если у нас есть критическая для приложения функция, которая ускоряется в разы на процессорах отличных от определённых как минимальные требования для данного ПО. Соответственно в таком случае мы указываем в списке минимальное требование (как и для всего остального кода в проекте) и плюс те поколения процессоров, на которых происходит принципиальный скачок в производительности для данной функции.
А если есть пять разных функций, которые по-разному "ускоряются" на разных архитектурах? Неужели непонятно, что это путь в тупик?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, netch80, Вы писали:
N>>У Intel было две потрясающие возможности убрать весь старый хлам — переходы 16->32 и особенно 32->64. Обе возможности она бездарно протеряла. (Ну, во втором AMD помогла, но тут они близнецы.)
V>Вот именно что. Если бы AMD не навредила, то была бы сейчас архитектура IA64 в мейнстриме.
Не была бы. Даже сейчас это сочетание хренового процессора и хреновых компиляторов. Народ бы просто ушёл на что-то другое, альтернативы были и активно использовались (как Apple на PowerPC), конкуренты дышали в затылок и готовы были отнять всю базу.
AMD их спасла. А вот то, что я говорю — что можно было спасти и чуть менее извращённо
The God is real, unless declared integer.
Re[22]: Что на самом деле произошло с Windows Vista
Здравствуйте, netch80, Вы писали:
V>>Вот именно что. Если бы AMD не навредила, то была бы сейчас архитектура IA64 в мейнстриме. N>Не была бы. Даже сейчас это сочетание хренового процессора и хреновых компиляторов.
Дык, это не мейнстрим, т.е. основные деньги и усилия индустрии не там.
N>Народ бы просто ушёл на что-то другое
А не было куда уходить.
N>альтернативы были и активно использовались (как Apple на PowerPC)
Это даже не смешно.
1. На тот момент OSX технологически была в слишком глубокой ж-пе.
2. До поколения PowerPC G5 там было не о чем даже разговаривать — они годились только на игровые приставки и банковские терминалы.
И когда стало понятно, что G5 (где ввели 64-битную архитектуру) заметно проигрывает Итаниуму и amd64, да еще с наладкой выпуска возникли серьёзные проблемы, то Apple была ВЫНУЖДЕНА переехать на архитектуру amd64. Это ж было болезненно, развлечения ради никто так не делает.
N>конкуренты дышали в затылок и готовы были отнять всю базу.
На тот момент конкуренту Windows не было.
Это уже потом, когда Apple переехал на amd64 и выпустил как из пулемёта кучу обновлений подряд своей OSX, можно стало говорить хоть о чём-то...
Стив Джобс, конечно, сделал невозможное.
Представляю, чего только стоило принять решение переехать на Интел-совместимую платформу. ))
Силён, силён...
N>AMD их спасла.
Ни в одном из мест. Винду и основные проги (офис, SQL-сервак) под Итаниум были переделаны и те первоначально работали быстрее, чем в архитектуре IA32. Этого было достаточно для начала переезда. А там чем дальше, тем было бы быстрее.
AMD нас всех не спасла, а наказала.
Эта чёртова x86 архитектура — это ж позор всей индустрии.
И он теперь очень надолго.
Собсно, я не вижу способов избавиться от этого позора усилиями железячников, т.е. преодолеть эту инерционность.
Спасение должно было придти со стороны софта — как обсуждали байт-код здесь.
Скорее всего так и будет в итоге.
Здравствуйте, CreatorCray, Вы писали:
Ops>>Несколько минут? Это где такое? Зачем в десктопной программе гигабайтные текстуры? Весь экран для FHD в несжатом виде 8М, а в типичном окружении он без потерь до сотен килобайт пожмется. Или ты про Sportster 28.8? CC>Забей, у него пошёл бред на вольную тему.
Раздел "Slow Path" RDP-протокола совместим с T.128 до сих пор, кста.
В общем, смешно слушать рассуждения от тех, кто страшно далёк от темы и питается слухами/мифами.
Спорить со слухами вообще неблагодарное дело. ))
CC>Он с обсуждения RDP перешёл на тему как бы не потокового стриминга видео.
А вот и ЧТД.
Ты так и не понял, похоже, что это практически одно и то же.
Просто ты не в курсе, как кодируется потоковое видео. Там слишком много общего.
В RDP экран бъется на квадратики и передаётся (прямо как в потоковом видео перед кодированием).
Для каждого квадратика вычисляют, что выгодней передать — разницу или сам квадратик (прямо как в потоковом видео, где по результатам алгоритма motion compensation делается вывод — это будет I-frame или P/B-frame).
Есть еще команды перемещения квадратиков (прямо как в потоковом видео).
Для низкоскоростных соединений передаваемое еще и сжимают, причем, сжимают отдельно по цветовым слоям (прямо как в потоковом виде — тоже по слоям, разве что в потоковом видео алгоритм сжатия другой, с потерями).
Основные операции:
— заменить содержимое "квадратика" (TS_UPDATE_BITMAP);
— применять к квадратику битмап + некую операцию (например diff, т.е. простейший XOR);
— переместить одну область в другую на терминале (полезно при перемещении окна мышкой);
— потоковый stream (ы-ы-ы, как грится).
=============
Что такое "потоковый стрим"? — это когда информация выводится на экран не дожидаясь приёма всего PDU (покадрово в некоторой области).
Именно поэтому на удалённой машине можно запросто запустить видеоплейер и смотреть киношку через RDP.
А упомянутый ранее mirror-driver тут нужен лишь для того, чтобы не сканить весь экран и иметь информацию о том, какие области стоит просматривать на предмет изменений, а какие нет.
Re[21]: Что на самом деле произошло с Windows Vista
Здравствуйте, CreatorCray, Вы писали:
CC>Не взлетит никогда. Потому что просто по определению будет работать одинаково плохо везде.
Уже взлетело. Как-то. С каким-то подобием PGO и onfly рекомпиляцией уже скомпилированных кусков. JIT-ы в последних андроидах. Из жаба-байткода в таргеты MIPS/ARMv7/ARM64/x86, как минимум.
kalsarikännit
Re[22]: Что на самом деле произошло с Windows Vista
Здравствуйте, vdimas, Вы писали:
C>>Не позволяет, так как на практике все варианты переносимого JIT-транслируемого байт-кода не достигают скорости нативного.
V>Речь не о JIT, речь об AOT.
реальный AOT тоже не достигает, т.к. от ограничений на время компиляции никуда не денешься. Но идея с AOT мне нравится гораздо больше, чем предварительная компиляция "на века".
ЗЫ: Если AOT переместить в облака, со сборкой клиентской статистики исполнения, ИМХО можно достичь.
ЗЗЫ: Под "нативным" подразумеваю выхлоп современного оптимизирующего С++ компилятора.
Здравствуйте, vdimas, Вы писали:
CS>>DirectDraw это был фактически механизм вывода напрямую в видео память минуя инфраструктуру окон.
V>... Я писал когда-то на DirectDraw, там суть всё та же — создаётся поверхность, на ней рисуешь, потом эта поверхность отображается либо полноэкранно, либо в некоем конкретном окне (через блиттинг или оверлей, если железо позволяет).
V>В D2D полностью аналогично, разве что идентификаторы участников чуть другие.
Ох, ну нет конечно... там только слово Direct общее, а так парадигмы совсем разные.
DirectDraw это про заброс bitmaps в видео память. Как происходит primitive rasterizing на тех bitmap DirectDraw ничего не знал (можно было руками, а можно было GDI или не приведи тя хоспидя GDI+ какой использовать).
Direct2D же...
ID2DRenderingTarget это не bitmap (как правило), а storage для GPU команд.
Вызов ID2D1RenderTarget::DrawLine например это выполнение tessellation того отрезка с заданной stroke т.е. генерация вектора треугольников. А уж этот вектор треугольников отправляется на GPU для рисования.
Т.е. отрисовка окна это последовательное исполнение двух потоков в GPU — команды рисования non-client и batch команд клиентской части.
При такой схеме на стороне CPU вообще той самой bitmap в стиле GDI,GDI+,DirectDraw нет.
Как ты видишь DirectDraw и Direct2D это принципиально разные вещи. В условиях high-dpi monitors DirectDraw (bitmap на стороне CPU) это вообще не опция.
Условно: для отрисовки флага республики Крым на полный экран в DirectDraw ты рисуешь bitmap в CPU и пересылаешь его/её в видео память.
В Direct2D же это три вызова ID2D1RenderTarget::FillRect что выливается в посылку координат шести треугольников (+ три brush) в GPU.
Разница очевидна, нет?
V>В OpenGL аналогом является frame buffer, созданный поверх текстуры или экранного буфера (deep buffer). Т.е. во всех случаях речь идёт о массиве байт в видеопамяти.
Ну можно наверное frame buffer условно обозвать DirectDraw. Но очень условно.
Аналог же Direct2D в OpenGL... Ну вот скажем NanoVG это самое близкое по смыслу...
Re[22]: Что на самом деле произошло с Windows Vista
Здравствуйте, vdimas, Вы писали:
K>>>Байт-код позволяет переложить это на плечи разработчика рантайма. C>>Не позволяет, так как на практике все варианты переносимого JIT-транслируемого байт-кода не достигают скорости нативного. V>Речь не о JIT, речь об AOT.
А без разницы. Пока что нет систем с байт-кодом, которые систематически превосходили бы по производительности нативный код.
Т.е., "под капотом" там происходило примерно одно и то же.
Ограничения же могут быть лицензионные — ставить компилятор уровня icc на каждую машину это... мнэээ... дорого. 
