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

V>DirectDraw появился изначально для WinMobile
Ты почему то с гуя всё время сползаешь на какие то другие темы, которые тебе видимо удобнее обсуждать.
Кто в своём уме на DD гуй в те времена делал?
Всё было на GDI.

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

CC>>Какие млять шейдеры? Откуда в гуе шейдеры?
C>Начиная с Aero для общих эффектов и продолжая в Direct2D для собственно самого рендеринга, а что?
Это детские шейдеры, они на чём угодно, даже на встроенном видео работают. Передавать есессна сам HLSL, как объект, потом дёргать его уже как операцию.

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

V>Вопрос-то стоит по-другому — "RDP должен адекватно работать в любом сценарии".
Кому должен? Кто такую задачу ставил?

V>Похоже, что я опять тебя удивлю
Не, я странным заявлениям от тебя уже давно не удивляюсь.

V> но такой сценарий — один из самых популярных для RDP.
Среди кого?

V>Всему остальному RDP вообще не нужен, достаточно удалённого текстового шелла.
Угу, шелла, на винде.
Кому он нафиг нужен, шелл на винде?

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

CC>>А кому есть дело до AMD?
Ops>Ну вообще-то есть, это 20% рынка x86 процессоров.
Они всё больше во всяких приставках светятся в последнее время.

CC>>Вспомни Blu-Ray vs HD-DVD.
Ops>Так у них рынок помирал
Ну и где он помер, этот рынок? До сих пор полно BD в продаже.

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

K>Исходник слишком высокоуровневый для эффективного переноса.
Wut?

K> Да ещё и язык чрезмерно сложный.
Допустим возьмём С. Куда уже проще?

K> Собственно отсюда и родилась концепция HAL, на которой построены все современные ОС.
HAL это Hardware Abstraction Layer
Родилась она как идея обеспечить одинаковый базовый API для работы ядра под разным железом.

K> Если стандартизировать байт-код из относительно небольшого набора команд, то над ним можно надстроить легко переносимый код.
Можно, но при этом довольно сильно потеряв в эффективности этого кода.
Тыж понимаешь, и на brainfuck можно писать программы. Вот только сначала придётся сложные конструкции разбить на туеву хучу простых а потом эти простые собрать обратно в сложные.

K> Вопрос упирается только в наличие эффективного jit/ngen
Jit сразу идёт в лес просто потому что у него банально нет времени и ресурсов генерировать эффективный код.
ngen в это же ничем не лучше компилятора, вот только пространство для манёвра у него хуже, потому что он видит простые команды, тогда как должно быть что то типа AST. Но если заморачиваться с AST то почему бы не взять тогда сразу сурсы и использовать готовые компиляторы?

K> собственно UWP как раз и построена на этой идее — когда разработчики сабмитят байт-код в стор, а пользователям доставляются уже "нативизированные" сборки под его конкретную платформу.
Ну, посмотрим что из этого получится. Мне что то кажется что не взлетит.

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

НС>Здравствуйте, netch80, Вы писали:

N>>Давай ограничимся 32-разрядным режимом.
НС>О, уже ограничения понадобились.

Естественно, какие-то ограничения нужны. Иначе ты код для Мир-2 потребуешь исполнять

N>> То есть это будет 3.11+Win32s vs. Win10. В таком случае, думаю, уже реально увидеть программу, которая работает в обоих. И она вполне может даже выполнять что-то очень важное полезное.
НС>Но выглядеть она все равно будет как гавно.

Она будет выглядеть как стандартная виндовая прога без изысков. Причём оформление будет своё под каждую из этих систем. Если это для тебя "говно", то докажи это Microsoftʼу, который придумал все эти стандартные элементы GUI.
Или она может выглядеть со своими элементами полностью. Как Winamp в его лучшие времена. И тоже будет работать.

N>>В случае же x86 — сборка под i386, конечно, даст немного неоптимальный код, но позволяет покрыть огромнейший диапазон функциональности.
НС>Ну так а вот байткод позволяет обойтись без компромиссов.

"А вот если бы у рыбы была шерсть, на ней жили бы блохи" (tm)

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

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

N>>С точки зрения внутреннего устройства процессоров — между ними ничего общего, кроме кремния.
K>Система команд та же.

