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

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

MM>>Да ладно. Раньше WPF точно также не работал с DirectX напрямую, а использовал milcore.dll.

V>Все структуры и константы, описывающие примитивы, преобразования и т.д. — напрямую из DirectX.
В силу того, что я не являюсь знатоком DirectX, я просто с ходу приведу тебе несколько структур, и надеюсь ты напишешь, к какой части DirectX они относятся. Вот, например, MILCMD_GUIDELINESET, MIL_SEGMENT_POLY и MILCMD_ELLIPSEGEOMETRY.

V>А прослойка эта была связана скорее всего в несовместимостью самого DirectX м/у версиями 9.0 и теми, что выше. У меня и в нативной части приложения был некий слой-абстракция, обеспечивающий единый АПИ для разных версий DirectX.
Что значит "была связана", когда она так и осталась. Почитай уже хоть Википедию что-ли.

MM>>Да что ты привязался к этим панелям В них же простейший код! Тормоза начинаются там, где нужно считать место для геометрий и глифов, в которые в итоге выливаются все элементы. Этим занимается unmanaged.

V>Это он на первый взгляд простейший, но смотри далее, что скрывается за каждым обновлением. Фишка форматирования в том, что оно может сбрасываться и начинаться заново, и так до полного "утрясания". Это весьма нагрузочный код для большого кол-ва элементов и большой их вложенности. И managed-тормоза тут связаны с медленным проходам по массивам в managed. Я уже приводил тут данные, что числодробильные алгоритмы работают в managed в 3-5 раз медленнее. Что есть числодробильные алгоритмы? Это обычно довольно примитивные вычисления на каждом шаге цикла, но при большом кол-ве итераций. Медленно дотнет итерирует, се ля ви.
Вот и славно! Осталось MS переписать код измерения и компоновки в панелях через unsafe и чудеса — WPF ускорится в 3-5 раз!

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

E__>У эппла остались их процессоры?

В смысле — их? Своих процов у них никогда не было.

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

NBN>В смысле — их? Своих процов у них никогда не было.

Недавно купили контору. Теперь есть.
Но речь не об этом была.

E__>>>>Предложившего этот путь быстрее самого предадут анафеме.

__>>>Раскажите это Эпл.

M>>А что ей рассказывать? Байткод их процессоры точно не выполняют. Даже в случае с бойкотом сторонних языков, который уже снят, на айфоне работал Objective-C и Javascript, что уже никак нельзя считать одним языком

E__>У эппла остались их процессоры?

Я имел в виду, процессоры, что используются в их продуктах

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

П>Если есть быстрая реализация на C, ВСЕГДА можно создать эквивалентную по производительности на С++.

Если есть быстрая реализация на C, то С++ не нужен

Приветствую, Eugeny__, вы писали:

E> Расскажите это маньякам, которые запустили на айфоне Убунту.

Так... Вот теперь я хочу iPhone...

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


MM>Вот и славно! Осталось MS переписать код измерения и компоновки в панелях через unsafe и чудеса — WPF ускорится в 3-5 раз!

Да весь код в нейтив переписать придется, ибо начинать надо будет с контейнеров, которые должны будут хранить нейтивные указатели. В общем, WPF вполне подходит для "формочек", но Word, IE И прочее MS упорно переписывает на нейтиве. Причем, с Офиса 2007, насколько я вижу, рендеринг в Word был переделан практически полностью. А ведь WPF уже был достаточно mature на тот момент. Странно, что эти "мелочи" усиленно игнорируются оппонентами.

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

MM>В силу того, что я не являюсь знатоком DirectX, я просто с ходу приведу тебе несколько структур, и надеюсь ты напишешь, к какой части DirectX они относятся. Вот, например, MILCMD_GUIDELINESET, MIL_SEGMENT_POLY и MILCMD_ELLIPSEGEOMETRY.

А это полный список? Лень посмотреть остальное?

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

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

MM>>В силу того, что я не являюсь знатоком DirectX, я просто с ходу приведу тебе несколько структур, и надеюсь ты напишешь, к какой части DirectX они относятся. Вот, например, MILCMD_GUIDELINESET, MIL_SEGMENT_POLY и MILCMD_ELLIPSEGEOMETRY.

