VBNet - Форум - Полная деградация .NET

Вопрос: Полная деградация .NET Добавлено: 28.05.10 19:30

Автор вопроса: VβÐUηìt | Web-сайт: смекаешь.рф

Ненене, народ, это совсем не топик для холиваров :) Я про другое. В общем, есть большой раста-проект (over 200'000 строк), написанных на MFC C++. Нужно внедрить в него WPF-контрол. Возможен ли такой путь:

WPF суем в WPF-контейнер на WindowsForms-контрол, ставим галочку "COM-видимость", каким-то чудеснейшим образом делаем из него ActiveX OCX, и затем мирно кидаем на диалог C++.

Вот только сделать из него ActiveX в ноль не получается. Грустно просто вообще. Какие еще есть варианты внедрения WPF в C++?

1) То что я описал
2) Ручная работа с COM на C++ (буээээ)
3) Вообще работаем с WPF в отдельном процессе и через расшаренную память трахаемся с ее отрендеренным результатом (да-да, как всегда)

У кого какое мнение есть на этот счет? Как сунуть WPF в MFC?

Вариант "Перепеши 200'000 строк на C# и XAML и не парься" не вариант :)
Ответить

Ответы Всего ответов: 10

Номер ответа: 1 Автор ответа: Uhehesh Вопросов: 4 Ответов: 42	Web-сайт: mda.net.ru Профиль \| \| #1	Добавлено: 28.05.10 21:29
	Перепиши не 200 тысяч строк, а 190, выкинь лишние 10 тысяч - это мусор. Ответить

Номер ответа: 2 Автор ответа: Sharp Лидер форума ICQ: 216865379 Вопросов: 106 Ответов: 9979	Web-сайт: sharpc.livejournal.com Профиль \| \| #2	Добавлено: 28.05.10 21:42
	Второй вариант, используй ATL и буэ не будет. Ответить

Номер ответа: 3 Автор ответа: VβÐUηìt Вопросов: 246 Ответов: 3333	Web-сайт: смекаешь.рф Профиль \| \| #3	Добавлено: 28.05.10 22:17
	Точно? Хм... Попробуем. Сенкс. Ответить

Номер ответа: 4 Автор ответа: EROS Вопросов: 58 Ответов: 4255	Профиль \| \| #4	Добавлено: 28.05.10 22:40
	WPF в C++ я считаю это идиотизмом.. зачем скрещивать страуса с бегемотом??? Чего в WPF такого, чего нельзя сдлеать в сях? Ответить

