Silverligth + cross-platform CLR - Философия программирования

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

Сегодня прислали ссылку по этой теме как раз...

http://blogs.msdn.com/hugunin/archive/2007/04/30/a-dynamic-language-runtime-dlr.aspx

A Dynamic Language Runtime (DLR)

Today, at MIX 07, we announced a new level of support for dynamic languages on .NET that we're calling the DLR.

From the beginning, Microsoft's .NET framework was designed to support a broad range of different programming languages on a Common Language Runtime (CLR). The CLR provides shared services to these languages ranging from a world-class GC and JIT to a sandboxed security model to tools integration for debugging and profiling. Sharing these features has two huge benefits for languages on the CLR. First, it's easier to implement a language because lots of difficult engineering work is already done for you. Second, and more importantly, these languages can seamlessly work together and share libraries and frameworks so that each language can build on the work of the others.

The CLR has good support for dynamic languages today. IronPython-1.0 demonstrates this. The new Dynamic Language Runtime (DLR) adds a small set of key features to the CLR to make it dramatically better. It adds to the platform a set of services designed explicitly for the needs of dynamic languages. These include a shared dynamic type system, standard hosting model and support to make it easy to generate fast dynamic code. With these additional features it becomes dramatically easier to build high-quality dynamic language implementations on .NET. More importantly, these features enable all of the dynamic languages which use the DLR to freely share code with other dynamic languages as well as with the existing powerful static languages on the platform such as VB.NET and C#.

The DLR is about giving you the best experience for your language — true to the language, excellent tools, performance and seamless integration with a wealth of libraries and platforms. The essential benefits of the DLR are about sharing. It lets language implementers share standard features rather than rebuilding them from scratch. This lets them focus on the features that make a given language unique rather than on reinventing yet another GC system. It lets developers share code regardless of the language the code is implemented in and to use whatever language they prefer regardless of the language preferred by the environment they want to run in. Coupled with the Silverlight 1.1 platform announced today, it even lets languages share a sandboxed security model and browser integration. This means that developers building browser-based applications can now use their preferred language even for client-side code.

We're initially building four languages on top of the DLR — Python, JavaScript (EcmaScript 3.0), Visual Basic and Ruby. We shipped today both Python and JavaScript as part of the Silverlight 1.1alpha1 release today. John Lam and I will be demoing all four languages, including VB and Ruby, working together during our talk tomorrow at 11:45.

In addition to the Silverlight release, we've also made the full source code for both IronPython and all of the new DLR platform code available on codeplex under the BSD-style Microsoft Permissive License. All of that code can be downloaded today as part of the IronPython project at codeplex.com/ironpython. If you want to know more about the DLR, you should feel free to download the code. However, you should understand that this is a very early release of these bits and we still have significant work left to do including refactoring, design changes, performance tuning — not to mention documentation.

For the short term, our focus is on using a small number of languages to drive the first wave of DLR development where we can work closely and face-to-face with the developers in order to iron out the worst kinks in the DLR design. After this initial phase, we want to reach out to the broader language community. If you're building a language on top of .NET and are interested in supporting dynamic language features then we want your feedback on the DLR. However, I'd discourage you from trying to implement on top of the DLR today. I don't want you to get frustrated trying to work with these really early bits and then not be interested in working with us when we're better prepared to engage with the language community. We plan to kick off a broader engagement with language implementers at the upcoming lang.net conference in three months — at the end of July. This will be the best place to really engage with the DLR and let us know what we got wrong.

In the meantime, I'll be using this blog to post our design notes for the DLR as they're written and any feedback you have on the design is welcomed. Tomorrow I'll talk more about the shared dynamic type system and the "One True Object".

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

V>The CLR has good support for dynamic languages today. IronPython-1.0 demonstrates this.

Интересно, эти пиарщики вообще IronPython смотрели? Он скорее демонстрация того, что ЦЛР весьма фигово поддерживает динамические языки. И то что динамические языки просто не вписываются в идеологию ЦЛР. Тот же Питон реально толко потребитель (коньсюмер). Делать на нем сборки для использования из других языков просто нельзя.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

V>>The CLR has good support for dynamic languages today. IronPython-1.0 demonstrates this.

VD>Интересно, эти пиарщики вообще IronPython смотрели? Он скорее демонстрация того, что ЦЛР весьма фигово поддерживает динамические языки. И то что динамические языки просто не вписываются в идеологию ЦЛР. Тот же Питон реально толко потребитель (коньсюмер). Делать на нем сборки для использования из других языков просто нельзя.

1. Можно делать DLL странной структуры (вот только как их использовать из других языков? — может кто знает)
2. Можно сабклассить родные класссы.

Можно писать небольшие обертки для взаимодействия с другими языками на C# вот, например полный исходный текст лоадера плагинов для Far.Net:

using FarManager;
using System.Reflection;
using System.Collections;
using System.Collections.Generic;
using System.IO;
using IronPython.Hosting;
using IronPython.Modules;
public class IronPythonLoader : BasePlugin
{
    protected string PluginFile(string name)
    {
           FileInfo fi=new FileInfo(Assembly.GetExecutingAssembly().Location);
           return fi.Directory.Parent.FullName+"\\"+name;
    }
    protected void LoadScript(string fileName)
    {
        PythonEngine engine = new PythonEngine();
        engine.AddToPath(Path.GetDirectoryName(fileName));
        engine.Import("site");        
        ClrModule clr =  (ClrModule)engine.Import("clr");

        
        EngineModule engineModule = engine.CreateModule("__main__", false);
        engine.DefaultModule = engineModule;

        clr.AddReferenceByPartialName("FarNetIntf");
        engine.Import("FarManager");
        engine.Globals["far"] = Far;
        engine.ExecuteFile(fileName);
    }
    override public void Connect()
    {
        string scriptsFolder = PluginFile("Scripts");
        foreach(FileInfo file in new DirectoryInfo(scriptsFolder).GetFiles())
            LoadScript(file.FullName);
    }
}

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

А вот ещё мнение о том, что кроссплатфроменность противоречит интересам МС (кстати, это пересекается с твоим замечанием

)

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

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

Кстати, было бы идеальным местом для Максимовского AntiGrain.

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

К>А вот ещё мнение о том, что кроссплатфроменность противоречит интересам МС (кстати, это пересекается с твоим замечанием

)

Я вот уверен в обратном.
Тут нужно подходить с точки зрения экономики. С этой точки зрения существуют только рынки (рыночные ниши). И если МС не создает продукт для некоторой ОС, то это всего лишь означает, что она упускает эту рыночную нишу.

Если бы ингнорирование данной ниши привело бы к уничтожению ниши, то може МС и была бы от этого выгода. Но по факту мы наблюдаем совершенно другое. Люди просто выбираеют технолонии от других производителей (в том числе ОпенСорсные).

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

Этот рынок уже создал вокруг себя инфраструктуру. Люди изучили разные ПХП, (в лучшем случае) Явы. МС тут пролетает мимо кассы.

Содздав кросплатформный ЦЛР МС сразу получает множество бенефитов:
1. Вторгается в новый для нее рынок.
2. Создает конкуреницию ОпенСорсу, Сану и IBM-у на этом рынке.
3. Пропагандирует свои технологии во "аражденбном" лагере.
4. Снимает психологическое ограничение зависимости от одной платформы.
5. Нарывает большое количество аппоратных платформ.
6. И наконец, может использовать ЦЛР в качестве замены скриптам на клиенстких машинах.

МС ничего не теряет перенося ЦЛР на другие платформы. Ведь сила МС в прикладных продуктах и самой ОС. Даже средства разработки останутся под Виндовс. Так что скорее некоторые приверженцы Линукса и/или ОпенСорс начнут лучше относиться к Виндвс, чем Виндвос потеряет популярность.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Содздав кросплатформный ЦЛР МС сразу получает множество бенефитов:
VD>1. Вторгается в новый для нее рынок.
VD>2. Создает конкуреницию ОпенСорсу, Сану и IBM-у на этом рынке.
VD>3. Пропагандирует свои технологии во "аражденбном" лагере.
VD>4. Снимает психологическое ограничение зависимости от одной платформы.
VD>5. Нарывает большое количество аппоратных платформ.
VD>6. И наконец, может использовать ЦЛР в качестве замены скриптам на клиенстких машинах.

Звучит правдоподобно, но на странице закачки нет инсталлятора под Linux и FreeBSD.
И 9 из 10, что не появится. В лучшем случае GNU'шники сами запарятся на ещё одно безнадёжное дело.

now playing: Spor — Insecticide

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

C>Из хороших новстей — Мигель де Иказа пообещал, что Silverlight будет сделан в Mono в течение года (польностью в OpenSource, насколько я понял).

C>Кстати, было бы идеальным местом для Максимовского AntiGrain.

У нас был с ним по этому поводу разговор, но как-то завял на время. Не все так просто. Вопрос лицензирования очень важен. Мне пришлось сменить лицензию на GPL (потому что достали — ходют и ходют). Я, конечно же готов предоставить самые либеральные условия для задействования AGG в Mono, но не знаю, можно ли так сделать — что в составе Mono лицензия более либеральна, чем GPL, хотя сами исходники AGG остаются под GPL (Моновцы не могут использовать GPL). То есть, нужно некое специальное соглашение, типа AGG в составе Mono распространяется под лицензией Mono, но в случае отчуждения автоматически становится GPL, точно так же, как если бы библиотека была взята непосредственно с antigrain.com. Вроде бы никаких противоречий здесь нет, но надо сформулировать соглашение и проверить его юристами. Здесь много подводных камней, например, ни в коем случае нельзя допускать, чтобы я нес хоть какую-то ответственность за potential patent infringing. Если Мигель готов составить такое соглашение и оплатить тщательную проверку моим юристом, то пожалуйста — пусть задейстуют на здоровье совершенно бесплатно. Но сам я не горазд заниматься всеми этими юридическими вопросами (потому что в этой "лоерской-блиннах" Америке это все не просто, а очень непросто), а Мигель пока что молчит.

Здесь так же много и технических проблем, в основном то, что сам формат графических данных страшно устарел по сравнению с Flash. Формат SL — это по сути SVG. Он простой и очевидный, но страшно неэффективный.

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

VD>Я вот уверен в обратном.
VD>Тут нужно подходить с точки зрения экономики. С этой точки зрения существуют только рынки (рыночные ниши). И если МС не создает продукт для некоторой ОС, то это всего лишь означает, что она упускает эту рыночную нишу.

Вот только продукты МС это прежде всего Офис и, в меньшей степени, Windows. Девелоперское подразделение дохода не приносит и служит исключительно для проталкивания Windows.

VD>МС может думать что хочет, но есть рынок массового, дешевого хостинга где МС практически не присуствует, а Линукс и Фришка чувствуют в нем себя просто замечательно.

Отлично. Но как этому горю может помочь кроссплатформенный SL?

VD>1. Вторгается в новый для нее рынок.