V>А это полный список? Лень посмотреть остальное?
Предлагаешь мне выложить сюда все типы из System.Windows.Media.Composition? Полный список смотри Рефлектором, а здесь будь добр, подтверди свои слова о том, что "Все структуры и константы, описывающие примитивы, преобразования и т.д. — напрямую из DirectX"

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

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


MM>>Вот и славно! Осталось MS переписать код измерения и компоновки в панелях через unsafe и чудеса — WPF ускорится в 3-5 раз!

V>Да весь код в нейтив переписать придется, ибо начинать надо будет с контейнеров, которые должны будут хранить нейтивные указатели. В общем, WPF вполне подходит для "формочек", но Word, IE И прочее MS упорно переписывает на нейтиве.
Переписывания там очень малая часть. Врядли на каждый релиз хотябы 50% кода переписывается.

V>Причем, с Офиса 2007, насколько я вижу, рендеринг в Word был переделан практически полностью. А ведь WPF уже был достаточно mature на тот момент.
Ага учитывая что WPF появился аж в начале 2007 года, а офис 2007 начали делать гораздо раньше.

V>Странно, что эти "мелочи" усиленно игнорируются оппонентами.
Просто оппоненты понимают что переписывать существующий софт только ради managed смысла нет. Вообще нет.

Вот для VS2010 был смысл, потому что очень хотели модульности и безопасности, получилось. А переписывать word\excel на managed смысла нет, это ничего кроме турдозатрат не даст. Офисные приложения и так умеют запускать addin_ы на управляемом коде, большего от них не требуется. А сам MS совершенно не стесняется писать на .NET тот же самый power pivot для excel.

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

V>Да весь код в нейтив переписать придется, ибо начинать надо будет с контейнеров, которые должны будут хранить нейтивные указатели. В общем, WPF вполне подходит для "формочек", но Word, IE И прочее MS упорно переписывает на нейтиве.

Если точнее, то никто это не переписывает.

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


MM>Да что ты привязался к этим панелям В них же простейший код! Тормоза начинаются там, где нужно считать место для геометрий и глифов, в которые в итоге выливаются все элементы. Этим занимается unmanaged.

Кстати говоря, как выяснилось, та же нехалтурная отрисовка шрифтов из managed нехило жрет процессор...

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

MM>Предлагаешь мне выложить сюда все типы из System.Windows.Media.Composition? Полный список смотри Рефлектором, а здесь будь добр, подтверди свои слова о том, что "Все структуры и константы, описывающие примитивы, преобразования и т.д. — напрямую из DirectX"

Раз уж пошла такая пьянка, опять взял в руки шашки, хоть и не люблю WPF.

Да, насчет "всех" погорячился, согласен. Подробно рассматривал WPF в 2006-м, мог детали забыть. Однако, прекрасно помню, что глаз цеплялся за много чего до боли знакомого из DirectX.

Опять же, с чего начался и о чем идет спор? Меня пытались убедить, что низкоуровневый лейаут выполняется в нейтиве. Это не так. Или как минимум путаница терминов. Нейтивный хелпер даже не производит отображение визуального дерева на сцену из DirectX (!!!). Т.е. ни то что лейаутом, он даже рендерингом не занимается (повторюсь, за исключением старой версии Effects, которые выполнялись основным процом, а не видюхой, тут действительно обсуждаемый нейтив-хелпер участвовал, но это скорее минус, чем плюс. )

Ты там говорил что-то о подсчетах размеров геометрий, думая что там причина тормозов. Неграмотно. Эти вещи у глифов подсчитываются лишь однократно и кешируются до изменения самого глифа/шейпа. Опять же, для подсчета размеров глифов используется DirectX (методы типа: GetDesignGlyphMetric()/GetGdiCompatibleGlyphMetrics(), которые соответствуют managed опциям: Ideal/Display). Т.е. нативный хелпер и этим тоже не занимается. Да и не может, ибо у него недостаточно информации, в отличие от драйвера видюхи.

