Все что выше скипнуто, поскольку Павел Кузнецов высказал свою точку зрения, с которой я согласен.
VD>1. Нет тут никакого компромиса.
Скипнуто. Я бы описал так. Проблема в том, что в MSIL массив есть instanse объект — единый и неделимый, и наследующий единую функциональность. Это не область памяти как в С++ и других языках с неуправляемым кодом(в большинстве языков). Сделать такое с выбранной концепцией просто физически невозможно или чрезвычайно неэффективно.
VD>Надо понимать, что принцип очень прост. Дотнет обеспечивает безопастность на уровне модели допускающей контроль. МСИЛ можно статически проверить на безопастность типов. И если имеются преобрзования гарантирующие сохранение семантики, то такие преобразования так же будут порождать безопастный код (хотя рельно он будет исползовать отнюдь не безопастные конструкции). Так вот джит не обазан порождать код буква в букву соотвествующий соотвествие "модельному коду". Важно, чтобы соблюдалась семантика. Таким образом джит может делать любые оптимизации.
VD>Качество же оптимизации зависит исключительно от двух факторов: VD>1. Навороченности оптимизатора. VD>2. Времени имеющемуся на оптимизацию кода.
3. Концепция типобезопасности+GC. Статически проверить типы JIT значительно сложней (а точнее иногда невозможно). Но поскольку существует концепция типобезопасности (спасибо что ты есть), то типы проверяются динамически. В результате получаем отличие благодаря концепции.
VD>Отсюда можно заключить, что если будет создана систем позволяющая поэтапное добавление оптимизаций, и если все эти оптимизации смогут осуществляться на этапе инсталляции или даже предворительной компиляции, то скоростные характеристики порождаемого кода будут очень высоки. И никаких проблем кроме сложности подобной задачи не существует. Так что будет время и деньги, и будет супер быстрый управляемый код.
3 пункт все меняет. Концепция влияет. Это только один пункт который пришел сразу на ум.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Несовсем. Такие вещи как боксинг, интерфейсы, делегат, итераторы и т.п. это все ООП-патерны встроенные в язык. Их нет в С++.
ПК>Боксинг, интерфейсы, делегаты и итераторы реализуются на C++ в виде библиотек без сколько-либо заметного напряга.
Ну, так согласен что в С++ их нет, и что они все встроены в Шарп?
ПК>(за исключением лямбды, что к ОО не относится)
Лямбды это тебе не делегаты. Делегаты ОО-сущьность. Они позволяют хранить ссылку на объект.
>> Нет задач требующих прямого доступа к памяти.
ПК>Есть даже задачи, требующие прямого доступа к стеку и регистрам. Эти задачи даже на C или C++ не решаются, не то что на C#. Тут только ASM.
Если речь не идет о драйверах, то таких задач нет. Это всего лишь оптимизации.
ПК>Каким это, интересно, образом получение поддиапазона может нарушить абстракцию или инкапсуляцию более, чем это делает получение отдельного элемента?
Тем что это опора на знание организации памяти на конкретной платформе.
>> Надо понимать, что принцип очень прост. Дотнет обеспечивает безопастность на уровне модели допускающей контроль. МСИЛ можно статически проверить на безопастность типов.
ПК>Если приведения типов включены в MSIL, то статически — нельзя; как минимум часть проверок придется делать в динамике.
Не нужно вырывать фразы из контекста. Речь шла о массивах и том, что не нужно делать проверок при обращении к каждому их элементу.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> Боксинг, интерфейсы, делегаты и итераторы реализуются на C++ в виде библиотек без сколько-либо заметного напряга.
> Ну, так согласен что в С++ их нет, и что они все встроены в Шарп?
Опять двадцать пять... Мне все равно, в языке нечто или в библиотеке. Скорее, даже интереснее, если язык позволяет делать подобные вещи самостоятельно, а не ограничивает набором уже встроенных "рюшечек".
> ПК> Есть даже задачи, требующие прямого доступа к стеку и регистрам. Эти задачи даже на C или C++ не решаются, не то что на C#. Тут только ASM.
> Если речь не идет о драйверах, то таких задач нет. Это всего лишь оптимизации.
Речь идет не о драйверах. Например, такая задача возникла при связывании встраиваемого языка с C++. А также при разработке ядра этого языка. Ни о каких оптимизациях речь там не шла.
> ПК> Каким это, интересно, образом получение поддиапазона может нарушить абстракцию или инкапсуляцию более, чем это делает получение отдельного элемента?
> Тем что это опора на знание организации памяти на конкретной платформе.
Не нужно знание об организации памяти на конкретной платформе, чтобы получить объект, представляющий собой поддиапазон массива. Это даже в Питоне делается.
> ПК> Если приведения типов включены в MSIL, то статически — нельзя; как минимум часть проверок придется делать в динамике.
> Не нужно вырывать фразы из контекста. Речь шла о массивах и том, что не нужно делать проверок при обращении к каждому их элементу.
Очень интересно... А как же избежать этих проверок в присутствии возможности приведения массивов к массивам базовых классов? Эти ошибки (например, помещение в массив унаследованного класса объектов базового) в C# в run-time вылетают, а не в compile-time.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, GlebZ, Вы писали:
VD>>1. Нет тут никакого компромиса. GZ>Скипнуто. Я бы описал так. Проблема в том, что в MSIL массив есть instanse объект — единый и неделимый, и наследующий единую функциональность. Это не область памяти как в С++ и других языках с неуправляемым кодом(в большинстве языков). Сделать такое с выбранной концепцией просто физически невозможно или чрезвычайно неэффективно.
Очено убедительно и обосновано.
GZ>3. Концепция типобезопасности+GC. Статически проверить типы JIT значительно сложней (а точнее иногда невозможно). Но поскольку существует концепция типобезопасности (спасибо что ты есть), то типы проверяются динамически. В результате получаем отличие благодаря концепции.
Сложнее не значит невозможно. В случае с многомерными массивами проверки типов вообще не причем. Они не делаются уже сйчас.
GZ>3 пункт все меняет. Концепция влияет. Это только один пункт который пришел сразу на ум.
Придумывать надо меньше. В общем, тест есть. Coredbg.exe и "m JitOptimizations 1" тоже есть. Запускашь одно под ругим и убеждашся в том что заблуждался. Хэлп по командам печатается вводом "h".
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Но в жизни все зависит от того, насколько быстро на рынок выйдут качественно акселерированные видеокарты.
Нада. А ты можешь найти рядом с собой компьютер на котором не стаяло бы хотя бы Riva-ы?
ЗЫ
Все очень просто. Те ктому не нужна быстрая графика и "поворот эбаута вокруг чего-то-там" просто живут на нормозном софтовом лов-энд драйвере, а то и просто на сторых ОС. Остальные потихоничку перелизают на Лонгхорн.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Поджариста.
MS> Только похоже, что это какая-то секретная организация MS>Каких-то левых упоминаний много, а на самой MS только вот эта презенташка.
Дык, а например о том же Фениксе что-нибудь более презинтахи найди.
В общем-то по-моему все ясно. Это технология низкоуровневая и расчитана она на будующее. Сейчас и видюх то поддерживающих это чудо нет. Вкладывать деньги в ее пиар пока смысла нет. Информация появилась благодоря тому, что это одна из подсистем ОС. Вот когда лонгхорн будет ближе к релизу, а то и после его выхода, может и начнут пиарить.
VD>>2D просто выбрасывается. Ведь разницы между 2D и рисованием на плоскости в 3D в общем-то нет.
MS>Теоретически — несомненно. На практике — там стоолько проблем — копать-неперекопать.
Ну, вот у МС и копает. В общем-то уже даже накопало. Два из трех заявленных режима ГУИ в Лонгхорне будут базироваться на D3D. Третий же старый добрый ГДИ (т.е. просто завернут старую библиотеку).
MS> Грамотное сглаживание границ (antialias) плюс субпиксельная точность очень плохо совместимы с 3D.
По последним играм это не скажешь. В ФарКае, Думе3 и Халфе2 с включенными режимами сглаживания и т.п. можно читать текст на стенах в конце уровня.
MS> Чего только стоит одна пробема совмещения граней (bleeding effect).
Какие еще грани в 2D?
В общем, не знаю какие там проблемы но это все уже работает в Лонгхорне. И вроде как очень не дурно.
MS> Боюсь, что все эти 3D-окна с перспективой будут выглядеть позорными лестницами, как и сейчас выглядят резкие грани во всех игрушках и интрах.
Ты бы ради хохмы поглядел авишники годовалой давности. Там даже видио на 3D-плоскостях умудряются крутить. Что уж там до примитивного текстурирования?
MS> Это очень похоже на чисто рекламную замануху, а на практике все будут тут же отключать эти 3D-меню, как я сейчас отключаю этот аляповатый WinXP look&feel Им надо брать пример с Apple и нанимать грамотных дизайнеров, вместо того, чтобы полагаться на фотожопные упражнения некого Joe Sixpack в сотрудничестве с Сидором Колобковым.
Думаю, что они лучше нас с тобой знают что им делать. Отключаешь "WinXP look&feel " только ты и еше пара тысяч велвоек во всем мире что не умеет принимать новое. Все остальные прекрасно пользуются приемуществами новых технологий.
Что до брать пример, то это вообще смешно. Это все равно что олигарху брать пример с клерка средний руки. Эпэл и жив то только благодаря тому, что МС нужны ручные конкуренты.
MS>XAML — хорошо. Попытка решить задачу космического масштаба — плохо.
Меня просто умеляет твоей снобизм. То что эта задача не по зубам тебе или мне, еще не значит что она не решаема. У МС хватает денег и сил. Это их задачи и они ее успешно решают.
MS> К слову сказать, уж на что Квац — эталон с точки зрения качества 2D и графического API, так и то, наиболее продвинутые используют AGG даже на Маках.
Рад за них. Я не продвинутый. У меня даеж Маки использовать никакого желания нет. А в области графики мне больше наравятся творения ID и КрайТим.
MS>К слову сказать, упомянутые выше тесты качества графических акселераторов проделаны именно на Маке.
К слову сказать, там использован какой-то хлам и такие же мусорные технологии. Лонгхон на них не рассчитан. Его 3D заточено на карты последних 4 поколений и на D3D. Их хватает на современные игры, а уж на градиентные заливки и теньки в примитивных формочках их хватит и подавно.
В общем, забавно беседовать с человеком который не верит ни во что что сам пока не видел. Но я то видел. Авалон валяется у меня на винте. Все в нем шустро и красиво. Описываемых тобой проблем особо незаметно.
Вот погляди статейку Avalon – ноябрьский Community Technical Preview (перевод). Там в конце скриншоты Шарповскоко приложения снятые мной на моей машине в прошлом году. Это все работает со скоростью звука под ХРюшей. Все это чистый 3D. Битмапы только изображения пользователей на кнопках. Даже зеленые кнопочки нарисованы Авалоном. Если тебя такое качество устроет (с поправкой на джипег), то думаю разговор можно закрыть.
MS> Ты веришь, что через год-два хотя-бы несколько хардварных контор обеспечит вот такое качество рендеринга (что, кстати, значительно лучше, чем даже в Quartz2D)? Да еще и в 3D чтоб все то же самое?
Я уверен, что оно обеспечено еще лет 6 тому назад.
MS> И чтоб быстро со страшной силой.
Начиная с Вуду2 ни один процессор не может угнаться за 3D-акселераторами. Так что скорость уж точно будет выше чем на софте. Да и не нужно для ГУИ особо быстро. 30 кадров в секунду более чем достаточно. А современные игрушки дают сотни, и в куда более сложных условиях.
MS> Я — нет.
Ну, а в чем ты вообще уверен? Ты же не веришь не одному моему слову.
Ну, да выйдет Лонгхорн и Авалон убедишся сам.
MS> Графическая индустрия занята окучиванием игрушечников и заботиться о таких "мелочах" им недосуг.
Здается мне, что мелочи — это пролема прикладников. Сглаживание, мультитекстурирование, аппоратную "алфу" и т.п. 3D карты обеспечивают очень давно. Любая карта ценой вше 100 баксов дает качество выше всяких похвал (при соотвествующих настройках). Так что ты опять застрял в прошом веке.
MS> А вообще-то я с удовольствием бы переключился на более высокоуровневые вещи, если наступит такое "щасте". Но наступит ох как нескоро. И подозреваю, что не без моих усилий
Авалон будет доступен на ХРюще уже в этом году. Лонгхорн в следующем. Так что считай счастье уже настало.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если кому интересно... картинка Авалона пожатая в png-24
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Опять двадцать пять... Мне все равно, в языке нечто или в библиотеке. Скорее, даже интереснее, если язык позволяет делать подобные вещи самостоятельно, а не ограничивает набором уже встроенных "рюшечек".
Ну, то-есть спорными слова не были? Так и запишим. В общем, ты давай не объявляй все слова "спорными", а оспаривай конкретные моменты с конкретными фактоами. А то как-то странно получается. Слова спорные, но оспорить не можешь.
А что до библиотек... Тут уже дело в удобстве испоьзования.
ПК>Речь идет не о драйверах. Например, такая задача возникла при связывании встраиваемого языка с C++. А также при разработке ядра этого языка. Ни о каких оптимизациях речь там не шла.
Что такое "встраиваемого языка" и что не позволяет обходиться без ассемблера?
>> Тем что это опора на знание организации памяти на конкретной платформе.
ПК>Не нужно знание об организации памяти на конкретной платформе, чтобы получить объект, представляющий собой поддиапазон массива. Это даже в Питоне делается.
К сожалению некоторыми своими правилами Питон заранее определяет свою реализацию. Списки в питоне обязаны быть сслочными и менее эффективными. Так что аналогия с Питоном не уместна.
Что же касается подиапазона, то на логическом уровен в этом особой необходимости нет. Ну, а на физичесоком... это работа оптимизирующего компиляотора. Не гоже ее спихивать на прикладного программиста.
>> ПК> Если приведения типов включены в MSIL, то статически — нельзя; как минимум часть проверок придется делать в динамике.
>> Не нужно вырывать фразы из контекста. Речь шла о массивах и том, что не нужно делать проверок при обращении к каждому их элементу.
ПК>Очень интересно... А как же избежать этих проверок в присутствии возможности приведения массивов к массивам базовых классов?
1. В описываемом случае классами (ссылками если быть более точным) и не пахен. Стало быть привдить просто нечего.
2. В цикле одно и то же приведение, из одной и той же переменной делается сотни миллионов раз. Нет особых проблем вынести такие проверки из цикла. Это его инвариант. Например, в следующем коде:
class A { }
class B : A { }
class Program
{
static void Main(string[] args)
{
B[] array = new B[10];
Test(array, new B(), new A());
}
static void Test(A[] array, A obj1, A obj2)
{
int half = array.Length / 2;
for (int i = 0; i < half; i++)
array[i] = obj1;
for (int i = half; i < array.Length; i++)
array[i] = obj2;
}
}
Можно смело вынести проверки типов за пределы циклов. Ведь типы ни array, ни obj1, ни obj2 не могут измениться во время работы цикла.
ПК> Эти ошибки (например, помещение в массив унаследованного класса объектов базового) в C# в run-time вылетают, а не в compile-time.
Ну, опиши какие теоретические проблемы могут возникнуть в примере выше. Это кстати, один из наиболее часто применимых паттернов.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Многомерные массивы в C# - очередной наезд
Здравствуйте, VladD2, Вы писали:
MS>> Грамотное сглаживание границ (antialias) плюс субпиксельная точность очень плохо совместимы с 3D.
VD>По последним играм это не скажешь. В ФарКае, Думе3 и Халфе2 с включенными режимами сглаживания и т.п. можно читать текст на стенах в конце уровня.
Это ни о чем не говорит. А вот что действительно было бы интересно — так это воспроизвести вот эту картинку http://antigrain.com/demo/aa_test.png на разных продвинутых картах, используя OpenGL или D3D. Исходник здесь: http://antigrain.com/demo/aa_test.cpp.html описание здесь: http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html. Из этого легко сделать на OpenGL или D3D.
Пристально посмотреть на качество и оценить, насколько хорошо оно все "поддерживается" на HW уровне. Вот это для меня был бы критерий. Кто-нибудь возьмется за такое? Было бы просто замечательно!
VD>Ты бы ради хохмы поглядел авишники годовалой давности. Там даже видио на 3D-плоскостях умудряются крутить. Что уж там до примитивного текстурирования?
Мы ведем разговор о разных вещах. Мне не интересны видео на 3D плоскостях и игрушки тоже не интересны. Это — другая область, понимаешь? Твои же суждения на эту тему являются крайне поверхностными и дилетантскими, следовательно критерием не являются.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[10]: Многомерные массивы в C# - очередной наезд
Здравствуйте, VladD2, Вы писали:
VD>В общем, забавно беседовать с человеком который не верит ни во что что сам пока не видел. Но я то видел. Авалон валяется у меня на винте. Все в нем шустро и красиво. Описываемых тобой проблем особо незаметно.
VD>Вот погляди статейку Avalon – ноябрьский Community Technical Preview (перевод). Там в конце скриншоты Шарповскоко приложения снятые мной на моей машине в прошлом году. Это все работает со скоростью звука под ХРюшей. Все это чистый 3D. Битмапы только изображения пользователей на кнопках. Даже зеленые кнопочки нарисованы Авалоном. Если тебя такое качество устроет (с поправкой на джипег), то думаю разговор можно закрыть.
просто прибило там ЭТО , как стиль расставляния чего-либо на формочке и заполнения пропитей))))))
VladD2,
> В общем, забавно беседовать с человеком который не верит ни во что что сам пока не видел. Но я то видел. Авалон валяется у меня на винте. Все в нем шустро и красиво. Описываемых тобой проблем особо незаметно.
Артефакты видны невооруженным глазом. Смотреть вокруг рамочки поверх фотографии, вокруг надписи "Type Password", вокруг картинки "Sign in", вокруг фона под дероидом слева внизу и т.п. Вполне возможно, что это артифакты сжатия JPEG, но утверждать о том, что на тех картинках нет проблем, описанных McSeem2, я бы не стал.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[11]: Многомерные массивы в C# - очередной наезд
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Артефакты видны невооруженным глазом. Смотреть вокруг рамочки поверх фотографии, вокруг надписи "Type Password", вокруг картинки "Sign in", вокруг фона под дероидом слева внизу и т.п. Вполне возможно, что это артифакты сжатия JPEG, но утверждать о том, что на тех картинках нет проблем, описанных McSeem2, я бы не стал.
Это именно артефакты JPEG и есть.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
MS>А вот что действительно было бы интересно — так это воспроизвести вот эту картинку MS>http://antigrain.com/demo/aa_test.png на разных продвинутых картах, используя OpenGL или D3D. Исходник здесь: MS>http://antigrain.com/demo/aa_test.cpp.html описание здесь: http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html. Из этого легко сделать на OpenGL или D3D. MS>Пристально посмотреть на качество и оценить, насколько хорошо оно все "поддерживается" на HW уровне. Вот это для меня был бы критерий. Кто-нибудь возьмется за такое? Было бы просто замечательно!
Огромная просьба — позапускайте на всяких-разных акселераторах, чем современнее и навороченнее — тем лучше. Качество, естественно, надо выставить на максимум. Очень интересно посмотреть на картинки, можно прислать мне на mcseem at antigrain dot-com
Можно, конечно, попробовать переписать на D3D, но не думаю, что будет какая-то разница по качеству — алгоритмы-то внитри все одинаковые.
А самое главное, найдите мне видеокарту, которая бы корректно рисовала линии с толщиной, некратной пикселу, особенно, меньше пиксела.
Буду приятно удивлен, если кто-то продемонстрирует достойное качество.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[10]: Многомерные массивы в C# - очередной наезд
VladD2,
> ПК> Опять двадцать пять... Мне все равно, в языке нечто или в библиотеке. Скорее, даже интереснее, если язык позволяет делать подобные вещи самостоятельно, а не ограничивает набором уже встроенных "рюшечек".
> Ну, то-есть спорными слова не были?
Были. Разве я где-то сказал, что не были? Конкретно вот эти слова:
> GZ>На ООП заточены оба языка в разной функциональности.
> Несовсем. Такие вещи как боксинг, интерфейсы, делегат, итераторы и т.п. это все ООП-патерны встроенные в язык. Их нет в С++.
Подробнее: спорной является аргументация большей "заточенности" C# на ООП тем, что в C# перечисленные возможности встроены в язык. Основание: легкость их реализации в C++ в виде библиотек + точно такая же легкость последующего использования.
> ПК>Речь идет не о драйверах. Например, такая задача возникла при связывании встраиваемого языка с C++. А также при разработке ядра этого языка. Ни о каких оптимизациях речь там не шла. > > Что такое "встраиваемого языка" и что не позволяет обходиться без ассемблера?
Язык, функции которого могут вызываться из C++, и который сам может вызывать функции C++. Если соглашения о вызовах в "том" языке не совпадают с соглашениями о вызовах в C++ (а в нашем случае так и было), то организация этих возможностей требует доступа как к стеку, так и к регистрам.
> ПК>Не нужно знание об организации памяти на конкретной платформе, чтобы получить объект, представляющий собой поддиапазон массива. Это даже в Питоне делается.
> К сожалению некоторыми своими правилами Питон заранее определяет свою реализацию. Списки в питоне обязаны быть сслочными и менее эффективными. Так что аналогия с Питоном не уместна.
В общем, обоснований, почему именно без знания организации памяти на конкретной платформе нельзя сделать поддиапазоны, судя по всему, не последует.
> Что же касается подиапазона, то на логическом уровен в этом особой необходимости нет.
Да уж... В таком случае в массивах тоже необходимости нет, достаточно указателя, плюс числа, обозначающего количество элементов. Не смешно, в общем. Может, у тебя в поддиапазонах потребности и не возникает, но это не значит, что это не нужно другим людям.
> ПК> Очень интересно... А как же избежать этих проверок в присутствии возможности приведения массивов к массивам базовых классов?
> 1. В описываемом случае классами (ссылками если быть более точным) и не пахен. Стало быть привдить просто нечего. > 2. В цикле одно и то же приведение, из одной и той же переменной делается сотни миллионов раз. Нет особых проблем вынести такие проверки из цикла. Это его инвариант.
Гм... Дык, это ж только пример. Речь-то идет о более общих проблемах. Если речь идет о примере, то всегда можно отмазаться тем, что можно встроить о нем знание в компилятор.
>
> static void Test(A[] array, A obj1, A obj2)
> {
> int half = array.Length / 2;
> for (int i = 0; i < half; i++)
> array[i] = obj1;
>
> for (int i = half; i < array.Length; i++)
> array[i] = obj2;
> }
> }
>
> Можно смело вынести проверки типов за пределы циклов. Ведь типы ни array, ни obj1, ни obj2 не могут измениться во время работы цикла.
> ПК> Эти ошибки (например, помещение в массив унаследованного класса объектов базового) в C# в run-time вылетают, а не в compile-time.
> Ну, опиши какие теоретические проблемы могут возникнуть в примере выше. Это кстати, один из наиболее часто применимых паттернов.
Я тя умоляю, заполнение массива одним и тем же объектом? Давай-ка лучше переделаем на получение объекта из функции или же копирование из другого массива... И как в этом случае можно будет вынести проверки?
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
MS>>А вот что действительно было бы интересно — так это воспроизвести вот эту картинку MS>>http://antigrain.com/demo/aa_test.png на разных продвинутых картах, используя OpenGL или D3D.
На самом деле и это не является эталоном качества. С более грамотной гамма-коррекцией, учитывающей нелинейность перцептуально-равномерного цветового пространства, должно быть вот так: http://antigrain.com/demo/aa_test2.png
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[10]: Многомерные массивы в C# - очередной наезд
Здравствуйте, VladD2, Вы писали:
VD>К сожалению некоторыми своими правилами Питон заранее определяет свою реализацию. Списки в питоне обязаны быть сслочными и менее эффективными. Так что аналогия с Питоном не уместна.
Для хранения элементов по значению используют module array.
... << RSDN@Home 1.1.4 beta 3 rev. 215>> (WinAmp: Darren Hayes — Insatiable)
Твои линки не открываются. Ты бы выкладывал бы файлы на РСДН-е в разделе "файлы" своего профайла.
MS>Можно, конечно, попробовать переписать на D3D, но не думаю, что будет какая-то разница по качеству — алгоритмы-то внитри все одинаковые.
Вообще-то Кармак намучился с ОпенЖЛ-ем. D3D намног более независим и разные оптимизации скрывает от программиста.
MS>А самое главное, найдите мне видеокарту, которая бы корректно рисовала линии с толщиной, некратной пикселу, особенно, меньше пиксела.
Может тут уже и попраграммировать нужно?
MS>Буду приятно удивлен, если кто-то продемонстрирует достойное качество.
Я не видел что там у тебя, но качества Авалона лично мне выше крыши. Сейчас я и этого не имею (если только в виде имиджей).
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Многомерные массивы в C# - очередной наезд
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Артефакты видны невооруженным глазом. Смотреть вокруг рамочки поверх фотографии, вокруг надписи "Type Password", вокруг картинки "Sign in", вокруг фона под дероидом слева внизу и т.п. Вполне возможно, что это артифакты сжатия JPEG, но утверждать о том, что на тех картинках нет проблем, описанных McSeem2, я бы не стал.
Блин, никак не могу привыкнуть к узким специалистам. Я все время подозреваю, что собеседник с высокими скилами в некоторой области знает столько же сколько и я в остальных.
Здравствуйте, mister-AK, Вы писали:
MA>наверно и код тоже на XAML можно лабать???!!!
Только декларативный. А вообще XAML перед работой превращается в дотнетные классы и работают уже они. Это обесепечивает высокую скорость и интерактивность. ХТМЛ тут и рядом не валялся.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Многомерные массивы в C# - очередной наезд
, как стиль расставляния чего-либо на формочке и заполнения пропитей))))))