Рынка нет никакого — SL не стоит ничего. А средства разработки, как я уже сказал, дохода не приносят.

... << RSDN@Home 1.2.0 alpha rev. 675>>

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

MS>... Мне пришлось сменить лицензию на GPL (потому что достали — ходют и ходют).
Печальное событие. А можешь подробнее прокомментировать, почему было принято такое решение?

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

AVK>Вот только продукты МС это прежде всего Офис и, в меньшей степени, Windows.

Это огромное заблуждение. МС делает лвиную долю денег на Виндовс. Офис им нужен только для удержания клиентов у своей ОС.

AVK>Девелоперское подразделение дохода не приносит и служит исключительно для проталкивания Windows.

Именно.

AVK>Отлично. Но как этому горю может помочь кроссплатформенный SL?

Кросплатформынй CLR? Об этом и говорилось в предыдущем сообщении.

VD>>1. Вторгается в новый для нее рынок.

AVK>Рынка нет никакого — SL не стоит ничего. А средства разработки, как я уже сказал, дохода не приносят.

Рынок есть. Рынок дешевого хостинга и вообще серверных приложений. Тут надо просто смотреть глучже. Деньги не всегда приходят прямыми путями. Иногда речь идет о долговренменных стратегических решения.

ЗЫ

Экономика вообще сложная вещь. В ней многое не очевидно.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

AVK>>Вот только продукты МС это прежде всего Офис и, в меньшей степени, Windows.

VD>Это огромное заблуждение. МС делает лвиную долю денег на Виндовс.

Это факт. Информация общедоступна, можешь поизучать.

AVK>>Отлично. Но как этому горю может помочь кроссплатформенный SL?

VD>Кросплатформынй CLR? Об этом и говорилось в предыдущем сообщении.

Я, честно говоря, так и не увидел ответа.

AVK>>Рынка нет никакого — SL не стоит ничего. А средства разработки, как я уже сказал, дохода не приносят.

VD>Рынок есть. Рынок дешевого хостинга и вообще серверных приложений.

МС хостингом не занимается и заниматься не будет.

VD> Тут надо просто смотреть глучже. Деньги не всегда приходят прямыми путями. Иногда речь идет о долговренменных стратегических решения.

Пока что я не вижу, какое отношение SL имеет к хостингу, и какими хитрыми путями от кроссплатформенности SL будут МС деньги.

... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>

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

MS>>... Мне пришлось сменить лицензию на GPL (потому что достали — ходют и ходют).
SO>Печальное событие. А можешь подробнее прокомментировать, почему было принято такое решение?

Просто были прецеденты unfair use. Почему-то сложился такой стереотип, что BSD-like лицензии — это полная и абсолютная халява. А вот GPL имеет длинный и грозный текст. Но печалится нечего, поскольку я предоставляю лицензии и другого типа, в том числе может быть free commercial license. Но это все определяется индивидуально. Проблема возникает только в случае с Open Source с лицензией, более либеральной, чем GPL. Но этим пришлось пожертвовать.

Забыл упомянуть, что версия 2.4 как была выпущена, так и остается под BSD, так что пользуйтесь на здоровье. Посто более новые версии будут под GPL.

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

AVK>Это факт. Информация общедоступна, можешь поизучать.

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

VD>>Кросплатформынй CLR? Об этом и говорилось в предыдущем сообщении.

AVK>Я, честно говоря, так и не увидел ответа.

Скорее не захотел увидить. Лучше объснить я не смогу.

AVK>МС хостингом не занимается и заниматься не будет.

МС играет на рынке серверов. Хостинг — это ниша на этом рынке. Эту нишу МС благополучно слил. Так что любой ход на этом рынке на руку МС.

AVK>Пока что я не вижу, какое отношение SL имеет к хостингу, и какими хитрыми путями от кроссплатформенности SL будут МС деньги.

Ну, лично я вижу. Возможно дело в знании экономики, а возможно в разных взглядах на жизнь.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

MS>Просто были прецеденты unfair use. Почему-то сложился такой стереотип, что BSD-like лицензии — это полная и абсолютная халява.

Дык BSD и есть полное "фри" при условии соблюдения авторских прав, которые выражаются в коментариях, что этот код основан на чьей-то работе.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Дык BSD и есть полное "фри" при условии соблюдения авторских прав, которые выражаются в коментариях, что этот код основан на чьей-то работе.

Я имею в виду, что некоторые думают, что если лицензия BSD или что-то подобное, то даже соблюдения авторских прав не требуется, хотя в тексте это четко и недвусмысленно сказано. А вот GPL эти некоторые опасаются нарушать. В силу некоторых причин не буду называть конкретных имен, но речь идет не об MS. К MS у меня как раз никаких претензий нету — они задействовали AGG во Flight Simulator X с полным соблюдением условий лицензии и даже больше того — Адам Зофран "пиарил" AGG на GDC 2006 и в своей статье про global terrain generation.

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

MS>Забыл упомянуть, что версия 2.4 как была выпущена, так и остается под BSD, так что пользуйтесь на здоровье. Посто более новые версии будут под GPL.
Идея понятна. Спасибо за развернутый ответ.

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

C>>Кстати, было бы идеальным местом для Максимовского AntiGrain.
MS>У нас был с ним по этому поводу разговор, но как-то завял на время. Не все так просто. Вопрос лицензирования очень важен. Мне пришлось сменить лицензию на GPL (потому что достали — ходют и ходют). Я, конечно же готов предоставить самые либеральные условия для задействования AGG в Mono, но не знаю, можно ли так сделать — что в составе Mono лицензия более либеральна, чем GPL, хотя сами исходники AGG остаются под GPL (Моновцы не могут использовать GPL).
Ты можешь дать "специальное разрешение", лицензия в принципе это позволяет.

А почему ты решил не LGPL заюзать? А то я уже хотел использовать в своем проекте

MS>Здесь так же много и технических проблем, в основном то, что сам формат графических данных страшно устарел по сравнению с Flash. Формат SL — это по сути SVG. Он простой и очевидный, но страшно неэффективный.
Сам по себе формат, ИМХО, не так важен — все равно в какой-то промежуточный код придется переводить.

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

AVK>>Это факт. Информация общедоступна, можешь поизучать.

VD>Если у тебя есть другая информация, приводи ссылки.

Какая другая? Та самая? Ссылок не могу привести, видел сии цифры на презентации, на Платформе.

AVK>>МС хостингом не занимается и заниматься не будет.

VD>МС играет на рынке серверов.

Играет.

VD> Хостинг — это ниша на этом рынке. Эту нишу МС благополучно слил. Так что любой ход на этом рынке на руку МС.

Вот теперь объясни — как кроссплатформенная клиентская технология может повлиять на рынок серверных ОС?

VD>Ну, лично я вижу.

Убедительно.

... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>

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

C>Ты можешь дать "специальное разрешение", лицензия в принципе это позволяет.

Хорошо, осталось только сочинить.

C>А почему ты решил не LGPL заюзать? А то я уже хотел использовать в своем проекте

Задействуй AGG 2.4, он ничем не отличается от 2.5 кроме лицензии. А когда я выпущу более новую версию и возникнет реальная необходимось перехода на нее, мы придумает другое решение.

MS>>Здесь так же много и технических проблем, в основном то, что сам формат графических данных страшно устарел по сравнению с Flash. Формат SL — это по сути SVG. Он простой и очевидный, но страшно неэффективный.
C>Сам по себе формат, ИМХО, не так важен — все равно в какой-то промежуточный код придется переводить.

Я несколько не о том. Не о формате данных, а о принципах организации данных. SVG и SL предполагают рисование сцены слой за слоем, многократно перезакрашивая по одному и тому же месту. В случае сложной анимации это становится очень медленно. Flash "уплощает" геометрию и использует спепциальную модель данных для этого. Это уплощение выполняется при создании файла, поскольку является довольно дорогой операцией. В run-time этого лучше не делать.
http://antigrain.com/stuff/compound_paths.png

Теоретически, модель данных SVG/SL позволяет представлять плоскую многоцветную сцену, но при этом сразу же возникает проблема "сшивания ребер" (edge stitching). С моделью данных Flash у меня есть хотя бы принципиальная возможность рисования без швов, а с SVG/SL такой возможности нет, поскольку нет информации о смежности. В данных Flash нет полигонов как таковых. Там просто набор ребер, каждому из которых присвоено два стиля закраски — слева и справа от ребра. Все ребра в совокупности образуют замкнутый и непротиворечивый граф. Поэтому я знаю, какое ребро с какими областями контачит и могу нарисовать сцену без швов. На SVG/FL у меня такой информации нет. Правильно можно нарисовать только с использованием FSAA, ну или использовать традиционным layered способом с многогратной перезакраской. Кстати, layered scene не всегда возможно обеспечить. Например, при векторизации фотографий, см, например Vector Eye — модель данных Flash для этого гораздо лучше подходит.

... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>

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

C>>Ты можешь дать "специальное разрешение", лицензия в принципе это позволяет.
MS>Хорошо, осталось только сочинить.
Посмотри на libstdc++ — оно под тоже GPL, но со специальным разрешением.

C>>А почему ты решил не LGPL заюзать? А то я уже хотел использовать в своем проекте

MS>Задействуй AGG 2.4, он ничем не отличается от 2.5 кроме лицензии. А когда я выпущу более новую версию и возникнет реальная необходимось перехода на нее, мы придумает другое решение.
Надеюсь, что будет что-нибудь менее ограничивающее, чем GPL. Просто с ним уж совсем ничего не получается сделать

MS>Я несколько не о том. Не о формате данных, а о принципах организации данных. SVG и SL предполагают рисование сцены слой за слоем, многократно перезакрашивая по одному и тому же месту. В случае сложной анимации это становится очень медленно. Flash "уплощает" геометрию и использует спепциальную модель данных для этого. Это уплощение выполняется при создании файла, поскольку является довольно дорогой операцией. В run-time этого лучше не делать.
MS>http://antigrain.com/stuff/compound_paths.png
Ну как AVK сказал, акселератор у нас замечательно рисует многослойные картинки. Кстати, с такой архитектурой и 3D можно нормально держать.

MS>Теоретически, модель данных SVG/SL позволяет представлять плоскую многоцветную сцену, но при этом сразу же возникает проблема "сшивания ребер" (edge stitching).
Ок, спасибо. Теперь понятно.

Попробуй выдвинуть в MS идею добавить такую модель в SL. Было бы круто.

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

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

Ну, во-первых, даже с HW acceleration это может быть слишком дорого (и есть слишком дорого, иначе наша компания не получала бы существенного дохода), во-вторых, эти байки про видеоакселераторы я слушаю со времен GDI+, в то время как на практике все рендерится чисто софтварно.
Можно тебя попросить проверить одну простую фишку SL на самой распоследней Висте с самыми наикрутейшими драйверами?
Берется http://www.simplegeek.com/mharsh/wpfepad/
После чего в нижнее окно надо сделать copy-paste следующего кода:

<Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
        Width="1056" Height="816">

    <Path Data="M 20,100 C 40,120 180,120 200,100z"
          Fill="#FFFFFF"/>

    <Path Data="M 20,100 C 40,120 180,120 200,100 L 200,120 L 20,120z"
          Fill="#FFFFFF"/>

    <Path Data="M 300,20 C 320,40 320,180 300,200z"
          Fill="#FFFFFF"/>

    <Path Data="M 300,20 C 320,40 320,180 300,200 L 320,200 L 320,20z"
          Fill="#FFFFFF"/>
</Canvas>

И нажать Load внизу. Если кривых внутри прямоугольников не видно, значит, возможно используется HW acceleration. Если видно, то все делается чисто софтварно. При этом белые прямоугольники должны быть на темном фоне. Если же фон белый, но надо поменять все "Fill" на черный. Другими словами, должно быть контрастно.
У меня на XP получается вот так:

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

C>Посмотри на libstdc++ — оно под тоже GPL, но со специальным разрешением.

Спасибо!

C>>>А почему ты решил не LGPL заюзать? А то я уже хотел использовать в своем проекте

MS>>Задействуй AGG 2.4, он ничем не отличается от 2.5 кроме лицензии. А когда я выпущу более новую версию и возникнет реальная необходимось перехода на нее, мы придумает другое решение.
C>Надеюсь, что будет что-нибудь менее ограничивающее, чем GPL. Просто с ним уж совсем ничего не получается сделать

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

C>Попробуй выдвинуть в MS идею добавить такую модель в SL. Было бы круто.

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

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

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

C>>Попробуй выдвинуть в MS идею добавить такую модель в SL. Было бы круто.

MS>Не прокатит. Во-первых, там у них в MS Research есть люди и покруче — тот же Jim Blinn. И даже при наличии продвинутых инсайдеров ситуация с графикой даже в супер-пупер современной Висте остается на уровне каменного века. Складывается впечатление, что MS Research это что-то типа почетного доктората, чисто чтоб было — там платят пожизненную пенсию, и не спрашивают результатов. Патентные заявки от них поступают — вот и хорошо, большего и не требуется.

Так и есть. Задача Research состоит в проделывании этого самого research'а. А улучшение продуктов — это уже задача product teams. Именно они должны пойти, взять у research'а идеи и реализовать их в своих продуктах. Jim Blinn не может пойти в Windows и сказать, что у них там все отстой, и что им нужно делать. Его просто пошлют. Наоборот, люди из Windows должны прийти к Blinn'у и попросить его поделиться с ними своими идеями.

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

A>Так и есть. Задача Research состоит в проделывании этого самого research'а. А улучшение продуктов — это уже задача product teams. Именно они должны пойти, взять у research'а идеи и реализовать их в своих продуктах. Jim Blinn не может пойти в Windows и сказать, что у них там все отстой, и что им нужно делать. Его просто пошлют. Наоборот, люди из Windows должны прийти к Blinn'у и попросить его поделиться с ними своими идеями.

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

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

AVK>Вот только продукты МС это прежде всего Офис и, в меньшей степени, Windows. Девелоперское подразделение дохода не приносит и служит исключительно для проталкивания Windows.

Ну так уволить их всех на фиг, оставить только сэйлз. А скрипач не нужен, родной, — он только лишнее топливо жрет...

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

AVK>Рынка нет никакого — SL не стоит ничего. А средства разработки, как я уже сказал, дохода не приносят.

Тебя обманули.

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

AVK>>Рынка нет никакого — SL не стоит ничего. А средства разработки, как я уже сказал, дохода не приносят.

CS>Тебя обманули.

Никто меня не обманывал. Скачиваешь МСный annual report и убеждаешься, что кроме Client, Server Tools и Information Worker, другие подразделения заметного дохода не приносят.

... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>

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

MS>Ну, во-первых, даже с HW acceleration это может быть слишком дорого

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

MS>(и есть слишком дорого, иначе наша компания не получала бы существенного дохода)

Понятия не имею что там за ваша компания и почему она получает доход.

MS>, во-вторых, эти байки про видеоакселераторы я слушаю со времен GDI+, в то время как на практике все рендерится чисто софтварно.

Во взрослом WPF таки не софтварно. А насчет SL не знаю пока ничего, он еще в очень сырой стадии.

MS>Можно тебя попросить проверить одну простую фишку SL на самой распоследней Висте с самыми наикрутейшими драйверами?

Виста тут никак не влияет. И на SL проверять в текущем состоянии производительность бессмысленно. А в чем суть сего эксперимента? Я так понимаю вылазят артефакты антиалиасинга. При чем тут аппаратное ускорение?

... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>

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

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

Ты ошибаешься. Оптимизировать рисование плоских многоцветных сцен не просто необходимо, а жизненно необходимо. Вне зависимости от того, сколько треугольников в секунду они могут перемалывать.

AVK>Виста тут никак не влияет. И на SL проверять в текущем состоянии производительность бессмысленно. А в чем суть сего эксперимента? Я так понимаю вылазят артефакты антиалиасинга. При чем тут аппаратное ускорение?

При том, что эти вещи сильно взаимосвязаны. Впрочем, это долго объяснять, можешь просто поверить на слово, что до тех пор, пока в приведенном примере присутствует явно видимые швы, никакого аппаратного ускорения не используется, а используется банальный софтварный растеризатор. А для него перекрашивать много раз сцену это не просто дорого, а очень дорого. В общем, имеются сильные сомнения, что в обозримом будущем будет задействовано аппаратное ускорение для векторной графики. А для SL мой прогноз — вообще никогда, так же как это произошло с GDI+.

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

MS>>Ну, во-первых, даже с HW acceleration это может быть слишком дорого
AVK>Для современных акселераторов вряд ли. Для них миллионы плоскостей с отсечением и блендингом десятки раз в секунду выводить не является проблемой.
Мне вот интересно как у современных акселераторов с точностью. В них везде используются float'ы, так что иногда артефакты получаются. В играх это не так важно, но вот для изображений полиграфической точности уже может быть проблема.

MS>>, во-вторых, эти байки про видеоакселераторы я слушаю со времен GDI+, в то время как на практике все рендерится чисто софтварно.
AVK>Во взрослом WPF таки не софтварно. А насчет SL не знаю пока ничего, он еще в очень сырой стадии.
Кстати, в WPF можно интегрировать трехмерные сцены?

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

C>>Посмотри на libstdc++ — оно под тоже GPL, но со специальным разрешением.
MS>Спасибо!
Вот даже текст этого исключения:

// As a special exception, you may use this file as part of a free software
// library without restriction. Specifically, if other files instantiate
// templates or use macros or inline functions from this file, or you compile
// this file and link it with other files to produce an executable, this
// file does not by itself cause the resulting executable to be covered by
// the GNU General Public License. This exception does not however
// invalidate any other reasons why the executable file might be covered by
// the GNU General Public License.

C>>Надеюсь, что будет что-нибудь менее ограничивающее, чем GPL. Просто с ним уж совсем ничего не получается сделать

MS>Ну я же сказал, GPL — это чисто зонтик от дождя, не более того. Другие лицензии завсегда возможы, но просто решается это индивидуально.
Индивидуально — это уже не так удобно, да и оперсорсники могут возражать. А вообще, пока просто подожду.

Желаю удачи в борьбе с мегакорпорациями!