ИМХО, причина создание прослойки-хелпера в в основном в том,чтобы уменьшить кол-во вызовов managed-unmanaged. Ну ты бы хоть посмотрел, как формируется конвеер команд. Там в буфер происходит сериализация следующего вида (один из популярных методов):

public override unsafe void RenderDataDrawingContext::DrawGeometry(Brush brush, Pen pen, Geometry geometry)
{
    this.VerifyApiNonstructuralChange();
    if (((brush != null) || (pen != null)) && (geometry != null))
    {
        this.EnsureRenderData();
        MILCMD_DRAW_GEOMETRY milcmd_draw_geometry = new MILCMD_DRAW_GEOMETRY(this._renderData.AddDependentResource(brush), this._renderData.AddDependentResource(pen), this._renderData.AddDependentResource(geometry));
        this._renderData.WriteDataRecord(MILCMD.MilDrawGeometry, (byte*) &milcmd_draw_geometry, 0x10);
    }
}

Ключевое здесь: MILCMD.MilDrawGeometry. Сравни со следующим методом из DirectX:

virtual void ID2D1RenderTarget::DrawGeometry(
  [in]            ID2D1Geometry *geometry,
  [in]            ID2D1Brush *brush,
                  FLOAT strokeWidth = 1.0f,
  [in, optional]  ID2D1StrokeStyle *strokeStyle = NULL
) = 0;

strokeWidth/strokeStyle — это описание объекта pen для outline (опционально).

Конечно глаз цепляется за такие вещи при просмотре кода рефлектором, ибо видно соответствие 1:1.

Итого, с managed стороны сериализуется набор команд для рендеринга вида: {cmd, data}, и затем за 1 вызов managed/unmanaged эта сериализованная последовательность "проигрывается" с unmanaged стороны, что в большинстве случаев сводится к вызову указанного в MILCMD соотв. метода из DirectX.

Надеюсь, теперь понятно, почему я говорил, что обсуждаемый нативный хелпер даже не занимается отображением VisualTree на сцену DirectX?

Этим занимается именно managed код, кодируя "отложенные" вызовы DirectX, которые затем весьма тупо проигрываются нативным хелпером. То бишь, при подробном изучении WPF, создается стойкое впечатление, что этот нативный хелпер нужен исключительно затем, чтобы уменьшить кол-во пересечений границ managed/unmanaged при вызовах. Ибо вызовы эти тяжеловаты, из-за маршаллинга данных и организации фреймов стека. Особенно все грустно для COM-интерфейсов в MTA, если сам объект был создан в STA-треде (а оно почти всегда так для GUI-приложений), ибо непонятно за каким чертом, но среда исполнения на каждый вызов запрашивает COM-объект на предмет собственного интерфейса-маршаллера, и эти вызовы получения интерфейсов вовсе не бесплатны. Как буд-то нельзя было вызвать и запомнить? Так что я (и не только) поступаю аналогично в мультимедиа-проектах, пряча COM-интерфейсы за своими прослойками, и заодно повышая уровень абстракции, чтобы за один вызов из managed сделать как можно больше операций.

Понятное дело, что вся схема слегка оптимизирована, то бишь во время того самого обновления лейаута пересоздается сериализованная последовательность команд отрисовки лишь для изменяемых элементов, и затем все эти закодированные последовательности команд проигрываются без участия managed стороны. Вот и получается, что сливать в "бутылочное горлышко", а затем разливать из него эффективнее, чем вызывать последовательность команд для рендеринга напрямую из managed, проходясь по VisualTree.

Так что повторю, с чего начал: из опыта WPF делать на дотнете Word или web-browser было бы глупо, по сегодняшнему состоянию дел.

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


V>>Да весь код в нейтив переписать придется, ибо начинать надо будет с контейнеров, которые должны будут хранить нейтивные указатели. В общем, WPF вполне подходит для "формочек", но Word, IE И прочее MS упорно переписывает на нейтиве.
G>Переписывания там очень малая часть. Врядли на каждый релиз хотябы 50% кода переписывается.

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


V>>Причем, с Офиса 2007, насколько я вижу, рендеринг в Word был переделан практически полностью. А ведь WPF уже был достаточно mature на тот момент.
G>Ага учитывая что WPF появился аж в начале 2007 года, а офис 2007 начали делать гораздо раньше.