Номер ответа: 5 Автор ответа: VβÐUηìt Вопросов: 246 Ответов: 3333	Web-сайт: смекаешь.рф Профиль \| \| #5	Добавлено: 28.05.10 22:59
	Не, я не спорю, что в сях можно все. Нужно лютое, бешеное количество пафосных 3D и 2D спецэффектов типа анимации или вращающегося в 3D видео, которое играется в реальном времени (по-настоящему нужно, это не очередной мой впендреж. Будь это выпендрежем, проблемы с программой на C++ в 200'000 бы не было ) При этом это все должно быть доступно для среднестатистического пользователя, то есть чувак может к C++-программе написать свой красивенький эффект. Конечно, можно на C++ написать жирный SDK для графики на базе DirectX, но во-первых очень и очень труднозатратно и долгоотлаживаемо, во-вторых... зачем делать это, если это уже сделали? Пишешь себе XAML-файлик, раз - и готово. Реализация графики на C++ требует огромных трудозатрат, нежели в WPF. Поэтому, если мы воткнем WPF в C++, то графику станет делать проще, и можно будет ее реализовывать в больших количествах. Не спорю, ручками она будет рендерится быстрее и оптимальнее, и возможностей для разработки будет моря. Но. Это делать должен не только я, но и любой человек, садящийся за программу и имеющий необходимость прикрутить пафосный прибамбас со сложностью, не превозходящую VBA в ворде. Самый разумный выход - я думаю вы согласитесь - это WPF. Плюс он позволит дальше весьма энергично развивать графику в программе. Поэтому я и решил WPF в C++ Ибо подключить WPF в MFC, я думаю, все же легче, чем написать свой WPF Ответить

Номер ответа: 6 Автор ответа: Artyom Разработчик Вопросов: 130 Ответов: 6602	Профиль \| \| #6	Добавлено: 28.05.10 23:34
	Во-первых, 3D модель в WPF довольно убогая, поэтому никаких спецэфектов не получится (по крайней мере сравнимых с теми чтоб можно сделать в самом С++ на DirectX). Текстуры, базовые возможности освещения, афинные трансформации, спорная возможность использовать шейдеры, это в принципе все что там есть. Во-вторых, вообще графическая модель в WPF очень тормознутая, при этом даже оперирование сотней элементов (2D - не 3D!) на форме начинает доставлять своими тормозами (видеокарта, аппаратное ускорение, все это имеется, и именно это прикалывает больше всего, смотреть как простейшая 2D графика тормозит на видеокарте за 100 баксов). Разумеется, на С++ + DirectX можно обойтись без тормозов В-третьих, если все-таки очень хочется, на .NET делается программа с окном на WPF, и ставится дочерним для окна в твоей программе на С++. Коммуникацию между .NET и С++ прилоежнием придумай как сделать - SendMessage, NamedPipes. Вобщем примерно так как в IE8 сделано. Ответить

Номер ответа: 7 Автор ответа: Artyom Разработчик Вопросов: 130 Ответов: 6602	Профиль \| \| #7	Добавлено: 29.05.10 07:34
	Кстати, самое интересное - наблюдать как после очередного мажорного изменения XAML простейшая графика начинает работать в разы медленнее, при этом догружая проц до 100% (читай - вываливается в программный рендеринг), и искать из-за какого именно элемента все вывалилось. А потом обнаружить что перестановка в XAML двух элементов местами оживляет аппаратное ускорение (это при том что на экране все как было так и осталось). Опять же, речь пока идет только о 2D-графике. Ответить

Номер ответа: 8 Автор ответа: VβÐUηìt Вопросов: 246 Ответов: 3333	Web-сайт: смекаешь.рф Профиль \| \| #8	Добавлено: 29.05.10 15:37
	Artyom пишет: Во-первых, 3D модель в WPF довольно убогая, поэтому никаких спецэфектов не получится (по крайней мере сравнимых с теми чтоб можно сделать в самом С++ на DirectX). Текстуры, базовые возможности освещения, афинные трансформации, спорная возможность использовать шейдеры, это в принципе все что там есть. Это понятно, но оно хотя бы ЕСТЬ (!). Я имею в виду не Crysis, а хотя-бы 3D-поворот. Artyom пишет: Во-вторых, вообще графическая модель в WPF очень тормознутая, при этом даже оперирование сотней элементов (2D - не 3D!) на форме начинает доставлять своими тормозами (видеокарта, аппаратное ускорение, все это имеется, и именно это прикалывает больше всего, смотреть как простейшая 2D графика тормозит на видеокарте за 100 баксов). Разумеется, на С++ + DirectX можно обойтись без тормозов Вася будет далеко не Full-Screen и полгонов будет не много (от силы штук 200). Так что все путем. Плюс, сколько я работаю с WPF, тормозов не замечал (даже когда импортировал непростые модели из 3Dmax). В MSDN там у них все написано, кто кого жрет. Вот, например, BitmapEffect всегда выполняется процессором. Потому тень и ореол жрут много. Выход - делаем PNG-ореол и меняем прозрачность Ну как вариант. Да и примерно можно смекнуть, почему он вдруг жрать больше начинает. Artyom пишет: В-третьих, если все-таки очень хочется, на .NET делается программа с окном на WPF, и ставится дочерним для окна в твоей программе на С++. Коммуникацию между .NET и С++ прилоежнием придумай как сделать - SendMessage, NamedPipes. Вобщем примерно так как в IE8 сделано. Да, я изначально к этому варианту склонялся, но все таки хотелось более Ъ интеграции. Artyom пишет: Кстати, самое интересное - наблюдать как после очередного мажорного изменения XAML простейшая графика начинает работать в разы медленнее, при этом догружая проц до 100% (читай - вываливается в программный рендеринг), и искать из-за какого именно элемента все вывалилось. А потом обнаружить что перестановка в XAML двух элементов местами оживляет аппаратное ускорение (это при том что на экране все как было так и осталось). Видимо, дело в порядке отрисовки. Типа А на B наложить просто, а B на A - сложно. Поэтому посылаем видеокарту надувать дирежабли и делаем все с процессором. Ответить

Номер ответа: 9 Автор ответа: Artyom Разработчик Вопросов: 130 Ответов: 6602	Профиль \| \| #9	Добавлено: 31.05.10 12:15
	http://msdn.microsoft.com/en-us/library/ms742522.aspx Ответить

Номер ответа: 10 Автор ответа: VβÐUηìt Вопросов: 246 Ответов: 3333	Web-сайт: смекаешь.рф Профиль \| \| #10	Добавлено: 31.05.10 17:50
	Спасибо большое! Ответить

Страница: 1 |