C>>Попробуй выдвинуть в MS идею добавить такую модель в SL. Было бы круто.
MS>Не прокатит. Во-первых, там у них в MS Research есть люди и покруче — тот же Jim Blinn. И даже при наличии продвинутых инсайдеров ситуация с графикой даже в супер-пупер современной Висте остается на уровне каменного века. Складывается впечатление, что MS Research это что-то типа почетного доктората, чисто чтоб было — там платят пожизненную пенсию, и не спрашивают результатов. Патентные заявки от них поступают — вот и хорошо, большего и не требуется.
Ага, складывается такое же впечатление. MS Research пишет кучу интересных статей, даже делает какие-то интересные продукты (типа Phoenix'а о котором тут пару лет назад говорили) — а потом на них забивает.

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

Планы по завоеванию мира с помощью AGG?

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

VD>>Если у тебя есть другая информация, приводи ссылки.

AVK>Какая другая? Та самая? Ссылок не могу привести, видел сии цифры на презентации, на Платформе.

Тогда обсуждать нечего.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

AVK>Никто меня не обманывал. Скачиваешь МСный annual report и убеждаешься, что кроме Client, Server Tools и Information Worker, другие подразделения заметного дохода не приносят.

Ссылку, плиз на этот документ.

Я вот сделал примитившеший запрос по гуглю:
Прибыль корпорации Microsoft
И все первые ссылки (дальше не смотрел) как одна трезвонят, что доходы МС шибко выросли по сравнению с прошлым годом, так как начались продажи Висты.
Примеры:
http://www.computerra.ru/news/316864/
http://www.vedomosti.ru/newspaper/article.shtml?2007/04/28/125030
http://www.cybersecurity.ru/os/23687.html

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

MS>Я несколько не о том. Не о формате данных, а о принципах организации данных. SVG и SL предполагают рисование сцены слой за слоем, многократно перезакрашивая по одному и тому же месту. В случае сложной анимации это становится очень медленно. Flash "уплощает" геометрию и использует спепциальную модель данных для этого. Это уплощение выполняется при создании файла, поскольку является довольно дорогой операцией. В run-time этого лучше не делать.
MS>http://antigrain.com/stuff/compound_paths.png

MS>Теоретически, модель данных SVG/SL позволяет представлять плоскую многоцветную сцену, но при этом сразу же возникает проблема "сшивания ребер" (edge stitching). С моделью данных Flash у меня есть хотя бы принципиальная возможность рисования без швов, а с SVG/SL такой возможности нет, поскольку нет информации о смежности. В данных Flash нет полигонов как таковых. Там просто набор ребер, каждому из которых присвоено два стиля закраски — слева и справа от ребра. Все ребра в совокупности образуют замкнутый и непротиворечивый граф. Поэтому я знаю, какое ребро с какими областями контачит и могу нарисовать сцену без швов. На SVG/FL у меня такой информации нет. Правильно можно нарисовать только с использованием FSAA, ну или использовать традиционным layered способом с многогратной перезакраской. Кстати, layered scene не всегда возможно обеспечить. Например, при векторизации фотографий, см, например Vector Eye — модель данных Flash для этого гораздо лучше подходит.

Максим , можешь пояснить почему этого нельзя сделать с SVG ? я вижу по крайней мере 2 возможности.

1. Всю сцену трасировать как один полигон с информацией о цвете и Z ordering.
2. Spans накапливать в промежуточном буфере для каждой линии scanline, без отрисовки , затем сортировать scanline и рисовать опять же за один проход.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

C>Мне вот интересно как у современных акселераторов с точностью. В них везде используются float'ы, так что иногда артефакты получаются. В играх это не так важно, но вот для изображений полиграфической точности уже может быть проблема.

Какие именно артефакты? Например, недокрашенные или перекрашенные пикселы на стыках возникают, если только сетка имеет T-junctions, но здесь и двойная точность не поможет. Так же может быть проблема при очень большом зуме, когда линии начинают скакать. Но это уже как бы и не артефакты, а просто ограничение по точности.

AVK>>Во взрослом WPF таки не софтварно. А насчет SL не знаю пока ничего, он еще в очень сырой стадии.
C>Кстати, в WPF можно интегрировать трехмерные сцены?

Кстати, забыл спросить — а что такое "взрослый WPF" и где его можно посмотреть? Только на Висте?
Еще раз попрошу, безотносительно к accelerated или нет, проверить вот этот пример на самом что ни на есть взрослом WPF и привести screenshot. http://www.rsdn.ru/Forum/Message.aspx?mid=2475048&only=1
Мне очень интересно узнать, есть там швы или нет?

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

M>1. Всю сцену трасировать как один полигон с информацией о цвете и Z ordering.

Это как? один полигон в SVG может иметь один стиль закраски.

M>2. Spans накапливать в промежуточном буфере для каждой линии scanline, без отрисовки , затем сортировать scanline и рисовать опять же за один проход.

В AGG, в compound rasterizer я именно так и делаю. Теоретически возможно избежать швов в SVG, если, например, растеризовать целую группу (<g>) в один проход. Но вопрос о том, можно ли это сделать или нельзя, является нетривиальным. Например, если в группе есть хоть один полупрозрачный элемент (или подгруппа), то уже нельзя. Или даже некая comp-op, отличная от alpah-blend, то тоже нельзя. Этих "вторичных половых признаков" там много и некоторые из них являются неявными. В общем, перед принятием решения нужно выполнить серьезный анализ данных. Иными словами, нет явной информации о том, что надо растаризовать в один проход, а что — послойно. Кроме того, нет явной информации о смежности областей. Растеризатор с этим справляется нормально, приходится только дважды обрабатывать одни и те же ребра, а вот для тесселятора дублирующиеся ребра могут быть серьезной проблемой.

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

Там есть понятие "key frame" и есть простой линейный морфинг для геометрии, аффинных матриц, цветов, градиентов и т.д. См, например, http://www.ncsoft.com/ — типичный геометрический морфинг при наезде на пункты меню.

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

K>Привет, Максим. А как обстоят дела с compound paths в OpenVG?
K>На настоящий момент я их там не увидел.

Никак. Они больше года жевали сопли по поводу нашего предложения, после чего решили не включать. Хотя API являся бы почти прямым отображением на модель данных compound paths. В общем, "смелые люди, но всего боятся".

K>Ещё, если не сложно, для общего развития можешь проконсультировать по вопросу?
K>Существуют ли вообще алгоритмы перевода данных из SVG представления в compound paths и обратно и насколко они дорогие?

Восстановить замкнутые контуры из compound paths возможно и достаточно легко. Просто в точке разветвления берется первое попавшееся ребро с таким же стилем и так до тех пор пока контур не замкнется. При рисовании с правилом even/odd получается все правильно. Да, все контуры с одним и тем же стилем надо рисовать за один проход, чтобы получить правильные дыры.

Обратная задача гораздо сложнее. Она очень похожа на Constructive Solid Geometry. У меня есть кое-какие соображения, но серьезно я над этим пока не думал.

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

MS>Ты ошибаешься. Оптимизировать рисование плоских многоцветных сцен не просто необходимо, а жизненно необходимо.

У тебя есть каки нибудь аргументы? Или нужно верить на слово?

MS> Впрочем, это долго объяснять, можешь просто поверить на слово

Нет, не поверю. Я точно знаю, что взрослый WPF использует Direct3D для вывода, а артефакты точно такие же.

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

Растеризатор софтварный конечно, с этим вроде никто и не спорил. Аппаратное там наложение и блендинг.

MS> А для него перекрашивать много раз сцену это не просто дорого, а очень дорого.

Он ее не перекрашивает много раз, он просто формирует текстуру. Один раз.

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

Для векторной графики никакого аппаратного ускорения и нет. Только это не имеет никакого отношения к замедлению производительности от многократного наложения.

... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>

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

MS>Кстати, забыл спросить — а что такое "взрослый WPF"

Собственно то, что называется WPF и является частью NetFX 3.

MS> и где его можно посмотреть?

Начиная с XP SP2. Но видеоакселератор нужен не самый дохлый.

MS>Еще раз попрошу, безотносительно к accelerated или нет, проверить вот этот пример на самом что ни на есть взрослом WPF и привести screenshot. http://www.rsdn.ru/Forum/Message.aspx?mid=2475048&only=1
MS>Мне очень интересно узнать, есть там швы или нет?

Есть.

... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>

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

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

M>>1. Всю сцену трасировать как один полигон с информацией о цвете и Z ordering.

MS>Это как? один полигон в SVG может иметь один стиль закраски.

Стиль закраски это even odd, non zero ? если это тогда нет проблем.

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

В Active Edge Table мы храним для каждого ребра указатель на текущие параметры слоя, то есть сколько было слоев по алгоритму "рисовальщика" , столько заводим данных по текущему winding и т.п. для слоя.
Плюс этого подхода в том что сортировка не на каждую линию сканирования идет, ну и прооптимизировать можно много чего.
И конечно скорость отрисовки на порядок быстрее должна быть , по сравнению с отрисовкой по частям.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

MS>>Ты ошибаешься. Оптимизировать рисование плоских многоцветных сцен не просто необходимо, а жизненно необходимо.

AVK>У тебя есть каки нибудь аргументы? Или нужно верить на слово?

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

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

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

AVK>Он ее не перекрашивает много раз, он просто формирует текстуру. Один раз.

Для каждого полигона одну текстуру, ага. Которую, заметим, требуется софтварно растеризовать. И чтобы сформировать сцену из 50 полигонов, надо закачать в видеокарту 50 текстур. А поскольку размер текстуры определяется через bounding box, который, в свою очередь может быть размером с окно, то получается 50-кратный перерасход при пересылке данных. Тебя обманули — это не аппаратное ускорение, это называется встроенный аппаратный вечный тормоз.

AVK>Для векторной графики никакого аппаратного ускорения и нет. Только это не имеет никакого отношения к замедлению производительности от многократного наложения.

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

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

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

MS>>Это как? один полигон в SVG может иметь один стиль закраски.

M>Стиль закраски это even odd, non zero ? если это тогда нет проблем.

Под стилем я подразумеваю цвет, градиент, такстуру и т.д.

M>Алгоритм рисовальщика работает по слоям , если я прав. Сначала один объект или группа , затем другой и т.д. Мы просто для каждого слоя храним текущие параметры отрисовки.

M>В Active Edge Table мы храним для каждого ребра указатель на текущие параметры слоя, то есть сколько было слоев по алгоритму "рисовальщика" , столько заводим данных по текущему winding и т.п. для слоя.
M>Плюс этого подхода в том что сортировка не на каждую линию сканирования идет, ну и прооптимизировать можно много чего.
M>И конечно скорость отрисовки на порядок быстрее должна быть , по сравнению с отрисовкой по частям.

Именно так. Но для этого необходима информация о том, что вот эту группу полигонов (с разными стилями!) можно использовать как единое целое для растеризации или тесселяции. Ни в SVG, ни в SL такой информации в явном виде нет, а вычислять по вторичным половым признакам — это сложно и ненадежно. Нужно хотя бы иметь уверенность в том, что "вот эта группа полигонов представляет собой плоскую многоцветную сцену". Поэтому я и говорю, что примитивная модель данных является морально устаревшей и неэффективной.

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

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

MS>>>Это как? один полигон в SVG может иметь один стиль закраски.

M>>Стиль закраски это even odd, non zero ? если это тогда нет проблем.

MS>Под стилем я подразумеваю цвет, градиент, такстуру и т.д.

M>>Алгоритм рисовальщика работает по слоям , если я прав. Сначала один объект или группа , затем другой и т.д. Мы просто для каждого слоя храним текущие параметры отрисовки.

M>>В Active Edge Table мы храним для каждого ребра указатель на текущие параметры слоя, то есть сколько было слоев по алгоритму "рисовальщика" , столько заводим данных по текущему winding и т.п. для слоя.
M>>Плюс этого подхода в том что сортировка не на каждую линию сканирования идет, ну и прооптимизировать можно много чего.
M>>И конечно скорость отрисовки на порядок быстрее должна быть , по сравнению с отрисовкой по частям.

MS>Именно так. Но для этого необходима информация о том, что вот эту группу полигонов (с разными стилями!) можно использовать как единое целое для растеризации или тесселяции. Ни в SVG, ни в SL такой информации в явном виде нет, а вычислять по вторичным половым признакам — это сложно и ненадежно. Нужно хотя бы иметь уверенность в том, что "вот эта группа полигонов представляет собой плоскую многоцветную сцену". Поэтому я и говорю, что примитивная модель данных является морально устаревшей и неэффективной.

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

C>>Мне вот интересно как у современных акселераторов с точностью. В них везде используются float'ы, так что иногда артефакты получаются. В играх это не так важно, но вот для изображений полиграфической точности уже может быть проблема.
MS>Какие именно артефакты? Например, недокрашенные или перекрашенные пикселы на стыках возникают, если только сетка имеет T-junctions, но здесь и двойная точность не поможет. Так же может быть проблема при очень большом зуме, когда линии начинают скакать. Но это уже как бы и не артефакты, а просто ограничение по точности.
У меня была проблема с тем, что координаты на сцене задавались в диапазоне от [-1,1]. И при переводе "в пиксели" оно ехало на мелких деталях из-за ошибок округления (пользуясь случаем, хочу передать привет Владимиру Юровицкому).

Мне это было не очень критично — так как при выводе на принтер точности вполне хватало (еще бы, 1200dpi...).

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

AVK>>>Во взрослом WPF таки не софтварно. А насчет SL не знаю пока ничего, он еще в очень сырой стадии.
C>>Кстати, в WPF можно интегрировать трехмерные сцены?
AVK>В WPF можно не то что интегрировать, там можно, к примеру, на грань трехмерной фигуры налепить обычные контролы.
Это, на самом деле, весьма бесполезная вещь. В реальных сложных 3D-приложениях делают свой rendering pipeline, оптимизированый под нужды движка. Ну а для простых приложений, ИМХО, лучше использовать хороший 2D.

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

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

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

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

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

M>Может приведешь пример , чтобы сразу было видно в чем сложность, иначе неделю спать не буду ... буду в голове перемалывать.

http://antigrain.com/stuff/compound_paths.png
Вот простейшая сцена из трех кружочков. Если все три непрозрачные, то во всех трех вариантах представления даных, мы должны получить тот же результат. Но если мы сделаем красный кружочек полупрозрачным, то в случае layered scene мы получим результат, отличный от двух других вариантов. В первом варианте черз него будет просвечивать синий, а в двух других — белый фон. А компаундный растеризатор, так же как и тесселятор устроен таким образом, что он принципиально уплощает геометрию (в одной точке один стиль) — иначе просто смысла в нем нет. То есть, результат его работы будет идентичен во всех трех случаях, вне зависимости от прозрачности элементов. Но если мы расчитываем на результат layred scene, то обязаны смотреть — если красный кружок полупрозрачный, то мы обязаны нарисовать это все слой за слоем, обычным образом. Если же все непрозрачное, мы имеем право соптмиировать и растеризовать всю сцену за один проход. Иными словами, если все элементы слоеной сцены непрозрачны, то мы имеем право выполнить уплощение геометрии. Если же есть прозрачный элемент, то через него должно быть видно то, что находится под ним в сцене, а не под сценой. Кроме прозрачности таких критериев еще вагон — когда можно, а когда нельзя так делать. Но явной информации не дано. Вообще, проблема похожа на проблему "group opacity" в том же SVG. А во Flash я точно знаю, что compound shape всегда является плоским слоем и спокойно растеризую в один проход. См. agg-2.4/examples/flash_rasterizer.cpp.

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

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

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

M>>Может приведешь пример , чтобы сразу было видно в чем сложность, иначе неделю спать не буду ... буду в голове перемалывать.

MS>http://antigrain.com/stuff/compound_paths.png
MS>Вот простейшая сцена из трех кружочков. Если все три непрозрачные, то во всех трех вариантах представления даных, мы должны получить тот же результат. Но если мы сделаем красный кружочек полупрозрачным, то в случае layered scene мы получим результат, отличный от двух других вариантов. В первом варианте черз него будет просвечивать синий, а в двух других — белый фон. А компаундный растеризатор, так же как и тесселятор устроен таким образом, что он принципиально уплощает геометрию (в одной точке один стиль) — иначе просто смысла в нем нет. То есть, результат его работы будет идентичен во всех трех случаях, вне зависимости от прозрачности элементов. Но если мы расчитываем на результат layred scene, то обязаны смотреть — если красный кружок полупрозрачный, то мы обязаны нарисовать это все слой за слоем, обычным образом. Если же все непрозрачное, мы имеем право соптмиировать и растеризовать всю сцену за один проход. Иными словами, если все элементы слоеной сцены непрозрачны, то мы имеем право выполнить уплощение геометрии. Если же есть прозрачный элемент, то через него должно быть видно то, что находится под ним в сцене, а не под сценой. Кроме прозрачности таких критериев еще вагон — когда можно, а когда нельзя так делать. Но явной информации не дано. Вообще, проблема похожа на проблему "group opacity" в том же SVG. А во Flash я точно знаю, что compound shape всегда является плоским слоем и спокойно растеризую в один проход. См. agg-2.4/examples/flash_rasterizer.cpp.

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

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

1. встретили первый спан , рисуем
2. встретили второй спан, если он из этого же слоя , выполняем winding rule.
3. если слой чужой, выбираем
а) если спан поверх текущего , значит рисуем его.
б) если спан ниже нашего, продолжаем рисовать текущий спан.
с) если кто то из спанов полупрозрачен , комбинируем слои с учетом Z ordering , а это необходимо делать в любом случае.