В ноябре 2006-го. И подозреваю, что делать начали гораздо раньше. И контора, вроде, та же самая.


G>Просто оппоненты понимают что переписывать существующий софт только ради managed смысла нет. Вообще нет.

А как же разрекламировананя легкость добавления сомна новых фич?
Но на самом деле тут дело немного в другом. Покажи-ка мне адекватный OLE-клиент и OLE-сервер на дотнете?
Я в упор не понимаю, почему MS их не сделало. Делал когда-то сам OLE-клиент, так там работы — замахаешься, несколько десятков COM-интерфейсов пришлось реализовать/поддержать/интероперировать. От мысли реализовать OLE-сервер я просто отказался. Ибо в простом режиме неинтересно, а в windowless (офигенная фича OLE/ActiveX, если честно) не умеет работать Windows.Forms, как бы я ее уже не хакал. Настолько жесткая завязка на HWND, что попахивает инженерным идиотизмом, особенно при наличии уже около 15-ти лет хорошей иерархии интерфейсов OLE/ActiveX, которые прекрасно от конкретного экземпляра HWND абстрагируются.

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


V>>>Причем, с Офиса 2007, насколько я вижу, рендеринг в Word был переделан практически полностью. А ведь WPF уже был достаточно mature на тот момент.
G>>Ага учитывая что WPF появился аж в начале 2007 года, а офис 2007 начали делать гораздо раньше.

V>В ноябре 2006-го. И подозреваю, что делать начали гораздо раньше. И контора, вроде, та же самая.


G>>Просто оппоненты понимают что переписывать существующий софт только ради managed смысла нет. Вообще нет.

V>А как же разрекламировананя легкость добавления сомна новых фич?
Это ты сам придумал?

V>Но на самом деле тут дело немного в другом. Покажи-ка мне адекватный OLE-клиент и OLE-сервер на дотнете?
V>Я в упор не понимаю, почему MS их не сделало. Делал когда-то сам OLE-клиент, так там работы — замахаешься, несколько десятков COM-интерфейсов пришлось реализовать/поддержать/интероперировать. От мысли реализовать OLE-сервер я просто отказался. Ибо в простом режиме неинтересно, а в windowless (офигенная фича OLE/ActiveX, если честно) не умеет работать Windows.Forms, как бы я ее уже не хакал. Настолько жесткая завязка на HWND, что попахивает инженерным идиотизмом, особенно при наличии уже около 15-ти лет хорошей иерархии интерфейсов OLE/ActiveX, которые прекрасно от конкретного экземпляра HWND абстрагируются.

Это ты вообще к чему все привел? Померяться фичами?
Покажи SOAP или Odata клиент или сервер на unmanaged...
WWS появился только около года назад и то с довольно хреновой лицензионной политикой, а ручками там писать ого-го. Не дай бог никому работать с soap из umanaged через сокеты\wininet.

Что касается интерфейса, то политика MS очевидна в этом вопросе: забить на Winforms (windows контролы)\activex и использовать WPF. Возможно мы в скором времени увидим unmanaged WPF работающий на том же нэйтивном движке. Winforms\activex саппортятся только для обратной совместимости, еще много кто по историческим причинам их использует.

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

V>>А как же разрекламировананя легкость добавления сомна новых фич?
G>Это ты сам придумал?

Ты действительно проспал все здешние обсуждения native vs managed?


V>>Но на самом деле тут дело немного в другом. Покажи-ка мне адекватный OLE-клиент и OLE-сервер на дотнете?
V>>Я в упор не понимаю, почему MS их не сделало. Делал когда-то сам OLE-клиент, так там работы — замахаешься, несколько десятков COM-интерфейсов пришлось реализовать/поддержать/интероперировать. От мысли реализовать OLE-сервер я просто отказался. Ибо в простом режиме неинтересно, а в windowless (офигенная фича OLE/ActiveX, если честно) не умеет работать Windows.Forms, как бы я ее уже не хакал. Настолько жесткая завязка на HWND, что попахивает инженерным идиотизмом, особенно при наличии уже около 15-ти лет хорошей иерархии интерфейсов OLE/ActiveX, которые прекрасно от конкретного экземпляра HWND абстрагируются.