Специально для убогих, которые не в состоянии перенести свой код (то есть, для 99.99% разработчиков).

N>>Ну да, согласен с кэпской частью этой фразы. Но в общем случае, как уже сказали, байт-код — не гарантия эффективности результата такого переноса.
K>Это вопрос реализации, а не принципиальная проблема подхода.

Когда будет доступная идеальная реализация — твои слова получат смысл. А сейчас это уровень "через четыре года на Марсе будет город-сад".

N>>В плане стимуляции некоторых решений Intel — очень даже при чём.
K>Примеры приведёшь? Только чтоб они были лет эдак 20 назад, когда защищённый режим только начал появляться (ибо многие считают этот момент поворотным в эволюции x86).

У тебя как-то убойно с хронологией. Только выпуск i286 с защищённым режимом это 1983, а разработка была явно раньше. Это уже 34 года. Xenix (майкрософтовский!) под эти процессоры вышел примерно тогда же. i386 (страничная организация) — 1985.
Нет, я имел в виду в первую очередь AVX. Формат "SSE не трогает старшие части расширенных регистров", по некоторым утверждениям, прямо навязан Microsoft, которые сказали "мы не готовы защищать данные в них". В результате имеем гимор с переключениями режимов SSE<->AVX (писалось, около 70 тактов) и vzeroupper/vzeroall. Этому 10 лет, а не 20. И это при том, что уже было ясно, что гонка частот остановилась

Если смотреть именно на 20 лет назад, то это выход SSE в большой мир и появление SSE2. Соответственно, это времена погони за графикой. Прямое следствие — попытка Rambus и разработка Pentium4.

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

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

C>>>То есть? По традиции новые платформы сейчас обратно-совместимы с предыдущими.
K>>Вот в этом-то и есть суть проблемы. Именно из-за этого система команд x86/x64 представляет из себя Адъ и Израиль, в котором без ящика водки не разберёшься. При том, что большая часть команд, режимов и подрежимов уже давным-давно устарела и не используется.
C>Нет, ну тут надо выбирать одно из двух: или старый код работает на новых CPU, или переписываем всё каждую итерацию микроархитектуры.

У Intel было две потрясающие возможности убрать весь старый хлам — переходы 16->32 и особенно 32->64. Обе возможности она бездарно протеряла. (Ну, во втором AMD помогла, но тут они близнецы.)

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

C>>Нет, ну тут надо выбирать одно из двух: или старый код работает на новых CPU, или переписываем всё каждую итерацию микроархитектуры.
N>У Intel было две потрясающие возможности убрать весь старый хлам — переходы 16->32 и особенно 32->64. Обе возможности она бездарно протеряла. (Ну, во втором AMD помогла, но тут они близнецы.)
Переход 16->32 состоялся, когда никто (в том числе и Intel) не думал, что x86 задержится надолго. Это был 85-й год, т.е. разработку начали где-то в 82-м году.

Переход 32->64 они попробовали сделать революционным, но получился Итаник.

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

V>>DirectDraw появился изначально для WinMobile
CC>Ты почему то с гуя всё время сползаешь на какие то другие темы, которые тебе видимо удобнее обсуждать.

Наверно потому что то, чего сейчас служит D2D, раньше называлось DirectDraw?


CC>Кто в своём уме на DD гуй в те времена делал?
CC>Всё было на GDI.

Да все, кому надо было видео, анимация, даже просто CAD-программу с кучей линий на GDI не сделаешь — жутко тормозило-с.

Причем, видео по тем временам было сугубо софтовое, т.е. это просто разновидность анимации была.

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

V>>Вопрос-то стоит по-другому — "RDP должен адекватно работать в любом сценарии".
CC>Кому должен? Кто такую задачу ставил?

Билл Гейтс лично, разумеется. ))


V>>Похоже, что я опять тебя удивлю
CC>Не, я странным заявлениям от тебя уже давно не удивляюсь.
V>> но такой сценарий — один из самых популярных для RDP.
CC>Среди кого?

Среди данной цепочки обсуждения, которую ты уже успел потерять — для пользования мощным CAD.
Работает прекрасно.
Лежишь себе на диванчике с ноутом или планшетом, а в соседней комнате пыхтит мощный комп.


