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

M>Понял , но зачем же нам растеризовать "плоский слой" если мы в один проход можем растеризовать все слои ?

Это уже чрезмерная усложнистика. Я пробовал представить, во что это выливается для тесселятора и решил, что это просто кошмарный рак головы.
Но в принципе, попозже можно будет вернуться к этим размышлениями, возможно сейчас я просто морально не готов.

M> с) если кто то из спанов полупрозрачен , комбинируем слои с учетом Z ordering , а это необходимо делать в любом случае.

А вот *где* мы это комбинируем? Надо это делать непосредственно во фрейм-буфере, что фактически эквивалентно просто рисованию.

M>Тогда каждый пиксел вс равно рисуется только один раз.
M>Невидимые полигоны/пикселы не рисуются а просто скипаются.

В принципе, да, такое возможно, но как я уже сказал, только для растеризатора. И лучше все-таки делать color compositing непосредственно в буфере, а scanline устроить многослойным, так, чтобы непрозрачый span автоматически поглощал все низлежащие. Тогда дорогие и ненужные color compositing операции редуцируются.

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

C>А если попробовать и их предвычислить? Определенные виды градиентов можно заранее скомбинировать. Хотя согласен, в общем случае вряд ли получится.

В любом случае, это комбинирование придется выполнять на CPU по-пиксельно. В то время, как самый нормальный способ — это быстро-быстро порубать на треугольники и отдать их на растерзание "треугольно-молотилке". А в этом случае, мы уже имеем дело не с пикселами, а с областями, для которых может и не быть одного сплошного цвета.

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

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

M>>Понял , но зачем же нам растеризовать "плоский слой" если мы в один проход можем растеризовать все слои ?

MS>Это уже чрезмерная усложнистика. Я пробовал представить, во что это выливается для тесселятора и решил, что это просто кошмарный рак головы.
MS>Но в принципе, попозже можно будет вернуться к этим размышлениями, возможно сейчас я просто морально не готов.

Что такое теселятор и зачем он используется я не очень представляю , а растеризатор можно было бы реализовать с одним проходом по всей сцене.

M>> с) если кто то из спанов полупрозрачен , комбинируем слои с учетом Z ordering , а это необходимо делать в любом случае.

MS>А вот *где* мы это комбинируем? Надо это делать непосредственно во фрейм-буфере, что фактически эквивалентно просто рисованию.

Ну зачем фрейм буфере , операции над одним пикселом можем провести локально не используя внешних механизмов и в буфер только результат вставлять.


M>>Тогда каждый пиксел вс равно рисуется только один раз.
M>>Невидимые полигоны/пикселы не рисуются а просто скипаются.

MS>В принципе, да, такое возможно, но как я уже сказал, только для растеризатора. И лучше все-таки делать color compositing непосредственно в буфере, а scanline устроить многослойным, так, чтобы непрозрачый span автоматически поглощал все низлежащие. Тогда дорогие и ненужные color compositing операции редуцируются.

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


Идея понятна, но немного напрягает что во флеш представлении данных есть некоторые ограничения , а может я просто не привык и не работал с compaund path. Но вот меня беспокоит что было 3 круга , а после превращения в compaund path кругов не осталось и мы их теперь переместить с другими наложениями не сможем....

Сложность — ужас , но не ужас ужас. Наверное для общего случая типа SVG это может быть довольно оптимальный метод ?

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

M>Что такое теселятор и зачем он используется я не очень представляю , а растеризатор можно было бы реализовать с одним проходом по всей сцене.

Тесселятор нужен, чтобы порубать всю multistyle shape на треугольники. Растеризация это конечно хорошо, но страшно тормозно.

M>Идея понятна, но немного напрягает что во флеш представлении данных есть некоторые ограничения , а может я просто не привык и не работал с compaund path. Но вот меня беспокоит что было 3 круга , а после превращения в compaund path кругов не осталось и мы их теперь переместить с другими наложениями не сможем....

Именно так. Но выходные данные Flash не предназначены для последующего редактирования, только для отображения. Именно это и позволяет выполнить существенные оптимизации. Впрочем, они в студии сделали совершенно по-дурному. Стоит в редакторе нарисовать внутренний кружочек, а потом его отодвинуть, то он тут же выкусывает во внешнем дыру. Хотя, за счет простоты работы со слоями, эта проблема нивелируется — можно все делать в разныз слоях, а потом объединить их в одну составную фигуру. Но вообще, неудобно ужасно.