Тогда каждый пиксел вс равно рисуется только один раз.
Невидимые полигоны/пикселы не рисуются а просто скипаются.
когда требуется комбинация слоев , выполняем ее сразу для целого пиксела со всеми слоями и по возможности оптимизируем (откидываем лишнее).

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

MS> То есть, результат его работы будет идентичен во всех трех случаях, вне зависимости от прозрачности элементов. Но если мы расчитываем на результат layred scene, то обязаны смотреть — если красный кружок полупрозрачный, то мы обязаны нарисовать это все слой за слоем, обычным образом.
А почему бы для полупрозрачных областей не предвычислять их цвет?

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

C>У меня была проблема с тем, что координаты на сцене задавались в диапазоне от [-1,1]. И при переводе "в пиксели" оно ехало на мелких деталях из-за ошибок округления (пользуясь случаем, хочу передать привет Владимиру Юровицкому).

C>Мне это было не очень критично — так как при выводе на принтер точности вполне хватало (еще бы, 1200dpi...).

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

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

C>А почему бы для полупрозрачных областей не предвычислять их цвет?

Если цвет сплошной, то конечно. А если там градиент или текстура?

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

C>>А почему бы для полупрозрачных областей не предвычислять их цвет?
MS>Если цвет сплошной, то конечно. А если там градиент или текстура?
Интересный вопрос...

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

Здравствуйте, 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 это может быть довольно оптимальный метод ?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 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 мег. Тебе жалко?

... << RSDN@Home 1.2.0 alpha rev. 675>>

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 675>>

Здравствуйте, 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 на ста тысячах элементов ласты откинет. Тоже детская игрушка?

... << RSDN@Home 1.2.0 alpha rev. 675>>

Здравствуйте, 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 мег. А на практике они бывают во много раз больше.

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

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

Понимаю.

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

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

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

Я в курсе.

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 675>>

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 675>>

Здравствуйте, 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 заваливает

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

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

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

Кстати, легко — это примерно вчетверо быстрее, чем BitBlt полноцветной 32-bpp картинки. Это очень медленно.

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

Кстати говоря, забыл спросить — какое такое сжатие? S3TC (sometimes also called DXTn or DXTC) — это действительно примитивная компрессия с потерей качества. Причем, нет никакой возможности управлять уровнем качества. И доступна она только для цветных текстур. То есть, для передачи растеризованного альфа-канала категорически непригодна. А других типов компрессии, понимаемых видео-железом пока не существует.

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

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

MS>Это распространенный миф. FSAA очень и очень небесплатен. Как только задействуются пиксельные шейдеры

А если не задействуют, то бесплатен. Это пример, понимаешь.

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

MS>Ты ошибаешься. Z-буфер работает не так.

Я нигде и не говорил, как работает Z-буфер. Я сказал другое — WPF использует аппаратный Z-буфер.

MS>Короче, я выяснил, что в SL никакой Direct3D не используется.

На данном этапе вполне возможно. Он еще в очень сыром состоянии, даже GoLive беты нет. WPF тоже довольно долгое время рендерил через GDI.

... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>

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

MS>Складывается впечатление, что апологеты Микрософт живут в какой-то иллюзорной стране чудес, где, например, и шрифты с кривыми Безье могут рендериться с аппаратным ускорением.

Я такое когда нибудь говорил?

... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>

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

MS>>Это распространенный миф. FSAA очень и очень небесплатен. Как только задействуются пиксельные шейдеры

AVK>А если не задействуют, то бесплатен. Это пример, понимаешь.

Тоже небесплатен. Его можно считать условно бесплатным до тех пор, пока софт не успевает загружать конвейеры видеокарты по самые уши. А когда удается утилизировать 100% ресурсов видеокарты, то разница даже с 6x FSAA составляет 2-4 раза. Но как мы выяснили по наличию швов, WPF использует софтварную растеризацию с Edge AA. Соответственно, FSAA там будет только мешаться.

AVK>Я нигде и не говорил, как работает Z-буфер. Я сказал другое — WPF использует аппаратный Z-буфер.

А я объяснил как он работает и привел доводы в пользу того, что WPF не может использовать аппаратный Z-буфер. Еще раз: Z-буфер работает с Z-координатой, линейно интерполируемой по плоскости треугольника, но он никак не может задействовать значения пикселов из текстуры.

В общем, так и не понятно, что же именно в WPF рисуется аппаратно ускоренно. Нигде не нашел четкой информации — все какие-то обрывки и слухи. Подозреваю, что просто-напросто софтварно рендерится битмап целиком (от начала и до конца), который потом можно "натянуть" на произвольную 3D поверхность. А сомнения есть еще и потому, что спецификация векторной графики в XAML фактически содрана с SVG. И там и там есть много деталей, входящих в противоречие с устройством конвейеров в апрпаратных ускорителях.

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

MS>А я объяснил как он работает и привел доводы в пользу того, что WPF не может использовать аппаратный Z-буфер. Еще раз: Z-буфер работает с Z-координатой, линейно интерполируемой по плоскости треугольника, но он никак не может задействовать значения пикселов из текстуры.

А зачем ему знать что там за пискель? Текстуры сдят на мешах. Меши z-буфером отскаются. Далее остается только сгенерить изображение из того что получилось.

В общем, что ты ты загибаешь.

Мои эксперементы с WPF показали, что как раз все что связано с отображением текстур там акселерируется. Проблемы с созданием самих текстур. Вот эта задача не решена никак. WPF это в первую очередь средство создания ГУИ. А ГУИ, как это не прискорбно, в 90% случаев выводит на экран динамический текст. Это полностью нивелирует весь выигрышь в некоторых (весьма распространенных) задачах. От того WPF интерфейсы частенько при всей своей красивости не шибко информативные.

В прочем, к вопросу отсечения геометрических фигур это никак не относится.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

MS>Соответственно, FSAA там будет только мешаться.

Блин, такое ощущение что ты читаешь по диагонали. Это пример, понимаешь, ПРИМЕР. Пример того, что далеко не всегда с амые быстрые алгоритмы в итоге позволят получить самый быстрый результат.

AVK>>Я нигде и не говорил, как работает Z-буфер. Я сказал другое — WPF использует аппаратный Z-буфер.

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

Твои доводы ничего не стоят, потому что не соответствуют действительности.

MS>В общем, так и не понятно, что же именно в WPF рисуется аппаратно ускоренно. Нигде не нашел четкой информации — все какие-то обрывки и слухи.

Задай вопрос в соотв. форуме на MSDN, тебе скажут где поглядеть. Мне в свое время кое что в MSDN попадалось.

... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>

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

VD>А зачем ему знать что там за пискель? Текстуры сдят на мешах. Меши z-буфером отскаются. Далее остается только сгенерить изображение из того что получилось.

Объясняю популярно. Текстура растеризуется софтварно, так? Возьмем для примера круг. Теперь, чтобы его отобразить, надо выполнить два действия. Во-первых, загрузить текстуру в видеопамять — это просто. Во-вторых, надо сделать сетку. Для простой плоскости сетка представляеь собой два смежных треугольника, покрывающих текстуру. Z-буфер будет работать с этой сеткой, ничего не зная о содержимом текстуры. В результате, в случае с плоскостью, операция с Z-буфером "выкусит" целый прямоугольник, покрывающий текстуру, в то время, как нам требуется модифицировать только те пикселы в Z-буфере, которые имеют ненулевую альфу в нашей текстуре. А Z-буфер про текстуру ничего не знает. И даже не знает, что там у нас — текстура или сплошной цвет. Ну так вот он устроен.