V>>Всему остальному RDP вообще не нужен, достаточно удалённого текстового шелла.
CC>Угу, шелла, на винде.
CC>Кому он нафиг нужен, шелл на винде?

А кому он нужен — сам терминал-то?
Единственный другой популярный сценарий был (кроме пользования мощными удалёнными ресурсами) — это запуск файловой 1C. ))
Дык, тоже уже относительно давно не актуально.

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

N>Естественно, какие-то ограничения нужны. Иначе ты код для Мир-2 потребуешь исполнять

Я взял тот же временной интервал — дату выхода i386. Windows 1.0 — его ровесник.

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

I>>Visual Studio Code
CC>Для моих целей не подходит, просто нет нужной функциональности — не дотягивает даже до старых студий.

Ужос, редактор, который изначально задумывался как не-IDE, является не-IDE

I>> Atom
CC>Вообще хз что это.

Это более популярный аналог VS Code.

I>>а то окажется что твой любимый тул написан на Electron или NW
CC>Мой любимый тул MVSC 2008 + VAX + ICC
CC>Так что нет, не написан.

Твой случай сильно частный, он никому кроме тебя неинтересен. Огромное количество девелоперов юзает один из двух редакторов, что я привел. Кроме того, есть и другие редакторы на этом же движке, и другие тулы.
Посмотри, какие софтины пишут на Electron и nwjs.

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

I>>Visual Studio Code, Atom — ты как нибудь поинтересуйся

НС>Интересовались уже, неоднократно. По сравнению с настоящей VS — гавнно гавном. Пользоваться можно только на безрыбье. Ну или если ты хипстер.

Ужос, редакторы который предназначался "быть не IDE" удруг не IDE. Скажем, VS как не умела, так и не умеет внятно работать с фолдерами, как с проектами. Собственно, для фронтенда а также многих немейнстримных языков это очень актуально. Для них IDE не появится в ближайшие годы.

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

V>Мы всё еще об обработке звука?
V>Тут достаточно взглянуть на популярные программы, типа FL Studio:
V>Image: 25381_594.jpg

Ну вот же. Никаких диких текстур.

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

CC>Они всё больше во всяких приставках светятся в последнее время.
Ты почитай, они в этом году как раз отыгрывать начали.

CC>Ну и где он помер, этот рынок? До сих пор полно BD в продаже.
Да ладно? Кому продают? Кому вообще сейчас нужны диски, любые?

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

I>Твой случай сильно частный, он никому кроме тебя неинтересен. Огромное количество девелоперов юзает один из двух редакторов, что я привел. Кроме того, есть и другие редакторы на этом же движке, и другие тулы.
I>Посмотри, какие софтины пишут на Electron и nwjs.

На электроне написали новый PgAdmin 4. Дрянь дрянью, тормозит даже локально, удаленно еще сильнее тормозит, потому что отрисовка у него как раз через растр.

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

I>>Твой случай сильно частный, он никому кроме тебя неинтересен. Огромное количество девелоперов юзает один из двух редакторов, что я привел. Кроме того, есть и другие редакторы на этом же движке, и другие тулы.
I>>Посмотри, какие софтины пишут на Electron и nwjs.

С>На электроне написали новый PgAdmin 4. Дрянь дрянью, тормозит даже локально, удаленно еще сильнее тормозит, потому что отрисовка у него как раз через растр.

Растр ни при чем. Растром в браузере можно рисовать не хуже чем в нативном виндовском апи.

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

V>>Тут достаточно взглянуть на популярные программы, типа FL Studio:
V>>Image: 25381_594.jpg
Ops>Ну вот же. Никаких диких текстур.

А в правом нижнем углу что? ))

Это всего лишь один из инструментов отображается в режиме графики плагина (остальные в режиме настроек хоста, а там одинаково для всех).

Можно пройтись по картинкам в гугле, посмотреть, как оно на самом деле.

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

V>А в правом нижнем углу что? ))

Мелочевка, в моем примере такая же была. На ползунок или крутилку много не надо, а когда их несколько одинаковых, саму текстуру не требуется дублировать, просто отрисовать иначе.

V>Можно пройтись по картинкам в гугле, посмотреть, как оно на самом деле.

Так какие-то ненужные текстуры от силы в четверти случаев, остальное все вполне разумно сделано. Контролы, даже текстурированные, занимают немного, просто размножены многократно.