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

G>Практика как всегда критерий истины, и именно она подсказывает что в общем случае выгоднее делать бизнес-приложения на вебе, чем на десктомных технологиях. Частные случаи, в которых верно обратное остаются частными случаями. Можешь еще хоть сто сообщений написать про печать со смартфона, 10 сканирований в секунду, летающий remote desktop, выполнение запроса между перезаписями файлов на сервере но на практике такого один на миллион.
Господи, ну это же полная чушь. Как только в ветку приходит gandjustas, она сразу превращается в простыню водяных сообщений с кучей базвордов и, как уже было верно подмечено, заведомо ложной информацией. Спор превращается в пустой треп

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

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

G>>Практика как всегда критерий истины, и именно она подсказывает что в общем случае выгоднее делать бизнес-приложения на вебе, чем на десктомных технологиях. Частные случаи, в которых верно обратное остаются частными случаями. Можешь еще хоть сто сообщений написать про печать со смартфона, 10 сканирований в секунду, летающий remote desktop, выполнение запроса между перезаписями файлов на сервере но на практике такого один на миллион.
MM>Господи, ну это же полная чушь.
Товарищ, что из этого чушь? То что большинство приложений делается на вебе? Или то что печать со смартфона — очень редкий кейс?

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

G>Товарищ, что из этого чушь? То что большинство приложений делается на вебе? Или то что печать со смартфона — очень редкий кейс?

Да и то, и другое

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

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

G>>Товарищ, что из этого чушь? То что большинство приложений делается на вебе? Или то что печать со смартфона — очень редкий кейс?

A>Да и то, и другое

Доказательства?

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

G>>>Товарищ, что из этого чушь? То что большинство приложений делается на вебе? Или то что печать со смартфона — очень редкий кейс?
A>>Да и то, и другое
G>Доказательства?

Э нет, это мой вопрос. Где доказательства, что на вебе делается больше приложений? Про печать со смартфона я с тобой даже говорить не хочу, ещё вчера ты понятия не имел что принтер может быть установлен в машине торогового агента. Сперва наберись опыта, а потом обсуждай энтерпрайз.

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

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

G>>>>Товарищ, что из этого чушь? То что большинство приложений делается на вебе? Или то что печать со смартфона — очень редкий кейс?
A>>>Да и то, и другое
G>>Доказательства?

A>Э нет, это мой вопрос. Где доказательства, что на вебе делается больше приложений?
Прямых как-бы нет. Никто точно не скажет. Но гугл по запросу "web business application" выдает в 2 раза больше результатов, чем "desktop business application", да и статистика потребностей технологий что здесь приводилась тоже косвенно о таком говорит.

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

A>Сперва наберись опыта, а потом обсуждай энтерпрайз.
Мне опыта хватает, я кучу разных "энтерпрайзов" видел.

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

A>>Э нет, это мой вопрос. Где доказательства, что на вебе делается больше приложений?
G>Прямых как-бы нет.

Ну вот и ладненько.

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

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

A>>>Э нет, это мой вопрос. Где доказательства, что на вебе делается больше приложений?
G>>Прямых как-бы нет.

A>Ну вот и ладненько.

Ок, съехал.

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

A>Здравствуйте, Аноним, Вы писали:

А>>Нус, расскажи как с твоими познаниями "как работает видеокарта" GDI оказывается в выигрыше перед DirectX.

A>Даю намёк для проспавших последние 10 лет в тайге: у видеокарты и процессора память не общая и любое использование GPU требует копирования данных.

Круто !
Только для тех кто в тайге :

1) Видеокарта позволяет копировать данные не только из памяти с которой работает процессор, у нее есть собственная
Например картинку на кнопке WPF загружает в видеопамять как текстуру и ее "копирование" из видеопаямти в видеопамять занимает намного меньше времени
2) Уже давно для плоской графики используется Direct3d , чтобы отрисовать прямоугольник для кнопки достаточно передать координаты вершин и цвет, не нужно копировать каждый пиксель. Для кнопки 50х20 ~ 4 кб информации по каждому пикселю, в случае DirectX < 100 байт.
3) GDI при операциях с видео осуществляет переключение в режим ядра, что существенно замедляет работу, в отличии от DirectX, который собственно для этого и создавали чтобы работать на прямую.