Но это все фигня. Как только среди полигонов встречается хотя бы один полупрозрачный, то все — про Z-буфер можно забыть. Даже если один полу-прозрачный пиксел. А в растеризованных текстурах этих полупролзрачнгых пикселов много, даже если сам полигон непрозрачный (догадайся, почему).

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

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

AVK>Твои доводы ничего не стоят, потому что не соответствуют действительности.

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

Здравствуйте, McSeem2, Вы писали:
MS>Z-буфер будет работать с этой сеткой, ничего не зная о содержимом текстуры. В результате, в случае с плоскостью, операция с Z-буфером "выкусит" целый прямоугольник, покрывающий текстуру, в то время, как нам требуется модифицировать только те пикселы в Z-буфере, которые имеют ненулевую альфу в нашей текстуре. А Z-буфер про текстуру ничего не знает. И даже не знает, что там у нас — текстура или сплошной цвет. Ну так вот он устроен.
MS>Но это все фигня. Как только среди полигонов встречается хотя бы один полупрозрачный, то все — про Z-буфер можно забыть. Даже если один полу-прозрачный пиксел. А в растеризованных текстурах этих полупролзрачнгых пикселов много, даже если сам полигон непрозрачный (догадайся, почему).

Если мне не изменяет память, игрался с 8-м директ3D довольно давно, то Z-буфер вообще работает с экранными пикселями, и там еще есть логика когда обновлять содержимое Z буфера, и как раз про полигоны то он ничего и не знает. Да и насколько помню выкусыванием полигонов занимаются немного другие алгоритмы, там тоже используется Z но только это Z составляющая вектора нормали.

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

MS>В результате, в случае с плоскостью, операция с Z-буфером "выкусит" целый прямоугольник

С чего бы это? Z-буфер хранит глубину каждого пикселя результирующего изображения. Так что ничего он выкусывать не будет. Выкидывание целых полигонов это совсем другие алгоритмы.

MS> А Z-буфер про текстуру ничего не знает. И даже не знает, что там у нас — текстура или сплошной цвет.

MS>Но это все фигня. Как только среди полигонов встречается хотя бы один полупрозрачный, то все — про Z-буфер можно забыть. Даже если один полу-прозрачный пиксел.

Все это здорово. Непонятно только одно — как современные ускорители справляются с альфа-блендингом.

... << RSDN@Home 1.2.0 alpha rev. 675>>

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

MS>Ну тогда тебе придется подкрепить свои слова чем нибудь более надежным, чем голословные утверждения. Итак, откуда дровишки?

Извини, но точных ссылок у меня нет. Базовые сведения по аппаратной акселерации WFP — http://msdn2.microsoft.com/en-us/library/ms742196.aspx . Дальше, если интерсны детали, скачиваешь SDK, там есть утилитка XAMLPad, которая позволяет поиграться с геометрией, и утилитка WpfPerf, которая позволит посмотреть, что и где там происходит в плане рендеринга.

... << RSDN@Home 1.2.0 alpha rev. 675>>

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

AVK>С чего бы это? Z-буфер хранит глубину каждого пикселя результирующего изображения. Так что ничего он выкусывать не будет. Выкидывание целых полигонов это совсем другие алгоритмы.
Максим говорит о том что если ты вывел некоторую текстуру натянутую на пару треугольников то в Z-buffer'е будет прямоугольних заполнений Z'ом этих треугольников. И ты больше ничего не сможешь вывести под этим прямоугольником даже если он полупрозрачный.

AVK>Все это здорово. Непонятно только одно — как современные ускорители справляются с альфа-блендингом.
Полигоны сортируют перед выводом.
Вобще умные игрушки сначала выводят все полностью не прозрачние полигоны. Причем сначала выводят ближайшие. Это позволяет ускорителю не заморачиваться с расчетом цвета пикселя ибо происходит отсечка по Z-buffer'у. А потом прозрачные. Но прозрачные нужно сначала выводить самые дальние. Это нужно чтобы несколько перекрывающихся полупрозрачных поверхностей наложились правильно.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

VD>>А зачем ему знать что там за пискель? Текстуры сдят на мешах. Меши z-буфером отскаются. Далее остается только сгенерить изображение из того что получилось.

MS>Объясняю популярно. Текстура растеризуется софтварно, так?
MS> Возьмем для примера круг.

Ага. Но если ты рисуешь скажем текстурированный круг, то как я понимаю сам круг будет мешью. И стало быть z-бужер будет пахать по полной программе.

Куча ошибочных предположений поскипана.

MS> А Z-буфер про текстуру ничего не знает.

Как это не знает? Z-буфер берет пиксель из меши и переносит его в свою памтять давая ему признак глубины.

MS>Но это все фигня. Как только среди полигонов встречается хотя бы один полупрозрачный, то все — про Z-буфер можно забыть.

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

MS> Даже если один полу-прозрачный пиксел. А в растеризованных текстурах этих полупролзрачнгых пикселов много, даже если сам полигон непрозрачный (догадайся, почему).

Немогу дагадаться. Особенно сбивает то, что я сам видел отличню работу этого всего.

Еще раз повторюсь. Единственная проблема — это формирование самой текстуры. Особая проблема — это текст. Вот он тормозит безбожно. Даже хуже чем в ГДИ. В прочем современные процессоры работают довольно шустро и на них это не так заметно.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Ага. Но если ты рисуешь скажем текстурированный круг, то как я понимаю сам круг будет мешью. И стало быть z-бужер будет пахать по полной программе.
Z-буффер тебе не поможет даже для полупрозрачных кругов в виде сеток. Так как в Z-буффер при выводе полупрозрачной геометрии писать нельзя.

VD>Как это не знает? Z-буфер берет пиксель из меши и переносит его в свою памтять давая ему признак глубины.
Не знает. Он работает с треугольниками, то есть просто делает интерполяцию по двум координатам. С шейдерами что-нибудь можно было бы сочинить, но с полупрозрачными треугольниками все равно и они не помогут.

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

C>Z-буффер тебе не поможет даже для полупрозрачных кругов в виде сеток.

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

... << RSDN@Home 1.2.0 alpha rev. 675>>

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

VD>Ага. Но если ты рисуешь скажем текстурированный круг, то как я понимаю сам круг будет мешью. И стало быть z-бужер будет пахать по полной программе.

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

VD>Как это не знает? Z-буфер берет пиксель из меши и переносит его в свою памтять давая ему признак глубины.

А признак глубины — это Z-координата, линейно интерполируемая по треугольникам. В частном случае чистого 2D она является банальной константой.

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

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

Он "прекрасно работает" только с честной сеткой. Для чего надо триангулировать полигоны в векторном виде.

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

А теперь смотри, что получается. Текстура натянута на прямоугольник, порубанный на два треугольника. При этом часть квадрата (внутренность полигона) у нас непрозначна, другая часть — полностью прозрачна, пикселы на границе — полупрозрачны. Теперь думаем, где здесь место для Z-буфера.

AVK>Но, при этом, этот самый блендинг современные видюшки тоже выполняют аппаратно.

Безусловно, но Z-буфер здесь ни при чем.

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

MS>Безусловно, но Z-буфер здесь ни при чем.

А я обратного и не говорил.

... << RSDN@Home 1.2.0 alpha rev. 675>>

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

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

Что обсуждать уже работающую технологию?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

MS>>Ну тогда тебе придется подкрепить свои слова чем нибудь более надежным, чем голословные утверждения. Итак, откуда дровишки?

AVK>Извини, но точных ссылок у меня нет. Базовые сведения по аппаратной акселерации WFP — http://msdn2.microsoft.com/en-us/library/ms742196.aspx . Дальше, если интерсны детали, скачиваешь SDK, там есть утилитка XAMLPad, которая позволяет поиграться с геометрией, и утилитка WpfPerf, которая позволит посмотреть, что и где там происходит в плане рендеринга.

Хм. Забавно "Sub-pixel font rendering uses available pixel shaders on the graphics hardware." что-то я не заметил ускорения рендеринга фортов.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

WH>Максим говорит о том что если ты вывел некоторую текстуру натянутую на пару треугольников то в Z-buffer'е будет прямоугольних заполнений Z'ом этих треугольников. И ты больше ничего не сможешь вывести под этим прямоугольником даже если он полупрозрачный.

Ничего не понял.

WH>Полигоны сортируют перед выводом.
WH>Вобще умные игрушки сначала выводят все полностью не прозрачние полигоны. Причем сначала выводят ближайшие. Это позволяет ускорителю не заморачиваться с расчетом цвета пикселя ибо происходит отсечка по Z-buffer'у. А потом прозрачные. Но прозрачные нужно сначала выводить самые дальние. Это нужно чтобы несколько перекрывающихся полупрозрачных поверхностей наложились правильно.

Вообще-то для вывода двух текстур достаточно мутитекстурирования и текстур с прозрачностью. Выведены они будут железом за один проход.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

C>Так как в Z-буффер при выводе полупрозрачной геометрии писать нельзя.

С чего это вдруг?

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

VD>Хм. Забавно "Sub-pixel font rendering uses available pixel shaders on the graphics hardware." что-то я не заметил ускорения рендеринга фортов.

Это насколько я понимаю только в Vista с использованием формата D3DFMT_A1.

Fdooch wrote:
> C>Так как в Z-буффер при выводе полупрозрачной геометрии писать нельзя.
> С чего это вдруг?
А с того, что если мы будем писать в Z-буффер при выводе полупрозрачного
треугольника, то уже не нарисуем того, что находится под ним.

Posted via RSDN NNTP Server 2.1 beta

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

C>Fdooch wrote:
>> C>Так как в Z-буффер при выводе полупрозрачной геометрии писать нельзя.
>> С чего это вдруг?
C>А с того, что если мы будем писать в Z-буффер при выводе полупрозрачного
C>треугольника, то уже не нарисуем того, что находится под ним.

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

Fdooch wrote:
> C>А с того, что если мы будем писать в Z-буффер при выводе полупрозрачного
> C>треугольника, то уже не нарисуем того, что находится под ним.
> Все полупрозрачные объекты выводятся в отсортированом по глубине порядке
> после непрозрачных объектов. Но это не зависит от того используем мы
> хардверный рендеринг или нет.
Ну так и чем нам тут сильно поможет Z-буффер?

Кроме того, как будешь сортировать по глубине классические "три
треугольника"?

Posted via RSDN NNTP Server 2.1 beta

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

C>Fdooch wrote:
>> C>А с того, что если мы будем писать в Z-буффер при выводе полупрозрачного
>> C>треугольника, то уже не нарисуем того, что находится под ним.
>> Все полупрозрачные объекты выводятся в отсортированом по глубине порядке
>> после непрозрачных объектов. Но это не зависит от того используем мы
>> хардверный рендеринг или нет.
C>Ну так и чем нам тут сильно поможет Z-буффер?
Да тем же чем и в остальных случаях, отсечет по глубине невидимые фрагменты.