G>Это ты вообще к чему все привел? Померяться фичами?
G>Покажи SOAP или Odata клиент или сервер на unmanaged...
G>WWS появился только около года назад и то с довольно хреновой лицензионной политикой, а ручками там писать ого-го. Не дай бог никому работать с soap из umanaged через сокеты\wininet.

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


G>Что касается интерфейса, то политика MS очевидна в этом вопросе: забить на Winforms (windows контролы)\activex и использовать WPF.

Уже 4 года прошло с выхода WPF, уже Висту сменила Win7, но никакой очевидности. Из какого пальца ты это высасываешь?
Не вижу аналога GUI OLE-сервера на дотнете, коими являются приложения офиса, autocad и т.д. И, похоже, ты не понимаешь, о чем речь.


G>Возможно мы в скором времени увидим unmanaged WPF работающий на том же нэйтивном движке.

Ключевое выделил. Это пять!!! Все-таки, ты страшно далек от темы.

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

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

V>>>А как же разрекламировананя легкость добавления сомна новых фич?
G>>Это ты сам придумал?

V>Ты действительно проспал все здешние обсуждения native vs managed?

Я не пойму как легкость добавления новых фич связана с языком\платформой. Думаешь добавить фичу это всего лишь закодить её?
При этом надо не забывать о полном переписывании на managed для получения непонятно каких преимуществ.


G>>Что касается интерфейса, то политика MS очевидна в этом вопросе: забить на Winforms (windows контролы)\activex и использовать WPF.

V>Уже 4 года прошло с выхода WPF, уже Висту сменила Win7, но никакой очевидности. Из какого пальца ты это высасываешь?
Ты время разработки оцениваешь? Виста вышла 30 ноября 2006 года. Семерка начала разрабатываться примерно в это время, при этом ничего кардинально нового в семерке нет. Просто допилили висту до адекватного состояния. откуда там взяться WPF?

V>Не вижу аналога GUI OLE-сервера на дотнете, коими являются приложения офиса, autocad и т.д. И, похоже, ты не понимаешь, о чем речь.
А я не вижу в unmanaged коде работы с вебом, и похоже ты не понимаешь о чем речь.

G>>Возможно мы в скором времени увидим unmanaged WPF работающий на том же нэйтивном движке.
V>Ключевое выделил. Это пять!!! Все-таки, ты страшно далек от темы.
От какой темы? Ты пытаешься сравнивать исключительно UI десктопных приложений. Во-первых это сильно застойная область, во-вторых далеко не самая большая. При этом ты почему-то пытаешься делать выводы о всем .NET и его применимости. Ну это как минимум неправильно.

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


G>>>Возможно мы в скором времени увидим unmanaged WPF работающий на том же нэйтивном движке.
V>>Ключевое выделил. Это пять!!! Все-таки, ты страшно далек от темы.
G>От какой темы? Ты пытаешься сравнивать исключительно UI десктопных приложений. Во-первых это сильно застойная область, во-вторых далеко не самая большая. При этом ты почему-то пытаешься делать выводы о всем .NET и его применимости. Ну это как минимум неправильно.

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

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

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


G>>>>Возможно мы в скором времени увидим unmanaged WPF работающий на том же нэйтивном движке.
V>>>Ключевое выделил. Это пять!!! Все-таки, ты страшно далек от темы.
G>>От какой темы? Ты пытаешься сравнивать исключительно UI десктопных приложений. Во-первых это сильно застойная область, во-вторых далеко не самая большая. При этом ты почему-то пытаешься делать выводы о всем .NET и его применимости. Ну это как минимум неправильно.

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

VS2010 тебе контрпример.

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

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

G>VS2010 тебе контрпример.

Редактор текста там разве дотнетный? А компиляторы?
Из дотнетного я вижу пока только GUI, но! Это же специальный тул для специальных людей, готовых идти на компромиссы в целях разработки.

Опять же, речь шла о больших документах со сложным форматированием. Где ты видел, чтобы студия оперировала большими документами?