It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have a WPF application, and part of the screen shows an object that needs to be rendered dynamically in 3D, at perhaps 20 FPS. I understand that typically a WPF application would use DirectX to do the 3D rendering. (I also understand that WFP has a simplified 3D API, but I don't think that would work in my case because I have too many triangles to render.) In my case, I would like to use OpenGL because there is a good chance the whole application will be ported to a non-Windows machine, and I don't want to have to rewrite the 3D code.
I see there have been some attempts to create a WPF control into which OpenGL can render directly, but they all seem a bit too rough/risky to use.
As a safer approach, I thought I could use FBOs with OpenGL to render the frames off-screen, and then take the bitmaps and pass them off, in real time, to WPF as regular 2D images.
My question is about speed. Do you anticipate there being deal-breaking bottlenecks in this scheme? I assume the FBO rendering will be about as fast as direct window rendering on the OpenGL side? And I expect that extracting the bitmaps from the rendered OpenGL images (FBOs) should be fast? I'm less sure about handing those images off to WFP and seeing them update at 20 FPS.
Do you have concrete experience that can help me decide if this is a reasonable way to go?
I would like to use OpenGL because there is a good chance the whole
application will be ported to a non-Windows machine
But then it means you have to rewrite your whole WPF app too as this framework is not cross-platform.So in such a case OpenGL part will be only of minor concern here.I think you should re-consider the whole UI tech.For example I would use Qt SDK as it is truly cross platform and you can connect it with both DirectX and OpenGL at will.
But if you plan to stick with WPF on Windows and using OpenGL just use C# OpenGL wrapper.
Yes you will get some performance overhead because that is a wrapper.Just like those for Java (JOGL , LWJGL).But still games like MineCraft were originally written and worked fine with these APIs.
Another , more challenging approach,is to WPF COM interop and call some C++ app that wraps your OpenGL renderer directly from WPF may be even using unsafe mode to get as low level as possible.Never tried it myself but it may get you a better performance.But that is a lot of work actually.
Finally I would suggest you using DirectX for Windows as WPF has the best integration with it naturally.If you design your app well then it won't be a problem to connect it to OpenGL backend later.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm starting to architect a new Windows application that will require a fairly rich client interface, but I have no idea what client API I should go with (WPF, Silverlight, WinRT, HTML5, other?). I'm actually rather disturbed that there is so little guidance from MS to help people make this decision.
Whats the MS support strategy for the different client APIs? Whats the longevity for each? I dont want to write a full client application in a currently known and supported API (WinForms or WPF) only to have MS pull support for it in two years, and be forced to re-write it. But I really cant write it in WinRT because mass corporate deployment wont be in place for at least 2 years. So am I forced to go with a web based approach, like Silverlight instead? Whats its support/longevity story? Do I go HTML5 instead? If I go that route, whats the benefit of using the Microsoft stack instead of just going the open source stack?
It feels like I'm in a total catch 22 here, and I cant find any good guidance from Microsoft. From the sounds of things it would be stupid to write software in WPF because its being dropped (soon?), but I cant write it in WinRT because corporations wont deploy it for a couple years. This whole thing just feels completely skitsofrantic to me.
Thoughts or ideas?
Taking your experience into account, and also the fact that you said 'Windows Application' (not web application) I would definitely go with WPF. Keep in mind that regardless of using a different set of underlying APIs, WinRT still keeps the core concepts of WPF: XAML, Bindings, Styles, Triggers, DataTemplates and so on. So, while it is true that you cannot copypaste code from WPF to WinRT and press F5, there is a significant amount of work that would be compatible between these technologies (namely ViewModels that are view-agnostic), while HTML, Winforms and other frameworks have completely different ways of doing things, and require a different mindset to work with.
In regards of what will Microsoft do.. I wouldn't be too worried, because evidence shows that even older technologies such as VB6 still remain "runnable" in current versions of OSes, and I don't think there will be a need to rewrite the whole application in 2 years even if Metro becomes a standard. Metro cannot replace desktop traditional applications, which still prove to be the best option for data intensive applications.
And, if it ever comes the time when all of us are really pushed into WinRT, it's gonna be immensely easier for those who made SL / WPF applications already written using MVVM and XAML, than for those who did HTML or winforms.
Whatever you end up choosing, make sure you separate as much as possible your application's functionality from the UI. This will definitely make it a lot easier when a UI framework change is required.
This is just my personal opinion, and I would like to hear what other people have to say about this subject too.
Edit: Another really important aspect is that if you need to really make an animation-intensive UI, or take a step away from traditional battleship-gray UIs, you're gonna end up suffering a lot from winforms incapabilities on this, or HTML/Javascript hell where all browsers render things differently, not to mention the amount of code required in these technologies to achieve things that require 3 lines of XAML in WPF / SL / WinRT.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to do graphics program by OpenGL. But I don't have any experienced in windows programming. Any suggestion?
See these links
lazy foo tutorial for SDL to simplify some file and inputs handling
SDL and OpenGL
Kore engine uses Opengl and SDL and is open source
Kore Engine wiki Some more info on the Kore Engine
My own project using SDL and OPENGL host on Google code
Note that you'll need to code in C++ with those links
EDIT:
I tried GLUT and SFML, and both are easier to use than SDL and OpenGL alone.
GLUT is pretty straightforward but is limited in its scope.
SFML brings the good things of SDL and OpenGL, but with a nice C++ interface instead of the old C interface of SDL and raw OpenGL calls (which are still possible to do). Big performance gain out of the box for the same project, SFML is just better optimized than my own code with SDL.
But I don't have any experienced in windows programming. Any suggestion?
Well, you need to create a window somehow, so that the user can see the beautiful pictures you'll draw using OpenGL. But you're right: Opening a window and creating a OpenGL context is tedious, no matter which OS you're doing it on (the most simple one would be probably NSOpenGLView of MacOS X).
Luckily there are some libraries that abstract away the OS dependent parts of creating a window and creating and attaching a OpenGL context to it.
GLUT is probably the oldest one of those. I discourage using the original GLUT and recommend to use FreeGLUT or OpenGLUT instead, as those are actively maintained. They are easy to use. But GLUT don't give you control over the event loop which essentially means, it's ill suited for creating games.
SDL is actually a whole bunch of sub-libraries, the main library providing creating of windows. Also provides OpenGL support, but has not been tailored for it. Personally these days I'd use SDL for everything but creation of a OpenGL window. But it's fine for audio, loading graphics and such.
GLFW is IMHO one of the nicest OpenGL frameworks out there. It has a well designed API, gives you full control over the event loop and is actively maintained. Also it focuses on exactly one task: Create a OpenGL window and provide a message pump for user input.
I’m working on creating a full-screen 3-D app (based on Johnny Lee's Wii head tracking app) with some augmented reality features, and it seems that WPF is too slow to render even the simple models I’m using at a reasonable frame rate. I think the problem is that I need to change both the view and projection of the camera on just about every frame, because of the nature of the app (it uses a web cam to track your face, and uses that data to move the camera around and change its perspective).
I've spent a lot of time trying to narrow down the problem, and it's definitely related to the graphics, and not the speed of the head-tracking API that I'm using. Also, I recreated the app in XNA, and it seems to work fine there (28 FPS versus 9 in WPF). Finally, when I remove the "walls" or make the window much smaller (say, 800 x 600), WPF's performance greatly improves, which makes me think that the bottleneck is the graphics calculations.
As a result, I need to either find a new graphics back-end to work with, or find a way to make WPF much faster for this app. I’m mostly looking at DirectX and XNA, and possibly OpenGL. Any recommendations on which of these APIs would be best to use for this app in .NET? Or alternatively, any idea what I'm doing wrong in WPF that's slowing things down?
I've not done enough with 3D in WPF to be able to say what could be causing the slowness, but I did notice that it's model datastructure isn't very efficient. While this might not be the cause it could be symptomatic of general slowness to the whole pipeline.
One thing that does spring to mind is that WPF is rendering the scene in software rather than using the hardware acceleration on the graphics card. The fact that you get better performance (though you don't say how much better) with a smaller window.
If you remove any textures from your model do you get better performance too?
I don't think it really matters whether you go for Direct3D or OpenGL - virtually all modern cards support them equally well. XNA is the obvious choice if you're sticking with .NET as it's integrated into Visual Studio - even the Express edition.
I would check out SlimDX, a much thinner DirectX wrapper than XNA or WPF
The problem with changing the projection on every frame is that API's like XNA/WPF werent designed with this in mind, so were optimized to have projection set once in the initialization phase, then not again.
I would suggest a hybrid choice here: use WPF for what its good at (Windows UI, composition, etc) and use XNA to render the 3D. There are samples out there that demonstrates combining XNA with WinForms. It should be possible to do the same "trick" to render XNA onto surfaces in WPF.
Update: there are supposedly issues with using XNA directly with WPF. This thread indicates that using XNA with WinForms and then hosting the WinForms control in WPF is a workaround to these issues. I've not tested this myself though (yet).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
WPF is positioned as a successor to WinForms, but given Microsoft's practice of abandoning toolkits (and what I perceive a s"bloat" in WPF), are there any recommended alternatives?
I don't think you need to worry about WPF being abandoned. WinForm was around for a long time, and WPF is the replacement.
Bloat? I don't know. It seems like a huge upgrade from WinForms to me. If there's bloat it's always going to be there because underneath everything is the Win32 API. Until that gets rewritten from scratch I don't think anything will be perfect. And since every toolkit targeted at the Windows platform has to deal with that, I had rather go with WPF and ReSharper.
Another sign Microsoft is serious about WPF is that it's getting used to make Visual Studio 2010. XAML seems to get used by more than just WPF (Workflow Foundation, Communication Foundation).
I've been coding in WinForms for the past 5 years and I was a bit sceptic of WPF too at first. But after reading a few books and trying out my first application in WPF I'm starting to see the beauty of it!
I keep amazing myself at how little "glue" code is needed in a WPF application compared to how I would have done it in WinForms. Here's an example: I had to show a simple histogram. In WinForms I would have written a custom control and handled the rendering myself. In WPF, I did it all from xaml without one line of code! I just bound the data samples to a list box, replaced the listbox's layout template to an horizontal stack panel, and replaced the item template to rectangles which height is bound to the sample values!
MS does not have a practice of abandoning toolkits (WinForms, MFC, ActiveX and Win32 are all still being actively developed) and the "bloat" is actually new capabilities you may not need right now but there's a good chance you'll need in the future.
If you don't want bloat and use only an API that will be impossible for MS to stop supporting you are more then welcome to work with the Win32 API directly.
I believe 4 out of 5 developers never ever look beyond the surface of a technology, they just want to drag & drop a few controls, write a few lines of code and get something up & running, maybe googling for some samples to help iron out a few kinks, and that's it. To such folks, bloat is not a word in their dictionary.
I, for one, prefer to look under the covers and really figure out how a technology actually works before jumping into writing code using the technology. Today, I spent an hour or so to investigate how the WPF built-in commands work, and with the help of reflector i managed to track down how a simple built-in Cut command is executed for a plain-vanilla textbox control, and guess what, by the time the text changed event is raised for a cut operation, there are around 30 calls on the call stack, isn't that code bloat?
WPF certainly has many powerful functionalities, but they do come at a cost. In some ways, i feel that WPF is to WinForms what MFC is to Win32 API; both WPF and MFC has the word "Foundation" at least :), but it would be interesting to watch if WPF will come to the same fate of MFC.
It depends on your favorite programming language, but Qt is a good Gui toolkit for C++. It has impressive features, is free and as platform independent as it gets for GUI toolkits.
Qt Quick (QML) is the way to go. It has extremely sharp design, and it is kept from being polluted by XML unreadability.
Adobe AIR is the strong competitor. If you aim to create cross-platform applications with rich user interface, check out this one.
First of all, I love WPF! I don't see any elegant/immediate way to achieve the same functionality and flexibility for designing interfaces in WinForms... That said, it is very sad to see that WPF is not anymore in favor inside Microsoft. Actually some people, including 'insiders' have stated that MS has shifted focus form WPF, and the Silverlight is now THE Windows Phone 7 application framework (not something to supplant Flash anymore):
http://www.theregister.co.uk/2010/09/09/microsoft_html_5/
Many people, including the current WPF Leader, denies this, but I see that this may actually have some truth behind. HTML5 is certainly going to become the "de facto" standard for rich (web)client interfaces. It overlaps so much with WPF, and does many other things too. It can "easily" be extended to work for non-web rich-client applications, and I believe MS will invest in that to have the lead in development tools for both web, mobile and windows targets.
I would not fear abandonment if I was already in the middle of a WPF project, but I wouldn't start one in WPF either as many have already said: it is not that simple to abandon something like WPF without giving a migration path and supporting it for many years.
So, current alternatives for WPF in the MS world? I don't think we have one already, maybe using its subset in Silverlight is the way to go for now. But, in the upcoming years HTML5 will probably be THE alternative to WPF.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
Has anyone got experience with the white framework?
www.codeplex.com/white ?
I'm thinking about using it for the next project for basic smoke tests of our windows client. I'd like some advice on articles or your own experiences. Thanks.
I recently used white to build a few (20+) UI tests for a fairly complex WinForms app with plenty of UserControls, dynamically created and 3rd-party controls.
Here are my impressions:
Very easy and intuitive to work with.
Little or no quality issues.
It's a young project so there are
some missing features, but they've
got the basics covered.
Occasionally, if a control didn't have a known AutomationID, I was forced to use keystrokes to navigate to and manipulate a control ("tab, tab, enter" for example) which was kind of a bummer, but still very easy to do in white. This usually only happened with 3rd-party or dynamically generated controls.
White's recorder is helpful (and will actually generate code for you) but does often get confused by complicated or unusual controls. For that reason I'd recommend that you...
...keep UISpy nearby so you can see the AutomationID of the controls you're working with.
And finally, if you're like me, you're hoping to set up some automated tests. This can be tricky since an automated test will usually be run by a CI tool such as CruiseControl which runs as a Windows service, which therefore has no active graphical environment (Windows session)...which white requires. The suggested way around this is to use a virtual machine. This is where I lost steam, as my tool chain had just grown too large for my purposes: CruiseControl->NAnt->NUnit->white + virtual machine.
Anyway, hope that's useful.
I evaluated it recently, but had to reject it because it would not support the third party controls (janus grid) we were using.