Но ты так и не раскрыл тайну о своих "познаниях как работает видеокарта" , которые позволяют производить какую либо отрисовку через GDI быстрее чем это можно сделать через DirectX.

Ушел за следующей порцией попкорна.

Здравствуйте, Аноним, Вы писали:

я отвечу

А>1) Видеокарта позволяет копировать данные не только из памяти с которой работает процессор, у нее есть собственная
А>Например картинку на кнопке WPF загружает в видеопамять как текстуру и ее "копирование" из видеопаямти в видеопамять занимает намного меньше времени

операция загрузки текстуры относительно медленная это раз,
два, тестура хранится целиком и занимает видео память, и если вам нужно отрисовать 10 тыщ картинок, то в GDI вы упретесь только в размер основной памяти, а в Direct3D у вас в распоряжении только видеопамять
причем вы эту память еще и с другими 3д приложениями делите и сам загрузка 10 тыщ изображдений не такая уж и быстрая и 10000 команд тоже не быстро будут обработаны, потому что сначала изменения помещаются в очередь вфп, а из неё в очередь графического проца, а потом еще дождаться презентации буфера — вот отсюда ноги лага растут всего что Direct3d использует, а в ГДИ всё рисуется напрямую одним вызовом и с немедленным отображением результата.
именно поэтому все современные игры сначала загружают данные в видеопамять, а потом запускают уровень, потому что ЦПУ-ГПУ это до сих пор очень узкое место.

в общем: если у вас 2д изображение часто и непредсказуемо меняется(например что-то рисуется), а не лепится из 10-20 кубиков, то впф будет сливаться по сравниению с гди, если бы это было не так мы бы уже давно имели принципиально новые 3д игры.
потому что заливка и особенно модификация данных в видеопамяти со стороны ЦПУ — это жопа, а логика у вас крутится на ЦПУ.
причем 3д играм проще, чем впф — они имеют право практически монопольно жрать весь ЦПУ и соотв использовать быстрые ожидания типа while(ждать_готовности_гпу) и получать максимальный фпс;
а впф такое запрещено, все ожидания должны быть сделаны через примитивы синхронизации.
поэтому в играх наш лаг можно сжать до минимума.

А>2) Уже давно для плоской графики используется Direct3d , чтобы отрисовать прямоугольник для кнопки достаточно передать координаты вершин и цвет, не нужно копировать каждый пиксель. Для кнопки 50х20 ~ 4 кб информации по каждому пикселю, в случае DirectX < 100 байт.

это тот слуай где 3д быстрее, но есть много случаев где он плох.
например вам нужно нарисовать случайное 2д изображение — для 3д это жопа. если вы не знали, у Direct3D вообще нет функций рисования, потому что там всё — геометрия, единственная функция — это залить цветом прямоугольник в текстуре.

А>3) GDI при операциях с видео осуществляет переключение в режим ядра, что существенно замедляет работу, в отличии от DirectX, который собственно для этого и создавали чтобы работать на прямую.

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

а DirectX назван не потому что вы с видухой напрямую общаетесь, а потому что это простенькая надстройка над драйвером, причем для GDI и DirectX драйвер реализует разный АПИ.
т.е. GDI не работает через DirectX, это независимая от DirectX функциональность, как минимум потому что она была до DirectX

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

K>Здравствуйте, Аноним, Вы писали:

K>я отвечу

А>>1) Видеокарта позволяет копировать данные не только из памяти с которой работает процессор, у нее есть собственная
А>>Например картинку на кнопке WPF загружает в видеопамять как текстуру и ее "копирование" из видеопаямти в видеопамять занимает намного меньше времени

K>операция загрузки текстуры относительно медленная это раз,
Это делается один раз. А не на каждую перерисовку формы, как в случае GDI.

K>два, тестура хранится целиком и занимает видео память, и если вам нужно отрисовать 10 тыщ картинок, то в GDI вы упретесь только в размер основной памяти, а в Direct3D у вас в распоряжении только видеопамять

Даже 10 тыщ иконок для кнопок по 4 кб каждая займут 40 Мб видеопамяти. Но даже в случае ее дефицита WPF может размещать данные и в оперативной памяти.
Так что он использует преимущество пока оно возможно. А GDI тормозит всегда.
В случае GDI порядка 10 тыщ кнопок вам вообще будет сложно сделать

Each time a window is opened, it consumes GDI objects. As the complexity of the window increases, with additional features such as buttons and images, its GDI object usage also increases. When too many objects are in use, Windows is unable to draw any more GDI objects, leading to misbehaving software and frozen and unresponsive program operation. [8][9] The total available GDI objects varies from one version of Windows to the next: Windows 95, 98, and Millennium had a limit of 1,200 total objects; Windows 2000 has a limit of 16,384 objects; and Windows XP, Vista, and Windows 7 have a configurable limit (via the registry) that defaults to 10,000 objects per process

K>причем вы эту память еще и с другими 3д приложениями делите и сам загрузка 10 тыщ изображдений не такая уж и быстрая и 10000 команд тоже не быстро будут обработаны, потому что сначала изменения помещаются в очередь вфп, а из неё в очередь графического проца, а потом еще дождаться презентации буфера — вот отсюда ноги лага растут всего что Direct3d использует, а в ГДИ всё рисуется напрямую одним вызовом и с немедленным отображением результата.

В GDI рисуется не все сразу а только то что делает конкретная команда, Rectangle, SetPixel и т.п.
Причем каждая команда вызывает переключение в режим ядра, что помимо копирования в видео создает дополнительные тормоза.
Попробуйте закрасить форму случайными пикселями при помощи GDI и сравните насколько быстрее это будет через DirectX, на 2 порядка.

K>именно поэтому все современные игры сначала загружают данные в видеопамять, а потом запускают уровень, потому что ЦПУ-ГПУ это до сих пор очень узкое место.

Именно поэтому современные игры пишутся на DirectX, а не на GDI. Потому что GDI заведомо тормоз.


K>в общем: если у вас 2д изображение часто и непредсказуемо меняется(например что-то рисуется), а не лепится из 10-20 кубиков, то впф будет сливаться по сравниению с гди, если бы это было не так мы бы уже давно имели принципиально новые 3д игры.

Если бы было по вашему то современные игры писали бы на GDI, однако я и другие разработчики предпочитают DirectX.

K>потому что заливка и особенно модификация данных в видеопамяти со стороны ЦПУ — это жопа, а логика у вас крутится на ЦПУ.
поэтому GDI и тормоз, т.к. он все делает на уровне ЦПУ, WPF использует возможности DirectX, для акселерации того же альфа-канала.

K>причем 3д играм проще, чем впф — они имеют право практически монопольно жрать весь ЦПУ и соотв использовать быстрые ожидания типа while(ждать_готовности_гпу) и получать максимальный фпс;

В играх много расчетов , в том числе физики. Например WinRar при архивации сжирает ЦПУ не меньше, однако никаких обновлений экрана не использует.

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

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

А>>2) Уже давно для плоской графики используется Direct3d , чтобы отрисовать прямоугольник для кнопки достаточно передать координаты вершин и цвет, не нужно копировать каждый пиксель. Для кнопки 50х20 ~ 4 кб информации по каждому пикселю, в случае DirectX < 100 байт.

K>это тот слуай где 3д быстрее, но есть много случаев где он плох.
K>например вам нужно нарисовать случайное 2д изображение — для 3д это жопа. если вы не знали, у Direct3D вообще нет функций рисования, потому что там всё — геометрия, единственная функция — это залить цветом прямоугольник в текстуре.
Слишком бедные у вас представления, а как же вершинные и пискельные шейдеры, на которых можно сделать практически любую анимацию без постоянной передачи данных от ЦПУ в ГПУ.
Понятие случайное 2D изображение для бизнес приложения это какой-то бред. Когда в тех же играх делают "шум" из пикселей раньше использовали готовые текстурки с рандомными пикселями, сейчас используют шейдеры.
Но в бизнес приложениях с обычными кнопками это вообще не нужно.