M>Сложность — ужас , но не ужас ужас. Наверное для общего случая типа SVG это может быть довольно оптимальный метод ?

Попробуешь? Берется AGG, agg_rasterizer_compound_aa.h, функции render_scanlines_compound и render_scanlines_compound_layered, примеры flash_rasterizer.cpp и rasterizer_compound.cpp

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

M>>Сложность — ужас , но не ужас ужас. Наверное для общего случая типа SVG это может быть довольно оптимальный метод ?

MS>Попробуешь? Берется AGG, agg_rasterizer_compound_aa.h, функции render_scanlines_compound и render_scanlines_compound_layered, примеры flash_rasterizer.cpp и rasterizer_compound.cpp

Руки чешутся конечно , но объем задачи не маленький ... Разве что повезет и на фулл тайм работе что то пересечется с таким заданием. Возможность есть , я счас вокруг ГИС технологий кручусь.

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

M>Руки чешутся конечно , но объем задачи не маленький ... Разве что повезет и на фулл тайм работе что то пересечется с таким заданием. Возможность есть , я счас вокруг ГИС технологий кручусь.

Но только надо иметь в виду, что существенного улучшения производительности все равно не получишь. Как ни крути, а все равно остается софтварная растеризация, которая сама отъедает много времени. Во-вторых, ты фактически хочешь весь SVG файл растеризовать за один проход. Если данных много, то растеризатор может затребовать слишком много памяти — 20 байт на каждый пиксел по перметру всех полигонов. Впрочем, Flash делает full scele anti-aliasing приблизительно таким же способом — накапливает данные вдоль границ для всей сцены.

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

C>Да, и можно ли использовать для контекста WPF _свой_ контекст рисования? Например, сделать на WPF интерфейс для компьютера внутри игры или рисовать WPF на принтер?

Ну Андрей же сказал, что "можно, к примеру, на грань трехмерной фигуры налепить обычные контролы". В качестве частного случая "трехмерной фигуры" можно взять прозрачную плоскость, за которой отрисовывается сцена игры. У нас для всяких HUDs так и делается. Но вообще, да, имеется такое понятие как низкоуровневый рендерер, который всегда тесно интегрирован с конкретным движком и у нас их уже куча, для всяких Gambryo, Unreal и прочих CryEngine. В качестве частных случаев может выступать рендерер, основанный на голом D3D или OpenGL.

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

MS>Конечно есть. Если за одно и то же время можно нарисовать сцену вдвое сложнее, то это эквивалентно увеличению тактовой частоты вдвое.

Видеоакселератор нарисует ту же самую сцену с наложением в сто раз быстрее, нежели наиоптимальнейший софтовый алгоритм.

MS>Нууу, тоже мне рокет саенс.

А кто то утверждал что это рокет саенс?

MS> Это не фейерверк, это полюция. Под нормальным аппаратным ускорением можно подразумевать софтварную триангуляцию и рендеринг внутри видеокарты. Только при таких условиях и FSAA возможно рисование без швов.

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

MS>Именно, что имеет. См. выше, про загрузку текстур.

Это все сказки, не подкрепленные какими либо цифрами. Ты возьми, посчитай, сколько потребуется времени на пересылку по PCI-E текстур для самой навороченной двухмерной сцены. Не забудь про сжатие текстур, кстати.
Если бы все было так печально, как ты тут пытаешься убедить, то в 3D ситуация была бы еще хуже — там перекрытие поверхностей и объем текстур значительно больше, чем у типовых двумерных векторных сцен. Только вот что то не видно софтовых рендереров, способных догнать самый дохлый современный видеоускоритель.
Ты упускаешь один простой момент — оверхед там конечно есть и значительный, только вот на фоне чудовищной производительности видеоускорнителей этот оверхед не играет никакой роли.

MS> При такой технологии, модель данных типа Flash (многоцветных плоских compound paths) сэкономила бы подавляющую долю трафика через шину в случае анимации.

И что? Дался тебе этот трафик? Современное железо с трудом хорошо если загрузит одну-две линии PCI-E, а у видео их 8 или 16 штук в монопольном владении.