C>Кроме того, как будешь сортировать по глубине классические "три
C>треугольника"?
Насколько я понимаю в WPF такая ситуация невозможна, а так обычно решается тесселяцией.

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

C>>Кроме того, как будешь сортировать по глубине классические "три
C>>треугольника"?
F>Насколько я понимаю в WPF такая ситуация невозможна, а так обычно решается тесселяцией.

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

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

VD>Я вот уверен в обратном.
Зря. Позавчера разговаривал с представителем МС на эту тему.
VD>Тут нужно подходить с точки зрения экономики. С этой точки зрения существуют только рынки (рыночные ниши). И если МС не создает продукт для некоторой ОС, то это всего лишь означает, что она упускает эту рыночную нишу.
Это только в том случае, если продукт является прибыльным.

Влад, пойми — все приплясывания МС вокруг .Net и Visual Studio — это всего лишь инструмент по увеличению продаж лицензий на винду. Точка. Это их позиция.
В частности, поэтому они забивают на непригодность ASP.NET для шаред хостинга. Микрософт не интересует повышение плотности хостинга. Скорее наоборот: они бы предпочли, чтобы народ приобретал по win2k3 Enterprize на каждый веб-домен, даже если это domain parking, а не реальное приложение.

Каждая инсталляция линукса на сервере — это штука баксов, вынутая прямо из кармана
Билла Гейтса. Вот недавно IIS начал кампанию по поддержке PHP. Почему? Да потому, что хотят облегчить миграцию amateur сайтов под IIS. Чтобы если кто-то вдруг задумается насчет перевести сервер на винду, то ничего ему не помешало.

В обратном переходе они как раз очень мало заинтересованы. Поддержка CLR на тех платформах, за которые в кассу редмонда не идет бабло, интересует их постольку поскольку. Психологический фактор для тех, кто решает вложиться в дотнет девелопмент: "мы всегда сможем перейти на моно, если микрософт нас не устроит". Маркетинговый фактор третьего порядка малости. Причем обрати внимание: микрософт совершенно не хочет, чтобы этот переход действительно случился. Именно потому, что основная прибыль — это продажи платформы и офиса. Само количество инсталляций CLR их вовсе не интересует. Не больше, чем толпы голодающих в Нигерии интересуют производителей сникерса. Рынок огромен, но кому он нафиг уперся, если там не готовы платить?

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

F>Насколько я понимаю в WPF такая ситуация невозможна, а так обычно решается тесселяцией.

Нету там тесселяции. После тесселяции не бывает никаких швов между смежными полигонами. А швы есть.
http://files.rsdn.ru/5161/XAMLPad.png

Там софтварная растеризация для альфа-маски, котороая потом используется в качестве текстуры.

Fdooch wrote:
> C>Ну так и чем нам тут сильно поможет Z-буффер?
> Да тем же чем и в остальных случаях, отсечет по глубине невидимые фрагменты.
Ну вот — в реальных сценах такого почти не будет.

> C>Кроме того, как будешь сортировать по глубине классические "три
> C>треугольника"?
> Насколько я понимаю в WPF такая ситуация невозможна, а так обычно
> решается тесселяцией.
Фига она решается. Тесселяция — не самый быстрый процесс, особенно если
его в runtime'е выполнять.

Posted via RSDN NNTP Server 2.1 beta

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

VD>>Тут нужно подходить с точки зрения экономики. С этой точки зрения существуют только рынки (рыночные ниши). И если МС не создает продукт для некоторой ОС, то это всего лишь означает, что она упускает эту рыночную нишу.
S>Это только в том случае, если продукт является прибыльным.

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

S>Влад, пойми — все приплясывания МС вокруг .Net и Visual Studio — это всего лишь инструмент по увеличению продаж лицензий на винду.

Зачем мне это объяснять? Ты это АВК объясни. Он вот считает, что от ОС особого дохода нет.

S>В частности, поэтому они забивают на непригодность ASP.NET для шаред хостинга.

А вот это уже интересно. То есть они забиват на часть рынка где могли бы работать их серверы и приносить доход. Прелесно. И как обосновывают? Мне кажется обоснование здесь одно. Они слили эту часть рынка и понимают, что конкуренция на нем так сильна, что денег им на этом рынке не снять.

S> Микрософт не интересует повышение плотности хостинга. Скорее наоборот: они бы предпочли, чтобы народ приобретал по win2k3 Enterprize на каждый веб-домен, даже если это domain parking, а не реальное приложение.

Это напоминает басню про 7 шапок из одной шкуры. Хотеть они могут все что угодно. Это экономика, сэр. В ней хотеть мало. Есть рынок который готов платить по 10 баксов в месяц. Рынок огромный. У нашего провайдера есть виртуальные хостинги где на одной машине живут тысячи сайтов. Все они регулярно платят деньги. Но вот ОС там — Линукс и Фришка.

S>Каждая инсталляция линукса на сервере — это штука баксов, вынутая прямо из кармана

Ой, если я так посчитаю, то мне вообще весь мир будет должен. Не серьезно это.

S>Билла Гейтса. Вот недавно IIS начал кампанию по поддержке PHP. Почему? Да потому, что хотят облегчить миграцию amateur сайтов под IIS. Чтобы если кто-то вдруг задумается насчет перевести сервер на винду, то ничего ему не помешало.

Ну, вот и подумай какой смысл в поддержке PHP если рынок мелкого хостинга для МС не интересен?

S>В обратном переходе они как раз очень мало заинтересованы.

Почему в обратном? Пойми. Никто никогда не перейдет на виндовс если он уже привык к Линукс/Фришке. По этому прежде чем переманивать нужно обеспечить людй:
1. Увереностью, что они не прилипнут к одной плаформе. Многие не приемлют решения МС только по этому.
2. Возможность плавной миграции.

Переводить под Виндовс сайт написанный на PHP — это глупость несусветная. Если уж кто-то захочет перйти на Виндовс-хостинг, то он будет дедлать это из-за возможности получить приемущества от чего-то. Например, от расширения выбора софта.

В таком ракурсе стратегия выглядит разумно. Мы сначала даем людям использовать АСП.НЭТ на сервере (кстати, это и так возможно через Моно), а потом показываем им замануху в виже MS SQL 2005, других сервисо, более качественой и полной реализации дотнета и основанных на нем подсистем. В итоге мы заставляем массу ползователей отказаться от Фришки с Линуксом и заплатить те саме тысячи долларов за ОС от МС. Да еще в пресрелизах напишем, что мол это обошлось людям дешевле, так как вместо дорогущего (как по цене, так и по обслуживанию) Оракла теперь он может использовать MS SQL...

S> Поддержка CLR на тех платформах, за которые в кассу редмонда не идет бабло, интересует их постольку поскольку. Психологический фактор для тех, кто решает вложиться в дотнет

Это тоже весомый фактор. Я не раз слышал слова вроде "C#? Да он же не кросплатформынй."

S>Само количество инсталляций CLR их вовсе не интересует.

Вот это правда. Иначе бы столь глупых поступков как невключнеие фрэймворка в сервиспаки для виндовс и рабухание его до 100 метров не случилось бы. Мне кажется это вообще бюракратический терроризм.

S> Не больше, чем толпы голодающих в Нигерии интересуют производителей сникерса. Рынок огромен, но кому он нафиг уперся, если там не готовы платить?

Кстати, о неграх... Гейтс вроде свое бабло им хочет оставить.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Зачем мне это объяснять? Ты это АВК объясни. Он вот считает, что от ОС особого дохода нет.

Не надо перевирать мои слова. Я сказал что МС приносит доход офис и винда. Вот точная цитата:

Вот только продукты МС это прежде всего Офис и, в меньшей степени, Windows. Девелоперское подразделение дохода не приносит

... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>

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

VD>>Зачем мне это объяснять? Ты это АВК объясни. Он вот считает, что от ОС особого дохода нет.

AVK>Не надо перевирать мои слова. Я сказал что МС приносит доход офис и винда. Вот точная цитата:
AVK>

Вот только продукты МС это прежде всего Офис и, в меньшей степени, Windows. Девелоперское подразделение дохода не приносит

И в чем перевирание? Это явное заблуждение.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, VladD2, Вы писали:
VD>Нишу он упускает по любому.

Влад, что такое "ниша"? Я так понял, что МС в первую очередь думает о прибылях.
VD>Другой вопрос сознательно ли это делается, или потому как "нешмагла". Прибыльность же вообще тяжело проверить пока не попробуешь.
В смысле? Прибыльность от бесплатного продукта может происходить только в том случае, если это продукт-комплемент к чему-то небесплатному.

S>>В частности, поэтому они забивают на непригодность ASP.NET для шаред хостинга.
VD>А вот это уже интересно. То есть они забиват на часть рынка где могли бы работать их серверы и приносить доход. Прелесно. И как обосновывают?
Никак. Мне пообещали дать координаты народа, который хоть что-то в этом понимает. Пока что все, с кем я общался по этому поводу, смотрят на меня как баран на новые ворота.

VD>Это напоминает басню про 7 шапок из одной шкуры. Хотеть они могут все что угодно. Это экономика, сэр. В ней хотеть мало. Есть рынок который готов платить по 10 баксов в месяц. Рынок огромный. У нашего провайдера есть виртуальные хостинги где на одной машине живут тысячи сайтов. Все они регулярно платят деньги. Но вот ОС там — Линукс и Фришка.
Угу. Совершенно верно. Кстати, для статик хостинга IIS еще лучше, чем всякие апачи. Банально благодаря более вылизанному коду. Уже шестерку крайне тяжело порвать; с ним успешно соперничает только lighttpd.

S>>Каждая инсталляция линукса на сервере — это штука баксов, вынутая прямо из кармана
VD>Ой, если я так посчитаю, то мне вообще весь мир будет должен. Не серьезно это.
Влад, это вполне серъезно. Уверяю тебя, именно так маркетологи и мыслят.

S>>Билла Гейтса. Вот недавно IIS начал кампанию по поддержке PHP. Почему? Да потому, что хотят облегчить миграцию amateur сайтов под IIS. Чтобы если кто-то вдруг задумается насчет перевести сервер на винду, то ничего ему не помешало.
VD>Ну, вот и подумай какой смысл в поддержке PHP если рынок мелкого хостинга для МС не интересен?
Я полагаю, что они всё же им заинтересовались, но считают, что легче заимплементить FastCGI и убедить народ мигрировать существующие приложения, чем доработать ASP.NET и подождать расширения рынка мелкого хостинга на нем. Впрочем, они инвестируют в расширение рынка мелкого хостинга на ASP.NET, хотя через ж.

S>>В обратном переходе они как раз очень мало заинтересованы.

VD>Почему в обратном? Пойми. Никто никогда не перейдет на виндовс если он уже привык к Линукс/Фришке.
Влад, это не совсем так. В бесспорности преимушества никса над виндой уверены только детишки, никогда не сталкивавшиеся с настоящим бизнесом. Недавний пример — GoDaddy смигрировался под винду, а у них больше двадцати миллионов доменов. Так что смигрируются только так — TCO у винды ниже.