А>>3) GDI при операциях с видео осуществляет переключение в режим ядра, что существенно замедляет работу, в отличии от DirectX, который собственно для этого и создавали чтобы работать на прямую.

K>неверно,
K>данные в GPU может передавать только кернел-драйвер, это именно тот который вы ставите чтобы видуха заработала, а он работает с портами и поэтому не может не быть в 0 кольце

Речь не про драйвер а про взаимодействие USER приложение через GDI с драйвером.

K>т.е. GDI не работает через DirectX, это независимая от DirectX функциональность, как минимум потому что она была до DirectX
само собой. Читайте выше.

Я и не говорил что GDI работает через DirectX, подумайте лучше зачем сделали DirectX когда была GDI.

И собственно так и не дали самого важного ответа — приведите конкретный практический пример любой отрисовки ( можно в исходном коде ) где GDI будет быстрее DirectX.
Все ваши попытки как-то представить белое черным как раз противоречат практике , которая подтверждает что GDI на порядок тормознее чем отрисовка через DirectX.

Здравствуйте, Аноним, Вы писали:

K>>операция загрузки текстуры относительно медленная это раз,
А>Это делается один раз. А не на каждую перерисовку формы, как в случае GDI.

Медленный старт приложений крайне характерен для WPF. Причём, когда я говорю медленный, я имею ввиду десятки секунд и минуты. Помимо прочего, вы предполагаете что все текстуры поместятся в видео-память. Это, вообще говоря, не всегда правда и тогда загрудка в видео-память может повторятся. Кроме того, DirectX, через который работает WPF, может по своей воле выгружать текстуры из видео-памяти. WPF использует DirectX в неэксклюзивном режиме и вытеснение WPF приложения нормальная ситуация. Интенсивное использование видеопамяти в неэксклюзивном режиме весьма неудачная практика. Если с обычной памятью GC может производить дефрагментацию, то с видео-памятью такого сделать нельзя. Получаем с WPF старые известные проблемы, которые уже встречались при использовании Large Object Heap. WPF фрагментирует видео-память. Это неизбежно. Как и в случае с LOH, это может приводить (и приводит) к досрочным OutOfMemory.

А>Даже 10 тыщ иконок для кнопок по 4 кб каждая займут 40 Мб видеопамяти. Но даже в случае ее дефицита WPF может размещать данные и в оперативной памяти.

Нет. В оперативное памяти текстуры находятся всегда. Прости некоторые из них находятся ещё и в видео-памяти. Потом вы в корне не правы расчитывая объём текстур. Надо понимать что разного рода эффекты могут требовать дополнительных redder target, так что под окно может быть более двух (а два есть всегда) буферов.

А>

А>Each time a window is opened, it consumes GDI objects. As the complexity of the window increases, with additional features such as buttons and images, its GDI object usage also increases. When too many objects are in use, Windows is unable to draw any more GDI objects, leading to misbehaving software and frozen and unresponsive program operation. [8][9] The total available GDI objects varies from one version of Windows to the next: Windows 95, 98, and Millennium had a limit of 1,200 total objects; Windows 2000 has a limit of 16,384 objects; and Windows XP, Vista, and Windows 7 have a configurable limit (via the registry) that defaults to 10,000 objects per process

Объекты GDI не имеют вообще никакого отношения к возможности отрисовать 10000 текстур. Вы плохо знаете GDI.

А>В GDI рисуется не все сразу а только то что делает конкретная команда, Rectangle, SetPixel и т.п.

Вы приводете заведомо ложные факты. GdiGetBatchLimit, GdiSetBatchLimit, GdiFlush.

А>Причем каждая команда вызывает переключение в режим ядра, что помимо копирования в видео создает дополнительные тормоза.

Смю выше.

K>>именно поэтому все современные игры сначала загружают данные в видеопамять, а потом запускают уровень, потому что ЦПУ-ГПУ это до сих пор очень узкое место.
А>Именно поэтому современные игры пишутся на DirectX, а не на GDI. Потому что GDI заведомо тормоз.