MS> Но они используют модель данных, примитивную как каменный топор.

Алгоритмы расчета 3D, применяемые в железе тоже крайне примитивны, особенно до появления шейдеров. Железо однако, там особо не размахнешься. Но за счет аппаратуры неэффективные алгоритмы, вроде того же Z-буффера, который тебя так пугает, в итоге оказываются ближе к оптимуму, нежели сверххитрые алгоритмы отсечения невидимых поверхностей.

MS>Ну и потом — а что можно делать с этими текстурами внутри видеокарты? — масштабировать нельзя

Можно.

MS>, вращать тоже нельзя

Можно.

MS>, ибо чревато потерей четкости

А так и происходит.

MS>. Можно только двигать, причем с дискретностью ровно в пиксел.

Давно уже видеоускорители с плавучкой работают.

MS> А если надо подвинуть на пол-пиксела или чуть смасштабировать, извольте растеризовать по-новой.

Зачем?

MS> А сколько видеопамяти при этом займет даже простейшая сцена?

Заметно менше типовых 256-512 мег. Тебе жалко?

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

C>Это, на самом деле, весьма бесполезная вещь.

Это конечно. Но в качестве демонстрации возможностей ...

C>Я имел в виду немного другое — можно ли в контекст WPF встраивать контексты рендеринга, например, для OpenGL? Или хотя бы использовать контрол в качестве поверхности для DX?

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

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

C>>Да, и можно ли использовать для контекста WPF _свой_ контекст рисования? Например, сделать на WPF интерфейс для компьютера внутри игры или рисовать WPF на принтер?
MS>Ну Андрей же сказал, что "можно, к примеру, на грань трехмерной фигуры налепить обычные контролы". В качестве частного случая "трехмерной фигуры" можно взять прозрачную плоскость, за которой отрисовывается сцена игры.
Хотелось бы уметь делать хотя бы свою реализацию фрейм-буффера. Я помню, что мне с OGL для полиграфического качества приходилось рендерить картинку тайлами. Так как в память видеокарты не влазил весь буффер.

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

MS>Флоаты имеют 7 десятичных значащих цифр вне зависимости от порядка. Ну пусть мы огрубим и возьмем 6. Уж 6 достоверных десятичных цифр мы точно имеем. 1200dpi * 10" = 12000, то есть необходимы 5 значащих цифр для представления координат с точностью до пиксела (на самом деле, ближе к четырем). Значит в 6 значащих цифрах мы можем представить координаты с точностью в 0.1 пиксела. Десятикнратный зум должен обеспечивать точность в пиксел и только на стократном точности явно не хватит. В принципе, для прецизионной картографии точности флоатов реально не хватает.
У меня еще не идентичная матрица преобразования использовалась (поворот на 45 градусов). Артефакты появлялись еще из-за того, что регулярные структуры при отображении на решетку пикселей давали глюки. Приходилось искать такое преобразование, при котором такие глючки были минимальны.

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

AVK>Видеоакселератор нарисует ту же самую сцену с наложением в сто раз быстрее, нежели наиоптимальнейший софтовый алгоритм.

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

AVK>А это уже пофигу что ты там себе подразумеваешь под нормальным аппаратным ускорением. Главное что, то, что имеется, полностью устраняет какой либо оверхед по отрисовке невидимых частей.

Дело в том, что видеоадаптер умеет делать гораздо больше, чем альфа-блендинг текстур. Я подразумеваю именно то, что есть на самом деле, а не рекламнымные байки про аппаратное ускорение, которыми Микрософт кормит народ.

AVK>Это все сказки, не подкрепленные какими либо цифрами. Ты возьми, посчитай, сколько потребуется времени на пересылку по PCI-E текстур для самой навороченной двухмерной сцены. Не забудь про сжатие текстур, кстати.

Сжатие надо выполнять опять же на CPU. Это еще один тормоз.

AVK>Если бы все было так печально, как ты тут пытаешься убедить, то в 3D ситуация была бы еще хуже — там перекрытие поверхностей и объем текстур значительно больше, чем у типовых двумерных векторных сцен. Только вот что то не видно софтовых рендереров, способных догнать самый дохлый современный видеоускоритель.

Андрей, ну ткни пальцем, где в этой ветке я агитирую за софтовый рендерер. У меня стойкое ощущение, что это происходит только у тебя в мозгу. Еще раз: я как раз и говорю о том, что растеризовать треугольники аппаратно — это гораздо эффективней, чем выполнять софтварную растеризацию и гнать текстуры. Не беспокойся на счет цифр — мы проверяли, с компрессией и без, во всевозможных позах. Что характерно, в клинических случаях софтварная растеризация действительно оказывается выгоднее. Но число таких случаев исчезающе мало и их можно легко распознать. Так что идеальным является комбинация из триангуляции и софтварной растеризации с некой логикой по принятию решения.

AVK>Ты упускаешь один простой момент — оверхед там конечно есть и значительный, только вот на фоне чудовищной производительности видеоускорнителей этот оверхед не играет никакой роли.

Растеризация в WPF все равно происходит софтварно, period. КЦ очень дорогое, родной. Все прочее после этого несущественно.

MS>> А если надо подвинуть на пол-пиксела или чуть смасштабировать, извольте растеризовать по-новой.

AVK>Зачем?

Просто таковы законы природы — информация при растеризации неизбежно теряется, так же, как и при дискретизации аналогового сигнала. См. теорему Котельникова-Шеннона. Если ты нарисуешь вертикальную линию толщиной ровно в пиксел, но попадающую в точности между пикселов, то она в результате анти-алиасинга будет размыта на два пиксела. Если теперь сместить систему координат на пол-пиксела вправо, и растеризовать по-новой, то линия станет четкой. Если сдвинуть на те же пол-пиксела готовую текстуру с линейным фильтром (да и вообще, любым фильтром), то та же линия, вместо того, чтобы стать четкой, расползется на четыре пиксела и станет еще более блеклой.

MS>> А сколько видеопамяти при этом займет даже простейшая сцена?

AVK>Заметно менше типовых 256-512 мег. Тебе жалко?

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

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

AVK>>Видеоакселератор нарисует ту же самую сцену с наложением в сто раз быстрее, нежели наиоптимальнейший софтовый алгоритм.

MS>Здесь ты уже явно передергиваешь. В данном контексте речь шла исключительно о хардварном рендеринге

MS>Я несколько не о том. Не о формате данных, а о принципах организации данных. SVG и SL предполагают рисование сцены слой за слоем, многократно перезакрашивая по одному и тому же месту. В случае сложной анимации это становится очень медленно.

В случае SL этим перезакрашиванием (с использованием Z-буфера и альфаблендинга) должен заниматься видеоакселератор.

Так что передергивает и меняет тему кто то другой. И следовать за твоими изменениями контекстов я не собираюсь, потому что иначе идиотизм выходит.

AVK>>Это все сказки, не подкрепленные какими либо цифрами. Ты возьми, посчитай, сколько потребуется времени на пересылку по PCI-E текстур для самой навороченной двухмерной сцены. Не забудь про сжатие текстур, кстати.

MS>Сжатие надо выполнять опять же на CPU. Это еще один тормоз.

Для современных CPU это семечки.

MS>Еще раз: я как раз и говорю о том, что растеризовать треугольники аппаратно — это гораздо эффективней, чем выполнять софтварную растеризацию и гнать текстуры.

Здорово. Какое это имеет отношение к формату данных флеша?

MS>Растеризация в WPF все равно происходит софтварно, period.

Ну кое что (навроде градиента) они все таки растеризуют шейдерами. Но с ними уже все совсем не так просто и не всегда шейдер быстрее выполнять в видеокарте. Особенно если учесть, что ноги SL растут из WPF, а WPF затачивался не столько под хитрую анимацию, сколько под отрисовку UI, а там, как ты понимаешь, проблемы с растеризацией разве что шрифтов, а их при любом раскладе софтово растеризовать придется.
Но тут, кстати, есть еще один забавный момент — растеризатор у WPF асинхронный, следовательно, при наличии свободного ядра, с учетом современных реалий, как бы софтовая растеризация сложных примитивов не оказалась на современном железе в итоге быстрее. Все это вопрос баланса и далеко не факт, что WPF в эту сторону двигаться не будет. Главное, МС сделал то, что кроме него мало кто мог сделать, полностью сменил платформу UI, а растеризатор, при желании, можно и свой подключить. И SL тоже тем и хорош, что прежде всего несет набор стандартов. А плагин для линукса, глядишь, линуксоиды и сами напишут.

AVK>>Заметно менше типовых 256-512 мег. Тебе жалко?

MS>Это означает, что имеется принципиальное ограничение на сложность сцены, неужели непонятно?

Оно всегда имеется. Хотя бы ввиду доступной оперативной памяти или максимально допустимого времени рендеринга. Я не могу представить себе двумерную сцену экранного разрешения, которой бы не хватило 256М.

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

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

MS> Получается очередная детская игрушка, неспособная справиться с серьезной нагрузкой.

GDI на ста тысячах элементов ласты откинет. Тоже детская игрушка?

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

AVK>

MS>Я несколько не о том. Не о формате данных, а о принципах организации данных. SVG и SL предполагают рисование сцены слой за слоем, многократно перезакрашивая по одному и тому же месту. В случае сложной анимации это становится очень медленно.

AVK>В случае SL этим перезакрашиванием (с использованием Z-буфера и альфаблендинга) должен заниматься видеоакселератор.

AVK>Так что передергивает и меняет тему кто то другой. И следовать за твоими изменениями контекстов я не собираюсь, потому что иначе идиотизм выходит.

Еще раз. В модели данных Flash сцены *уже* плоские, понимаешь? Слоев там мало. В SVG и SL все состоит из слоев и их очень много. Фактически, каждый полигон — отдельный слой. И другого не дано, поскольку рисование плоской сцены в SL (со смежными, а не перекрывающимися полигонами) чревато наличием видимых швов. Отрисовка же плоской сцены завсегда эффективнее, вне зависимости от метода. Используется там Z-буфет или нет уже не важно, нам все равно необходимо перемалывать эти данные так или иначе. Z-буфер тоже небесплатный. На примере всем известного тигра (68K треугольников), отрисовка плоской многоцветной сетки работает примерно вдвое быстрее, чем отрисовка множества слоев с Z-буфером. При этом, количество треугольников остается примерно таким же, просто в первом случае они все смежные, а во втором — перекрываются с коэффициентом значительно больше половины всей площади. С тупым перекрашиванием еще несколько медленнее, но несущественно. Я утверждаю (проверено), что во-первых, триангулировать и рендерить треугольники гораздо эффективнее, чем использовать софтварный растеризатор и текстуры (за исключением редких клинических случаев), во-вторых, что рисовать сцену, имеющую плоскую геометрию гораздо эффективнее, чем выполнять это "уплощение" на лету. Вне зависимости от метода — софтварный, хардварный, с Z-буфером или без — не важно. Если сцена плоская, то это значит, что уже проделана существенная часть работы.

Ну и еще раз напомню про побочный эффект — есть случаи, где только плоская сцена и возможна, например, после векторизации фотографий. Корректно отобразить ее ни в SVG, ни в SL не получается из за наличия швов между смежными полигонами.

MS>>Сжатие надо выполнять опять же на CPU. Это еще один тормоз.
AVK>Для современных CPU это семечки.

Предполагаю, что сравнимо с временем растеризации. Возможно, даже существенно дольше. Но это и не важно, достаточно того, что растеризация сама по себе является дорогой операцией.

MS>>Растеризация в WPF все равно происходит софтварно, period.
AVK>Ну кое что (навроде градиента) они все таки растеризуют шейдерами.

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

AVK>100 тыс полигонов это не проблема (хотя не понимаю зачем одновременно отображать все 100 тысяч, адаптивной деградации никто не отменял). Вот несколько десятков миллионов, это да, это уже проблема. Но в разумность такого требования поверить сложно.

Если каждая текстура будет размером хотя бы в 1 килобайт, то это уже 100 мег. А на практике они бывают во много раз больше.

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

C>MS собирается выпустить кросс-платформенный CLR (но не OpenSource) для поддержки своего DLR (Dynamic Language Runtime) и Silverlight:
C>http://blogs.zdnet.com/microsoft/?p=414

Странная кросс-платформенность — работать она будет только на "интельных" маках

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

MS>Еще раз. В модели данных Flash сцены *уже* плоские, понимаешь?

Понимаю.

MS> Слоев там мало. В SVG и SL все состоит из слоев и их очень много.

