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

Ops>Ты только что предложил самый куцый вариант для всех АМД.
А кому есть дело до AMD?
Вспомни Blu-Ray vs HD-DVD.
Так и тут.

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

V>Текстуры имеют разрешение с прицелом на экраны с высоким DPI в т.ч.
Ну и какой псих с этим станет работать через RDP?

V>А вот тут нахрена?
Просто потому, что могут.
Но эта прога через RDP и так и так бесполезна.

V>Это еще копейки. Ты возьми какой-нить CAD-пакет для того же строительства. Вот уж там текстур в память грузится — мама не горюй. Не каждая видюха потянет более-менее приличный проект.
Из той же категории — с такими прогами не работают remotely.

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

С>Но скажи, зачем на этих тум-балалайках изображать морды каких-то усилков и прочей ерунды? Что, обычных слайдеров не хватает? Или графа звукового потока, где в каждом узле стоит свой обработчик с ползунками?
По какой то причине каждый производитель таких тулов изгаляется в попытках перещеголять конкурента по попугайности контролов.
Такое ощущение что целевая аудитория без этих свистоперделок просто не может.

С>Это какая-то болезнь головного мозга у тех, кто делает музыкальный софт.
Да.
Есть совсем долбанутые, которые рендерят типа внутри "тёплые ламповые" лампы.

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

V>Только уже последние лет 10 и более новые проги не рисуют через GDI.
Ты не поверишь!

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

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

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

C>>Нет, ну тут надо выбирать одно из двух: или старый код работает на новых CPU, или переписываем всё каждую итерацию микроархитектуры.
K>Байт-код позволяет переложить это на плечи разработчика рантайма.
Для этого рантайм должен распухнуть до монструозных размеров всемогутера.
Проблема одна, чем больше всемогучесть тем больше накладные расходы на то, чтобы не расплющиться под собственным весом.

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

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

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

НС>Он же бесплатный есть — https://software.intel.com/en-us/articles/free-ipsxe-tools-and-libraries
Ты сам то читал что там написано?

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

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

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

Ops>Это не для работы. Оно может даже будет продаваться, но не как профессиональный инструмент. Я, конечно, не против раскраски кода в IDE, но вот немотивированное превращение ее в светофор мне нафиг не сдалось, и плагин, натягивающий на нее текстуры, я ставить не буду.

Да кто тебя спросит? ))
Вот есть некая функциональность только в таком-то плагине — и делать нечего.


Ops>Что за жанр такой? Нормальный софт, вот так, например, выглядит:

http://www.magix-audio.com/
Это для домохозяек, кто не в теме.
Ну и такой GUI устарел лет 10 назад или больше.
Посмотрел я там на другие их продукты для аудио — малость улыбнуло, один подход везде — для домохозяек, кто не слышал ни одной аббревиатуры в этой предметной области.

Сейчас нужен просто качественный хост плагинов, с удобным ортогональным микшированием. Всё. Но самих плагинов может быть очень много и эти плагины занимаются прорисовкой практически как им вздумается.


Ops>От оно. Такой софт и не гоняют удаленно.

Наоборот, я бы сделал мощную станцию для графического терминального доступа к ней.
Изначально графические CAD так и строились.

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

CC>Да что байт код, даже сурсы не позволяют обеспечить полную переносимость программы между архитектурами для сколь либо существенной функциональности. Всегда что нибудь да приходится перепиливать.
Исходник слишком высокоуровневый для эффективного переноса. Да ещё и язык чрезмерно сложный. На более низком уровне обеспечить переносимость намного проще. Собственно отсюда и родилась концепция HAL, на которой построены все современные ОС. Я же говорю о ещё более низком уровне. Если стандартизировать байт-код из относительно небольшого набора команд, то над ним можно надстроить легко переносимый код. Вопрос упирается только в наличие эффективного jit/ngen, собственно UWP как раз и построена на этой идее — когда разработчики сабмитят байт-код в стор, а пользователям доставляются уже "нативизированные" сборки под его конкретную платформу.

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

CC>А кому есть дело до AMD?
Ну вообще-то есть, это 20% рынка x86 процессоров. А вообще, во многих нишах хватило бы и единиц %. Правда тут пишут, что эта проблема у ICC уже не актуальна.
CC>Вспомни Blu-Ray vs HD-DVD.
Так у них рынок помирал, не за что воевать было, какой смысл вкладываться в технологию, доживающую последние дни? А были бы у дисков перспективы, все закончилось бы комбайнами, умеющими оба, как произошло с записываемыми ДВД.

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