Да нет, для многих современных(!) игр DirectX такой overkill, что придумали Direct2D. Причём Direct2D придумали даже не потому что GDI чем-то не устраивал, а потому что там архитектурная жопа с разного рода прозрачностями.

А>Если бы было по вашему то современные игры писали бы на GDI, однако я и другие разработчики предпочитают DirectX.

Разработчики игр пишут не на DX/OGL, а на ешйдерах, это дань моде. Шейдеры из GDI не доступны. Скорость отрисовки тут уже не так важна. GDI ещё использует аппаратное ускорение, а вот есть в Windows програмный рендерер WARP10, применяемый в терминальной сессии. На нём Crysis даёт не меньше 5 FPS на i5. Так что для большиства казуальных игр скорости GDI хватает выше крыши и причины использования DirectX совсем другие.

K>>потому что заливка и особенно модификация данных в видеопамяти со стороны ЦПУ — это жопа, а логика у вас крутится на ЦПУ.
А>поэтому GDI и тормоз, т.к. он все делает на уровне ЦПУ, WPF использует возможности DirectX, для акселерации того же альфа-канала.

Вы опять приводете заведомо ложные факты. GDI не всё делает через CPU. http://msdn.microsoft.com/en-us/library/ff729480%28VS.85%29.aspx

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

А отчёты?

А>Слишком бедные у вас представления, а как же вершинные и пискельные шейдеры, на которых можно сделать практически любую анимацию без постоянной передачи данных от ЦПУ в ГПУ.

А как же Intel GMA? Или по вашему в офисном компьютере сплошь последние GeForce'ы? Наивные вещи говорите.

А>Я и не говорил что GDI работает через DirectX, подумайте лучше зачем сделали DirectX когда была GDI.

DirectX был заменой WinG/DCI а вовсе не GDI.

А>И собственно так и не дали самого важного ответа — приведите конкретный практический пример любой отрисовки ( можно в исходном коде ) где GDI будет быстрее DirectX.
А>Все ваши попытки как-то представить белое черным как раз противоречат практике, которая подтверждает что GDI на порядок тормознее чем отрисовка через DirectX.

Практически любые аналитические графики.

Здравствуйте, Аноним, Вы писали:

А>Даже 10 тыщ иконок для кнопок по 4 кб каждая займут 40 Мб видеопамяти. Но даже в случае ее дефицита WPF может размещать данные и в оперативной памяти.
А>Так что он использует преимущество пока оно возможно. А GDI тормозит всегда.
А>В случае GDI порядка 10 тыщ кнопок вам вообще будет сложно сделать

мне не обязательо хранить хендлы для всех картинок, которые нада нарисовать.

А>В GDI рисуется не все сразу а только то что делает конкретная команда, Rectangle, SetPixel и т.п.
А>Причем каждая команда вызывает переключение в режим ядра, что помимо копирования в видео создает дополнительные тормоза.
А>Попробуйте закрасить форму случайными пикселями при помощи GDI и сравните насколько быстрее это будет через DirectX, на 2 порядка.

ну вы просто не в курсе, обращение напрямую к данным текстуры это операция которая еще медленнее чем любой GDI вызов, настолько медленная, что в комменде разработчкиов 3д движка можно по роже получить за использование ее там, где ее необходимость не критическая

А>Именно поэтому современные игры пишутся на DirectX, а не на GDI. Потому что GDI заведомо тормоз.

они пишутся потому что директе разрабатывался для них и заточен под них и потому что там есть 3D API.
но и там можно GDI использовать если нужно что-то рисовать, IDirect3DSurface9->GetDC и вперёд.

А>Если бы было по вашему то современные игры писали бы на GDI, однако я и другие разработчики предпочитают DirectX.

что-то не заметно, что вы директ знаете

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


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