Проблема с виндой именно в неэффективности шаред хостинга динамических приложений. К моему глубокому сожалению, как я уже сказал, МС предпочла поддерживать PHP, у которого плохая масштабируемость и низкий throughput, зато очень низкое ресурсопотребление. А могла бы разогнать ASP.NET.

VD>Переводить под Виндовс сайт написанный на PHP — это глупость несусветная. Если уж кто-то захочет перйти на Виндовс-хостинг, то он будет дедлать это из-за возможности получить приемущества от чего-то.
Решение о переходе на виндовс-хостинг принимает, грубо говоря, хостер. Если тебе предложат виндовс хостинг с поддержкой всей платформенной фигни (а PHP + MySQL = 99% от этих потребностей) за более дешевые деньги, чем линукс, то ты встанешь и перейдешь. Вот тебе и все преимущества. Ты же не думаешь, что МС стала поддерживать PHP просто так, от делать нечего? Уверяю тебя — компания с такой капитализацией никогда ничего не делает "просто так".

VD>Кстати, о неграх... Гейтс вроде свое бабло им хочет оставить.

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

VD>>>Зачем мне это объяснять? Ты это АВК объясни. Он вот считает, что от ОС особого дохода нет.

AVK>>Не надо перевирать мои слова. Я сказал что МС приносит доход офис и винда. Вот точная цитата:
AVK>>

Вот только продукты МС это прежде всего Офис и, в меньшей степени, Windows. Девелоперское подразделение дохода не приносит

VD>И в чем перевирание? Это явное заблуждение.

Раздел MS Annual Report за 2006 год, касающийся распределения прибыли по направлениям.

Sinclair wrote:
> Влад, это не совсем так. В бесспорности преимушества никса над виндой
> уверены только детишки, никогда не сталкивавшиеся с настоящим бизнесом.
> Недавний пример — GoDaddy смигрировался под винду, а у них больше
> двадцати миллионов доменов. Так что смигрируются только так — TCO у
> винды ниже.
GoDaddy смигрировал только запаркованые страницы

Так что доля IIS в
Инете сразу подскочила на заметную величину.

Так что, пример плохо.

Posted via RSDN NNTP Server 2.1 beta

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

C>Sinclair wrote:
>> Влад, это не совсем так. В бесспорности преимушества никса над виндой
>> уверены только детишки, никогда не сталкивавшиеся с настоящим бизнесом.
>> Недавний пример — GoDaddy смигрировался под винду, а у них больше
>> двадцати миллионов доменов. Так что смигрируются только так — TCO у
>> винды ниже.
C>GoDaddy смигрировал только запаркованые страницы

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

Sinclair wrote:
> C>GoDaddy смигрировал только запаркованые страницы
> Ну и что? Ведь смигрировали же. Значит, были причины.
Может предложение немного $$$ от MS?

> Почему-то апач перестал их устраивать для парковки.
Странно, а остальных регистраторов — устраивает.

> МС работает над тем, чтобы это была
> не последняя сделка. Проникновение винды в хостинг продолжается. Многие
> хостеры, которые раньше предлагали только линукс, начинают предлагать
> винду. Поддержка эквивалентной платформы — весомый стимул в пользу такой
> поддержки.
Хостеров с Виндой по разумным ценам — вообще мало. В основном,
предлагают выделенные серверы (причем реально выделенные).

Для Линукса сейчас, например, очень популярен виртуальный хостинг (на
основе OpenVZ и Virtuozzo), когда тебе дают виртуальную машину с
гарантией минимальной "тактовой частоты" и количества памяти. При этом
на один реальный сервер кладут десятки таких машин.

Posted via RSDN NNTP Server 2.1 beta

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

S>Здравствуйте, VladD2, Вы писали:
VD>>Нишу он упускает по любому.
S>

S>Влад, что такое "ниша"?

http://en.wikipedia.org/wiki/Market_niche

ЗЫ

Вообще, мне это становится не интересным. Так что закруглясь.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, Cyberax, Вы писали:
C>Может предложение немного $$$ от MS?
О да. Проще всего всё объяснить тем, что МС всем доплачивает за использование своих продуктов. Вот одно мне только странно: откуда у них тогда прибыли?
>> Почему-то апач перестал их устраивать для парковки.
C>Странно, а остальных регистраторов — устраивает.
Может, их тоже не устраивает. Только они пока не перешли по каким-то соображениям.
C>Хостеров с Виндой по разумным ценам — вообще мало. В основном,
C>предлагают выделенные серверы (причем реально выделенные).
Не только. Тот же dotster предлагает shared hosting и на винде.
C>Для Линукса сейчас, например, очень популярен виртуальный хостинг (на
C>основе OpenVZ и Virtuozzo), когда тебе дают виртуальную машину с
C>гарантией минимальной "тактовой частоты" и количества памяти. При этом
C>на один реальный сервер кладут десятки таких машин.
Открою тебе страшную тайну: мы выпускаем Virtuozzo не только под Linux.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

C>>Может предложение немного $$$ от MS?
S>О да. Проще всего всё объяснить тем, что МС всем доплачивает за использование своих продуктов. Вот одно мне только странно: откуда у них тогда прибыли?

Это работает примерно так. В дикой природе существа едят друг друга и это является обычным делом. А так называемым "цЫвилизованным" людям этого делать не удается — ну как-то неприлично и вообще, грязно, кровь течет... Но кушать кого-то все равно надо. Заметьте, не что-то кушать, а именно кого-то — своего конкурента. В этом суть. Поэтому люди придумали такую игру, называемую "бизнес". И в этой игре они друг друга виртуально едят. Практически это означает, что да, МС иногда, из стратегических соображений доплачивает некоторым за использование своих продуктов (ну ты же рыбак — понимаешь). Чтобы позже съесть их за завтраком и узурпировать результаты их работы. Это ни в коем случае не в упрек МС. Просто это работает примерно таким образом. А с "чистыми и светлыми идеями" и со "взором горящим" в бизнесе делать нечего.

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

C>Интресно, как быстро у них в Виндовой версии будут появляться фичи, которых нет в линуксовой версии?

[Mono:DLR] Hello, Dynamic Language Runtime-enabled World!

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Sinclair wrote:
> C>Может предложение немного $$$ от MS?
> О да. Проще всего всё объяснить тем, что МС всем доплачивает за
> использование своих продуктов. Вот одно мне только странно: откуда у них
> тогда прибыли?
Ну не всем, а два случая доплаты за использование .NET я точно знаю.

Называется это модным словом "маркетинг".

> C>Странно, а остальных регистраторов — устраивает.
> Может, их тоже не устраивает. Только они пока не перешли по каким-то
> соображениям.
Так ведь не перешли. А чтобы что-то устраивало на 100% — такого почти
никогда не бывает.

> C>Хостеров с Виндой по разумным ценам — вообще мало. В основном,
> C>предлагают выделенные серверы (причем реально выделенные).
> Не только. Тот же dotster предлагает shared hosting и на винде.
Есть у нас один такой (достался в наследство) на vpsland. Скажем так,
качество от Линуксового очень далеко.

> C>Для Линукса сейчас, например, очень популярен виртуальный хостинг (на
> C>основе OpenVZ и Virtuozzo), когда тебе дают виртуальную машину с
> C>гарантией минимальной "тактовой частоты" и количества памяти. При этом
> C>на один реальный сервер кладут десятки таких машин.
> Открою тебе страшную тайну: мы выпускаем Virtuozzo не только под Linux.
Так это вы его делаете

Posted via RSDN NNTP Server 2.1 beta

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

C>Ну вот — в реальных сценах такого почти не будет.
Почему? Есть хоть один полупрозрачный объект в сцене — уже выигрыш.

C>Фига она решается. Тесселяция — не самый быстрый процесс, особенно если
C>его в runtime'е выполнять.
Вы ее каждый кадр что ли собираетесь выполнять? Тесселяцию нужно произвести один раз при создании фигуры. Да и rendering в WPF вообще-то retained.
Или растеризовать ручками каждый кадр сложную самопересекающуюся полупрозрачную фигуру проще?

Fdooch wrote:
> C>Ну вот — в реальных сценах такого почти не будет.
> Почему? Есть хоть один полупрозрачный объект в сцене — уже выигрыш.
Фига. Z-буффер тоже не бесплатный (по памяти и по времени работы), так
что в части сцен будет выгоднее просто от него отказаться совсем.

> C>Фига она решается. Тесселяция — не самый быстрый процесс, особенно если
> C>его в runtime'е выполнять.
> Вы ее каждый кадр что ли собираетесь выполнять? Тесселяцию нужно
> произвести один раз при создании фигуры. Да и rendering в WPF вообще-то
> retained.
Фигуры-то у нас не статические. И сцена тоже может изменяться —
передвину треугольник и получим такую фигуру.

> Или растеризовать ручками каждый кадр сложную самопересекающуюся
> полупрозрачную фигуру проще?
А ничего другого не остается.

Posted via RSDN NNTP Server 2.1 beta

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

F>Вы ее каждый кадр что ли собираетесь выполнять? Тесселяцию нужно произвести один раз при создании фигуры. Да и rendering в WPF вообще-то retained.

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

F>Или растеризовать ручками каждый кадр сложную самопересекающуюся полупрозрачную фигуру проще?

Что характерно, да. Алгоритмически — на порядок проще. И как раз на сложных самопересекающихся фигурах (речь идет о десятках тысяч пересечений) любой тесселятор начинает тормозить, в то время как растеризатор продолжает нормально работать. Но зато на относительно простых полигонах, скажем до 500 точек, растеризация может быть в десятки раз дороже тесселляции.

	От:	Cyberax
	Дата:	01.05.07 07:52
	Оценка:	47 (5) +1

От:	Курилка	http://kirya.narod.ru/
Дата:	01.05.07 08:05
Оценка:	+1 -3

От:	vguzev	http://u.pereslavl.ru/~vadim/MCSharp/
Дата:	01.05.07 11:38
Оценка:	3 (2)

От:	VladD2	www.nemerle.org
Дата:	01.05.07 17:48
Оценка:

	От:	no4
	Дата:	02.05.07 06:53
	Оценка:

От:	McSeem2	http://www.antigrain.com
Дата:	04.05.07 00:39
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	04.05.07 08:27
Оценка:	1 (1) +3

От:	ShaggyOwl	http://www.rsdn.org
Дата:	04.05.07 09:54
Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	06.05.07 05:02
Оценка:

	От:	Слоноежик
	Дата:	10.05.07 07:47
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	14.05.07 09:01
Оценка:	21 (4) +2

	От:	EvilChild
	Дата:	03.05.07 20:29
	Оценка:

	От:	alexeiz
	Дата:	05.05.07 22:20
	Оценка: