According to MSDN's listing, GDI and GDI+ are both legacy. So when writing an application using the Windows API, what should you use to render 2d graphics?
Direct2D, WIC, DirectComposition (this is new to me), GDI+, GDI?
Note: not 2d games - just 2d images.
Either GDI or GDI+ are fine choices for basic needs.
The OS still uses GDI all over the place, so I'm not really sure what they mean by "legacy". Words like that generally don't have a meaning, so you shouldn't feel too bad ignoring them. The person who labeled these APIs "legacy" is probably one of those people who tell you that all of Win32 is legacy without realizing that these "modern" GUI frameworks that they love so much are built on top of Win32 and wouldn't be able to function without it.
Use GDI+ if you need the extra features it provides (such as transparency, etc.) and/or if you're programming in C++ and prefer its class-based API to GDI's flat C-style API. But note that if your app uses GDI+, you will have to redistribute the Gdiplus.dll library to users running Windows 2000 and earlier versions. GDI-based apps will always work out of the box.
That's not to say that you shouldn't investigate the new contenders. Supposedly, Direct2D is designed to interoperate well with GDI and GDI+. Only problem is, lots of developers are not in a position to require all of their clients to upgrade to Windows Vista or later. Supporting XP still seems like a worthwhile goal (at least providing a minimal subset of functionality for those users), and that's not really possible if you write the entire UI in Direct2D or one of the new fancy frameworks. I haven't really seen the advantage of switching to Direct2D for standard, line-of-business apps (I'm sure there are advantages for games and other programs that need 3D effects). You might be interested in the following comparison between Direct2D and GDI, which are both two-dimensional, hardware-accelerated graphics APIs.
Unless you really have to support XP (let it die already!), I would highly encourage using Direct2D. There are multiple reasons why Direct2D makes sense for all new developments:
generally faster rendering (aliased and anti-aliased rendering)
since Vista was introduced, GDI is not HW accelleration is highly crippeld (due to the new drivermodel)
better integration with Direct3D (if you need it), DirectWrite, DirectComposition, etc.
better utilization of new GPU features
many bitmap effects pre-built-in
GDI is not allowed for Metro-Style apps
Therefore, I would suggest anybody, who is beginning a new application to use Direct2D instead of GDI/GDI+.
Related
I inspected the Qt GUI interfaces using window spy tools and I know that it does not use windows common controls or any custom window class to create its UI elements and animation effects. I asked before here about developing a custom GUI framework using GDI/GDI+ but most people responded against these technologies, so the question remains which graphics technology Qt or any other equivalent appropriator system uses to render their UI?
I am aware of DirectX/OpenGL but isn't it overkill for simple requirements? If the answer is going to be one of the above then again I wonder how one could implement robust font rendering and vector graphics solutions with these polygon rendering technology? the full featured text editor is another huge challenge.
Also there already exists solutions based on directx/opengl like MyGUI and CEGUI but I think they look ugly and nowhere near how Qt looks.
First things first, Qt-5 introduced a new rendering model, which can (but is not required to) use OpenGL for rendering the UI elements. The upshot of this is, that one can truly mix custom OpenGL rendering with Qt widgets. The downside is, that some kind of OpenGL support is required, which not all systems have.
So Qt also has these two other drawing systems: Native, which will use the hosts systems native graphics primitives (GDI, CoreGraphics, X11/XRender) and raster which does a complete rasterization of a whole window into pixel buffers, where then only those are blitted over to the underlying graphics system. raster is the slowest of the graphics backends, but it gives consistent results for all plattforms and target systems. Hence raster is usually used for programs where consistent appearance is strictly required.
I plan to embed an unmanaged C++ OpenGL viewer in WPF. The requirements are (apart from robustness and ease of development)
proper resizing
context menu for the OpenGL viewer area (only for viewer related actions)
events (e.g. triggered by selection of an object in the OpenGL viewer)
WPF dialogs should be drawn on top of the OpenGL space
So far I've found some blogs and discussions about using a hosted WinForm control (via C++/CLI wrapper), but it seems to be bit tricky (even a bit tinkery) to get all my above requirements done (if possible).
How about creating an ActiveX control? Despite having no experience with creating an ActiveX control, one advantage would already be that it runs in its own process.
Is it a good idea or would I run into even more tinkering?
EDIT: I should be clearer about the OpenGL viewer. It's an existing app based on an C++ 3D engine which only supports OpenGL. Porting to an DirectX capable engine is considered as last resort.
Although I didn't use ActiveX, I've accomplished what I believe you are trying to achieve. Two pieces of information helped me down this road.
Mixing Managed and Unmanaged code
It turns out, that managed C++ compiles completely differently than unmanaged C++, and data is stored on a completely different heap. Luckily you can mark sections of code as managed or unmanaged by using...
#pragma managed
#pragma unmanaged
See more info at this article
OpenGL context management
I followed a method similar to what's described in this article
wglMakeCurrent and wglShareLists will be your buddy if you need to manage multiple OpenGL windows
Good Luck!
Why you want an activex? There is some managed PInvoke based wrappers as SharpGL doing the job you need easyear.
But also, since you are using WPF and you have a Viewport3d object,why don't use it? If you are familiar with 3d engines you will appreciate the semplicity ( even if there is some drawback in term of speed).
Another point, since as per this question here I was forced to abandon WPF 3d rendering in favor of OpenGl due to the fact that Opengl can render in session 0, by using pure software mode. This is a requirement if you are planning to render something in off-screen bitmaps from a service or an asp.net application.
I have been using a few cross-platform GUI libraries (such as FLTK, wxWidgets, GTK++), however I feel like none fulfil my needs as I would like to create something that looks the same regardless of the platform (I understand that there will be people against building GUI's that don't have a native look on the platforms but that's not the issue here).
To build my controls, I usually rely on basic shapes provided by the library and make my way up binding & coding everything together...
So I decided to give it a try and do some opengl for 2D GUI programming (as it would still be cross-platform. With that in mind, I couldn't help to notice that the applications that I have written using wxWidgets & FLTK usually have a average RAM consume of 1/2MB, whereas a very basic openGL window with a simple background ranges from 6 to 9 MB.
This brings me to the actual question for this thread,
I thought that all the rendering of the screen was made using either opengl/direct (under the covers).
Could someone please explain or link me some sort of article that could give me some insight of how these things actually work?
Thanks for reading!
These multiplatform toolkits usually support quite a lot of backends which does the drawing. Even though some of the toolkits support OpenGL as their backend, the default is usually the "native" backend.
Take a look eg. at Qt. On Windows it uses GDI for drawing for its native backend. On linux it uses XRender I think. Same on Symbian and Mac. Qt also has its own software rasterizer. And of course there is an OpenGL backend.
So why the application using some of these GUI toolkits can take less memory than a simple OpenGL application? If the toolkit use the "native" backend, everything is already loaded in memory, because it is very likely that all visible GUI uses the same drawing API. The native APIs can also use only one buffer representing a whole screen in which all applications can draw.
However when using OpenGL you have your own buffer which represents the application window. Not to mention that an OpenGL application usually has several framebuffers, like z-buffer, stencil buffer, back buffer, which are not essential for 2D drawing, but they take some space (even though its probably the space in graphics card memory). Finally, when using OpenGL, it is possible that the necessary libraries are not yet loaded.
Your question is exceedingly vague, but it seems like you're asking about why your GL app takes up more memory than a basic GUI window.
It's because it's an OpenGL application. This means it has to store all of the machinery needed to make OpenGL work. It means it needs a hefty-sized framebuffer: back buffer, z-buffer, etc. It needs a lot of boilerplate to function.
Really, I wouldn't worry about it. It's something every application does.
I am looking for the ability to open OpenGL contexts and draw native OpenGL in windows, macOS, linux distros with X, android and iOS
I don't want to rely on the "native" device framework for the actual UI, I don't need to use native components, all I want is an OpenGL context to natively draw in OpenGL. Many of the cross platform SDKs like Marmalade and MoSync focus on making use of the native UI components and stuff like that, all I need is an OpenGl context to draw as I intend to, absolutely no native UI functionality is required, however, access to native hardware features like microphone, camera and other sensors is desired if possible, as well as access to audio/video/network.
I don't want to use QT, I want to do something that is closer to the hardware to work on the low level. The general idea is to make a lightweight cross platform hardware accelerated GUI, written on a level low enough to be truly hardware native, without relying on any native software framework. I know for android I may have to use a java wrapper to launch the native code, but the idea is to have this wrapper minimized, with very little modifications needed to deploy the low level and thus hopefully TRULY cross-platform code, that is only dependent on OpenGL hardware and OpenGL context for it to work wit.h
So I need a bare minimum solution to avoid using non-cross platform features as much as possible.
At the time the only library that comes to my mind is SDL, but I am not sure it supports android and iOS property, so besides library recommendations, more information on how SDL handles android and iOS devices and their hardware is welcomed too.
How about:
GLFW
SDL
GLUT (FreeGLUT or OpenGLUT)
Blender's GHOST framework?
Essentially they open a window, create a OpenGL context on it, deliver you the input events and leave the rest up to you.
What you want is nothing more than a platform-specific OpenGL context setup (which is quite simple and well documented: the NeHe OpenGL tutorial provides code for many environments that does just this here (the explanation is Windows specific, scroll down for the code on different OSes).
Once you have the OpenGL context, nothing prevents you from creating a full GUI with all OpenGL elements.
If you want, you could use Qt to only set up an OpenGL context (ie don't use any QWidgets or anything, other than the window showing you your OpenGL scene). It takes care of the whole setup process, but for only that, Qt becomes a huge dependency, as it only really replaces at most 100 lines of code per platform.
With regards to SDL+Android, have you checked the README?
And for iOS check the same file here.
I've been challenged with a C++ 3D application project that will use 3 displays, each one rendering from a different camera.
Recently I learned about Ogre3D but it's not clear if it supports output of different cameras to different displays/GPUs.
Does anyone have any experience with a similar Setup and Ogre or another engine?
At least on most systems (e.g., Windows, MacOS) the windowing system creates a virtual desktop, with different monitors mapped to different parts of the desktop. If you want to, you can (for example) create one big window that will cover all three displays. If you set that window up to use OpenGL, almost anything that uses OpenGL (almost certainly including Ogre3D) will work just fine, though in some cases producing that much output resolution can tax the graphics card to the point that it's a bit slower than usual.
If you want to deal with a separate window on each display, things might be a bit more complex. OpenGL itself doesn't (even attempt to) define how to handle display in multiple windows -- that's up to a platform-specific set of functions. On Windows, for example, you have a rendering context for each window, and have to use WGLMakeCurrent to pick which rendering context you draw to at any given time.
If memory serves, the Windows port of Ogre3D supports multiple rendering contexts, so this shouldn't be a problem either. I'd expect it can work with multiple windows on other systems as well, but I haven't used it on any other systems, so I can't say with any certainty.
My immediate guess, however, is that the triple monitor support will be almost inconsequential in your overall development effort. Of course, it does mean that you (can tell your boss) need a triple monitor setup for development and testing, which certainly isn't a bad thing! :-)
Edit: OpenGL itself doesn't specify anything about full-screen windows vs. normal windows. If memory serves, at least on Windows to get a full screen application, you use ChangeDisplaySettings with CDS_FULLSCREEEN. After that, it treats essentially the entire virtual desktop as a single window. I don't recall having done that with multiple monitors though, so I can't say much with any great certainty.
There are several things to be said about multihead support in the case of OGRE3D. In my experience, a working solution is to use the source version of Ogre 1.6.1 and apply this patch.
Using this patch, users have managed to render an Ogre application on a 6 monitors configuration.
Personnaly, I've successfully applied this patch, and used it with the StereoManager plugin to hook up Ogre applications with a 3D projector. I only used the Direct3D9 backend. The StereoManager plugin comes with a modified demo (Fresnel_Demo), which can help you to set up your first multihead application.
I should also add that the multihead patch is now part of the Ogre core, as of version 1.7. Ogre1.7 was recently released as a RC1, so this might be the quickest and easiest way to have it working.