V>>Иначе бы не рассуждал отдельно о DX 3D и отдельно о 2D. Тем более, что в DX9 никакого 2D нет и вообще до Win7 не было
CC>
CC>Первый HW accelerated 2D появился внутри винды где то в ХР, насколько я помню.

Ну вот плохо помнишь. DirectDraw появился изначально для WinMobile, попал в DX и сразу был объявлен deprecated. Да и не работал зачастую на десктопе, т.к. не все карточки поддерживали в нужном объеме.

Сами версии DX шли асинхронно с версиями винды. Сменяли друг друга очень быстро, пока не наступила версия DX9. Затем лишь выходила куча патчей к этой версии, но она была и до сих пор остаётся стандартом де-факто уже более 15 лет. Без всякого 2D, заметь.


CC>Потом в висте его сломали, в W7 вернули назад и прикрутили Direct2D для более public доступа.

Ну вот так ты разрабатывал библиотеки для игр. ))
Дело не в W7, а в новом АПИ DX10.
Его сделали доступным и для Висты официально и существует тонна неофициальных сборок DX10 даже под WinXP.


V>>Столько слов вместо простого признания в том, что ранее ляпнул не подумав.
CC>Не юли.
CC>Съехал с темы ты, а пургу гонишь на меня.

Я продолжаю утверждать то же, что и утверждал.
Просто ты требуешь всё новых и новых объяснений, почему ты сказал не подумав. ))

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

V>Ну и такой GUI устарел лет 10 назад или больше.
А твой устарел несколько раньше.

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


С>Про рендеры из CAD понятно, хотя никто в реальном времени с рендером не работает, обычно там крутят модельку из линий.

В рантайм крутят примерно такое:


А заключительную растеризацию, действительно, считают долго, но это совсем другого уровня картинки:
http://www.lunas.pro/3d-interior-visualization.html


С>Но скажи, зачем на этих тум-балалайках изображать морды каких-то усилков и прочей ерунды? Что, обычных слайдеров не хватает? Или графа звукового потока, где в каждом узле стоит свой обработчик с ползунками?

И как ты тогда отличишь один инструмент от другого? По названию мелким шрифтом в углу? ))


С>Это какая-то болезнь головного мозга у тех, кто делает музыкальный софт.

Болезнь головного мозга — это когда пытаются в жертву ангажированности принести эффективность.
С Украиной такое происходит, кста.

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

V>>Текстуры имеют разрешение с прицелом на экраны с высоким DPI в т.ч.
CC>Ну и какой псих с этим станет работать через RDP?

Всё еще пытаешься "съехать"? ))
Вопрос-то стоит по-другому — "RDP должен адекватно работать в любом сценарии".


V>>Это еще копейки. Ты возьми какой-нить CAD-пакет для того же строительства. Вот уж там текстур в память грузится — мама не горюй. Не каждая видюха потянет более-менее приличный проект.
CC>Из той же категории — с такими прогами не работают remotely.

Похоже, что я опять тебя удивлю, но такой сценарий — один из самых популярных для RDP.
Всему остальному RDP вообще не нужен, достаточно удалённого текстового шелла.

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

V>>Только уже последние лет 10 и более новые проги не рисуют через GDI.
CC>Ты не поверишь!

Не поверю. ))

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

_>>Ты не прав, сама идея универсального байт-кода вполне хороша.
CC>Теория может и хороша. Но вот практика вносит свои коррективы.

Эту тему обсуждали уже не раз. Шоу-стоппером для оптимизаций джавовского или дотнетного байткода является обеспечение рантайм-рефлексии всей программы. Как только рефлексия не нужна, сразу можно оптимизировать сколь угодно агрессивно.

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

V>>Ну и такой GUI устарел лет 10 назад или больше.
Ops>А твой устарел несколько раньше.

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


или на самые популярные VST-плагины и сразу всё станет ясно. :zx:

Смысл рассматривать некий маргинальный софт с интерфейсом а-ля Fruity Loops 1999-го года выпуска?

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

C>>Нет, ну тут надо выбирать одно из двух: или старый код работает на новых CPU, или переписываем всё каждую итерацию микроархитектуры.
K>Байт-код позволяет переложить это на плечи разработчика рантайма.
Не позволяет, так как на практике все варианты переносимого JIT-транслируемого байт-кода не достигают скорости нативного.