Для SL это оправдано.

MS> Фактически, каждый полигон — отдельный слой.

Я в курсе.

MS> И другого не дано, поскольку рисование плоской сцены в SL (со смежными, а не перекрывающимися полигонами) чревато наличием видимых швов.

Ну да, если конечно швы поверх не залепить. Т.е. можно сделать ровно 2 слоя — каркас и заливка.

MS> Отрисовка же плоской сцены завсегда эффективнее, вне зависимости от метода.

Понимаешь, вот, безусловно, сцена c FSAA заведомо, вне зависимости от метода, менее эффективна, чем сцена с онным. Однако на современных видеокарточках FSAA до определенной степени бесплатен. Это первое. Второе — отрисовка полигонов с перекрытиями и блендингом, это как раз то, подо что заточено железо. Третье — формат SL пришел из взрослого WPF, а там предварительный пересчет, в отличие от флеша, не возможен в принципе.

MS> Используется там Z-буфет или нет уже не важно

Важно. Потому что Z-буфер реализован аппаратно. И аппаратный блендинг реализован с его помощью. Любой другой способ в лучшем случае удастся реализовать на шейдерах, а в худшем придется вобще отказаться от железной поддержки.

MS>Предполагаю, что сравнимо с временем растеризации. Возможно, даже существенно дольше.

Вряд ли. Алгоритм там сверхпримитивный.

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

К>Странная кросс-платформенность — работать она будет только на "интельных" маках

А зачем МС поддерживать устаревшую платформу?

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

AVK>Понимаешь, вот, безусловно, сцена c FSAA заведомо, вне зависимости от метода, менее эффективна, чем сцена с онным. Однако на современных видеокарточках FSAA до определенной степени бесплатен.

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

AVK>Второе — отрисовка полигонов с перекрытиями и блендингом, это как раз то, подо что заточено железо.

Железо заточено под рисование треугольников. Рисовать произвольные полигоны оно в принципе не умеет.

MS>> Используется там Z-буфет или нет уже не важно

AVK>Важно. Потому что Z-буфер реализован аппаратно. И аппаратный блендинг реализован с его помощью. Любой другой способ в лучшем случае удастся реализовать на шейдерах, а в худшем придется вобще отказаться от железной поддержки.

Ты ошибаешься. Z-буфер работает не так. Операции с ним выполняются до каких-либо манипуляций с цветами или альфами. То есть, он знать не знает ни о каких цветах в текструре. Это значит, что если выполняется софтварная растеризация и наложение текстуры, то задействовать Z-буфер нельзя, потому что операции с ним будут "выкусывать" целый прямоугольник, охватывающий текстуру, невзирая на содержимое этой текстуры. По-другому он просто не умеет работать. Z-буфер работает только с честной треугольной сеткой.

Короче, я выяснил, что в SL никакой Direct3D не используется. Все растеризуется и блендится чисто софтварно. И у меня есть большие сомнения, что полноценный WPF использует хоть что-то из аппаратного ускорения. Но хотелось бы выяснить это со 100% достоверностью, например, посмотреть тем же D3DSpy.

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

C>MS собирается выпустить кросс-платформенный CLR (но не OpenSource) для поддержки своего DLR (Dynamic Language Runtime) и Silverlight:
C>http://blogs.zdnet.com/microsoft/?p=414
C>Интресно, как быстро у них в Виндовой версии будут появляться фичи, которых нет в линуксовой версии?
Кстати, был вчера на встрече группы .NET, там Гайдар Магдануров сказал, что MS будет предоставлять сервис Silverlight Streaming в рамках системы сервисов live.com.

Вот URL: http://silverlight.live.com/ — потестируйте хоть кто-нибудь, у меня SL мой FireFox заваливает

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

C>Кстати, был вчера на встрече группы .NET, там Гайдар Магдануров сказал, что MS будет предоставлять сервис Silverlight Streaming в рамках системы сервисов live.com.

C>Вот URL: http://silverlight.live.com/ — потестируйте хоть кто-нибудь, у меня SL мой FireFox заваливает

У меня стриминг на страницу скачивания перекидывает, устанавливаю, ничего не меняется, захожу снова — тоже самое, глюки, какие-то...
(у меня тоже фокс)