А>Слишком бедные у вас представления, а как же вершинные и пискельные шейдеры, на которых можно сделать практически любую анимацию без постоянной передачи данных от ЦПУ в ГПУ.
А>Понятие случайное 2D изображение для бизнес приложения это какой-то бред. Когда в тех же играх делают "шум" из пикселей раньше использовали готовые текстурки с рандомными пикселями, сейчас используют шейдеры.
А>Но в бизнес приложениях с обычными кнопками это вообще не нужно.

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


А>Речь не про драйвер а про взаимодействие USER приложение через GDI с драйвером.

это всё не важно и ГДИ и ВФП в итоге отсылает данные драйверу, в любом случае.

А>И собственно так и не дали самого важного ответа — приведите конкретный практический пример любой отрисовки ( можно в исходном коде ) где GDI будет быстрее DirectX.
А>Все ваши попытки как-то представить белое черным как раз противоречат практике , которая подтверждает что GDI на порядок тормознее чем отрисовка через DirectX.

к примеру — рендер HTML`я, и Firefox5 тому пример, жрет больше, а толку не видно

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

A>Медленный старт приложений крайне характерен для WPF. Причём, когда я говорю медленный, я имею ввиду десятки секунд и минуты. Помимо прочего, вы предполагаете что все текстуры поместятся в видео-память. Это, вообще говоря, не всегда правда и тогда загрудка в видео-память может повторятся. Кроме того, DirectX, через который работает WPF, может по своей воле выгружать текстуры из видео-памяти. WPF использует DirectX в неэксклюзивном режиме и вытеснение WPF приложения нормальная ситуация. Интенсивное использование видеопамяти в неэксклюзивном режиме весьма неудачная практика. Если с обычной памятью GC может производить дефрагментацию, то с видео-памятью такого сделать нельзя. Получаем с WPF старые известные проблемы, которые уже встречались при использовании Large Object Heap. WPF фрагментирует видео-память. Это неизбежно. Как и в случае с LOH, это может приводить (и приводит) к досрочным OutOfMemory.

тут я честно говоря не уверен, в директх данные в видеопамяти хранятся в управялемой куче и чтобы получить указатель на что-то в видеопамяти нада делать Lock/Unlock
и я так понимаю он как минимум может делать дефрагментацию, а делает или нет это вопрос. мож и не делает

но всё остальное — верно

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

K>тут я честно говоря не уверен, в директх данные в видеопамяти хранятся в управялемой куче и чтобы получить указатель на что-то в видеопамяти нада делать Lock/Unlock
K>и я так понимаю он как минимум может делать дефрагментацию, а делает или нет это вопрос. мож и не делает
K>но всё остальное — верно

Для дефрагментации нужно два условия
1) Двойная косвенность: указатель на указатель на память.
2) Копирование данных.

Я легко могу поверить в первое, но в то что DirectX копирует текстуры из одной области видеопамяти в другой (да ещё и по своей воле) верится с трудом.

Lock/Unlock это не pin памяти, а копирование. В Lock/Map передаётся LockFlags/D3D11_MAP в которых указано что можно делать, а что нельзя. Если бы это был просто pin, зачем возможность делать read-only/write-only Lock/Map?

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

A>Медленный старт приложений крайне характерен для WPF. Причём, когда я говорю медленный, я имею ввиду десятки секунд и минуты.
И все же это характерно только для первого старта. Последующие гораздо быстрее.

A>Помимо прочего, вы предполагаете что все текстуры поместятся в видео-память. Это, вообще говоря, не всегда правда и тогда загрудка в видео-память может повторятся. Кроме того, DirectX, через который работает WPF, может по своей воле выгружать текстуры из видео-памяти. WPF использует DirectX в неэксклюзивном режиме и вытеснение WPF приложения нормальная ситуация. Интенсивное использование видеопамяти в неэксклюзивном режиме весьма неудачная практика. Если с обычной памятью GC может производить дефрагментацию, то с видео-памятью такого сделать нельзя. Получаем с WPF старые известные проблемы, которые уже встречались при использовании Large Object Heap. WPF фрагментирует видео-память. Это неизбежно. Как и в случае с LOH, это может приводить (и приводит) к досрочным OutOfMemory.
Так GC вообще никакого отношения к видеопамяти не имеет. Если, конечно, мы о .Net-овском GC.

А>>И собственно так и не дали самого важного ответа — приведите конкретный практический пример любой отрисовки ( можно в исходном коде ) где GDI будет быстрее DirectX.
А>>Все ваши попытки как-то представить белое черным как раз противоречат практике, которая подтверждает что GDI на порядок тормознее чем отрисовка через DirectX.
A>Практически любые аналитические графики.
В общем я согласен, что графикам тяжеловато на WPF. Из-за необходимости показывать большее число объектов, нужно заниматься оптимизацией. Но интересно вот что. Картинка в WPF и в GDI несколько различаются. В WPF есть сглаживание, есть субпиксельный рендеринг. Так ли аналогичен результат вывода обеих технологий, чтобы просто сравнивать время?

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

A>>Медленный старт приложений крайне характерен для WPF. Причём, когда я говорю медленный, я имею ввиду десятки секунд и минуты.
MM>И все же это характерно только для первого старта. Последующие гораздо быстрее.

Ну ОС тоже не дура, кеширует. prefetch опять же.

MM>Так GC вообще никакого отношения к видеопамяти не имеет. Если, конечно, мы о .Net-овском GC.

Объекты в видеопамяти разве не привязаны к объектам GC?

MM>В общем я согласен, что графикам тяжеловато на WPF. Из-за необходимости показывать большее число объектов, нужно заниматься оптимизацией. Но интересно вот что. Картинка в WPF и в GDI несколько различаются. В WPF есть сглаживание, есть субпиксельный рендеринг. Так ли аналогичен результат вывода обеих технологий, чтобы просто сравнивать время?

Ну в GDI+ субпиксельный рендеринг и сглаживание точно есть и он полностью на CPU (в отличие от GDI). Что касается аналогичности... ну я не буду долго говорить про шрифты которые в 4.0 уже можно читать, но всё же не так всё круто как могло бы быть.

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

MM>>Так GC вообще никакого отношения к видеопамяти не имеет. Если, конечно, мы о .Net-овском GC.
A>Объекты в видеопамяти разве не привязаны к объектам GC?
Ну не знаю. Напрямую .Net-ные объекты не вызывают методы DirectX. Кисти и тому подобные используют какие-то каналы: есть такие методы AddRefOnChannel и ReleaseRefOnChannel. Я не знаком с API DirectX, возможно тебе эти методы о чем-то говорят, но выглядит скорее, как API нативной части WPF, и фиг пойми, как она распоряжается ресурсами.

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

MM>>>Так GC вообще никакого отношения к видеопамяти не имеет. Если, конечно, мы о .Net-овском GC.
A>>Объекты в видеопамяти разве не привязаны к объектам GC?
MM>Ну не знаю. Напрямую .Net-ные объекты не вызывают методы DirectX. Кисти и тому подобные используют какие-то каналы: есть такие методы AddRefOnChannel и ReleaseRefOnChannel. Я не знаком с API DirectX, возможно тебе эти методы о чем-то говорят, но выглядит скорее, как API нативной части WPF, и фиг пойми, как она распоряжается ресурсами.

Как я уже говорил, DirectX может самопроизвольно выгружать ресурсы переводя их в Lost состояние, там что-то вроде вытесняющего кеша. Это обёрнуто в СОМ (упомянутые тобой AddRef/Release), а СОМ обёрнут в .Net/GC. Аж три перпендикулярные идеологии Мне сложно гарантированно предсказать поведение, я могу лишь высказывать обоснованные предположения.

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

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

MM>>Так что получается, любой WPF контент считается трехмерной сценой.

K>ессно,и я вообще думал что наши впфники догадываются откуда растут ноги у впфных шейдеров, 3д трансформаций, способов задания 3д объектов и прочего

эээ... мужики, вы чо, издеваетесь? Я знал, что в ДиректИксе есть "чистое 2D", но то, что мелкие извращенцы вместо него заюзают 3D — я не мог и в кошмарном сне представить!!! Всё, мои возражения снимаются — WPF ещё больший сакс, чем я думал!! (((((((