Related
How do GUIs get built inside operating systems. Lets use two examples, say GTK+ in Ubuntu verses a Java JFrame. I thought that operating systems using some kind of graphical user interface would have to provide some system calls to be able to display windows. So for example, if I installed a version of Ubuntu on a machine, with out downloading any software I should be able to make a system call to display a window. It appears though that isn't the case. I have to install and download the SDK for GTK+ which allows me to create windows with buttons, etc. So then my question is with Java, how does Java then build it's JFrames? I understand that there is a Java Virtual Machine running ontop of the Linux system, but how does the Java virtual machine make calls to actually display the window? Along with GUIs comes the events that the user interacts with them. At the Java level, the JVM handles all the lower level calls, and you get OnClick() events etc. How does the JVM actually call and work with those calls? Same with GDK+? I understand this is a broad question with many different answers, but any help would be greatly appreciated.
Let's take Linux as an example. There are several layers:
Kernel (Linux) and operating system (GNU) - Knows how to work the hardware, including graphics.
Windowing system (X) - Uses graphics functions to draw windows.
Desktop (eg Gnome) - Applies global styles such as window borders.
(Usually) A toolkit such as GTK - Knows about widgets, how to draw them and how to style them.
Your application.
On Windows, the Kernel, OS, windowing system, desktop and widgets are all bundled together. In this case the toolkit probably doesn't draw its own widgets, but uses them directly from Windows.
In any case, the toolkit insulates your application from the platform-specific details and automatically does the right thing.
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 6 years ago.
Improve this question
If you open the page "Graphics and Gaming (Windows)" on microsoft.com
the last category is described as
Legacy Graphics: Technologies that are obsolete and should not be used in new
applications.
This category includes (among others) the following APIs:
GDI
GDI+
OpenGL
What's your opinion? If i want to roll out a new software today it must support Windows XP (still about 50% of all installed systems). Direct2D requires Windows 7/Vista. What else should be used?
I suspect that Microsoft's definition of "legacy" has little to do with what any sensible developer should do, and is instead based on some Grand Rewrite of the Windows API.
Starting at around Windows Vista, Microsoft has been redesigning many of their API's. We now have MMDevAPI as the One True Sound API, WIC is the One True Image File API, etc. From what I've seen/heard, these new API's are much better than the old ones, and the "legacy" systems all work based on the new ones. In Windows Vista and later, DirectSound is entirely based on MMDevAPI, and components that need to read image files do it via WIC.
Windows 8 will have an ARM version, which it appears will support only a subset of the current Windows API. We won't know for sure until Windows on ARM is released, but, based on the libraries included for the ARM platform in Visual Studio 11 (ref: http://www.winehq.org/pipermail/wine-devel/2012-March/094559.html), it's looking like GDI+ and OpenGL will not be available. GDI is available for linking, but that doesn't necessarily mean it's intact.
This new API's from Vista and later roughly correspond to the libraries in the VS11 ARM target. I'm guessing that anything on that list is there because it's either the latest and greatest way to do what it does, or it's too technically important to discard (for now). Thus, "legacy" is anything that's not the latest and greatest way to do at least one thing.
I'm not sure what is the One True Graphics API. Already we have Direct2D, Direct3D, DirectComposition (which, by the way, is not available until Windows 8), DirectWrite, and DXGI. DXGI seems the closest, but I don't have a deep enough understanding of the graphics API's to say. I suspect gdi32 is technically very difficult to get rid of. How are non-legacy applications meant to find out when part of a window has been revealed and therefore must be painted, without using WM_PAINT, which involves an HDC, and how could a library do that on an application's behalf without replacing its window procedure? How are we meant to make semi-transparent windows without using UpdateLayeredWindow, which takes an HDC? How much does user32 depend on gdi32, and can they really be separated?
From a technical standpoint, Windows can easily get rid of GDI+ and OpenGL, but I'm not convinced that getting rid of OpenGL will work out, even on a new platform that doesn't promise any backward compatibility. It seems too valuable to developers. GDI+ isn't so important, but it's very easy for a third party to provide a replacement.
I would say use any of the API's you listed, and the worst that's likely to happen is that you have to rewrite your UI if you want to port your app to metro or Windows on ARM. GDI is a fine choice if your needs are simple and you'll be coding directly for the Windows API. There aren't many situations where I'd recommend GDI+ over OpenGL as a drawing API. GDI+ is slow, limited, and only available on Windows. The GDI+ API is simpler because it's 2D, so maybe it's worthwhile if you need to do something very simple but with anti-aliasing.
OpenGL isn't deprecated, Microsoft's implementation of it is. Microsoft's implementation is stuck at version 1.1, which is old. The current version of the standard is past version 4. If you want to use OpenGL, it is fully supported by NVidia, ATI, and Intel graphics cards on the Windows desktop, but not in Metro Windows Modern UI apps, is an industry standard, and also works on Mac and Linux. If you need a software fallback implementation, Mesa has got you covered, and it even works on DOS. (Since Mesa can render into memory buffers, there's no reason it won't work in Modern UI apps, but you probably don't want to do this because it can be slow.) One thing of note is that WGL, the API for accessing OpenGL functionality on the Windows desktop, depends on GDI (which is deprecated) so you probably want to use something like FreeGLUT or SDL instead if you want to future-proof your application, which also nets you platform independence.
OpenGL ES is a variant of OpenGL which works on Android and Apple iOS. It is also accessible in JavaScript via WebGL, which Internet Explorer 11 will support (and pretty much every other browser already does.) ANGLE provides a hardware-accelerated implementation of GLES for Windows which piggybacks off of DirectX (version 9 or 11) and thus should work in Modern UI apps as well. Once again, Mesa's got the software implementation covered.
TL;DR: OpenGL is not only not deprecated, it is cross-platform, standard, and has tremendous momentum in the industry. GDI and GDI+, well, not so much.
If you want to support Windows XP, then you're supporting a "legacy" operating system, and as such, using a "legacy" graphics framework is the logical choice.
Even if that weren't true, let's just say that I disagree with the advice given by the linked MSDN article. The "legacy" status here has more to do with which technology the Windows team thinks is cool this week. The status designation of "obsolete" just means that the group responsible is no longer accepting or fulfilling bug reports (except for critical security issues). Not too big of a deal—these technologies have been around long enough that they're fairly feature-complete and stable.
GDI isn't going anywhere, so if you need something rock-solid that is guaranteed to be supported anywhere and everywhere, that's what I would go with.
If you need a bit more 2D capabilities than GDI offers (e.g., alpha channel transparency), then you could consider using GDI+. It's nearly an order of magnitude slower than GDI, but that's not too big of an issue on modern machines with more power than you could ever want. This, too, is going to be supported for a very long time to come.
That said, if I were writing a new app today, I probably wouldn't bother with OpenGL. There's very little that it offers in benefits over Direct2D and DirectWrite, which are both what Microsoft is pushing as the replacements for GDI/GDI+. There might be some benefit to using OpenGL if you absolutely must target Windows XP because as far as I can tell, Direct2D/DirectWrite are only supported on Vista and later, but that's because (as I mentioned originally), Windows XP falls squarely into the "legacy" or "obsolete" camp itself. Alternatively, if you already know OpenGL well and don't have time or the desire to learn Direct2D/DirectWrite, then it might make sense to continue using it in a new application.
Don't let the verbiage of the MSDN article scare you. Choose whatever technology makes the most sense for your specific use case given all of the available information. By the time any of these technologies go away completely, you'll have to re-write the app completely for a dozen other reasons.
Edit: Hmm, it looks like DirectWrite has also been declared (by some people at least) "obsolete" as well, having been replaced by Direct2D. That's funny, it hasn't even been around long enough for me to bother learning it. I guess that only goes to support my earlier argument that "obsolete" simply designates that a particular technology is not what is currently considered to be in vogue by the Microsoft devs.
I'm personally waiting until all the bugs get worked out of this stuff (and we decide on a semi-permanent standard) before I make the switch for any of my applications. Everything I've seen written in DirectDraw or Direct2D has had serious rendering bugs and is a performance nightmare, even on reasonably competent machines. Sure, they only show up sometimes, under the right conditions, but that's too much for me. And I swear, the blurry text shows up all the time. Not being able to read what's on screen is a deal-killer for me and my users. GDI doesn't have this problem, and it's not going anywhere.
Are GDI, GDI+ and OpenGL really obsolete/deprecated?
This is not true for OpenGL. OpenGL 4 allows you to use geometry shaders on winxp. Which isn't possible with DirectX (DirectX 10 and up isn't supported on WInXP). It is also one of the only cross-platform 3D APIs out there.
From a business point of view MS is interested in promoting DirectX since it is their technology that lock Developer into windows platform (they're also interested in making DirectX more attractive for developer, but that's another story). So it makes sense that they aren't keen on promoting OpenGL.
What else should be used?
I'd advise to stop using platform-specific tecnologies when possible. Grab cross-platform framework and use it for your application. There's Qt, GTK, wxWidgets and other toolkits for GUI apps, and SDL(and alternatives) for games. This way when platform developer decide to make ridiculous decision (like not supporting DX10 on WinXP) you dislike, you'll be able to move elsewhere with minimum development cost. Qt is also ridiculously powerful and at the moment I have no reason to use something else for GUI development. Still, situation can change in the future.
In short, while developing for certain platform you should keep in mind that platform developer might have their goals that are not compatible with your wishes. Discovering that your source has become locked into single platform isn't very pleasant experience. Your own goals should be the first priority, and if os developer tries to make you use certain technology you don't like, then you shouldn't support that technology.
Because OpenGL is a standard, it should be considered equally deprecated as C or C++ so it is a matter of time before the entire Windows API -- which today has become a compile once run on every x86 machine API thanks to Wine -- is considered deprecated in favour of .NET and C#.
I use GDI for simple graphics and OpenGL, when I need accelerated 3d.
Another aspect is that Microsoft's build-in implementation of OpenGL is definitely to be considered as deprecated since it is just version 1.1 or something, but that has been for a long time.
Yeah, about OpenGL, it actually outperforms DirectX in many ways both resource and display wise. It will never be promoted by Microsoft because it can't own OpenGL, not to mention most people don't do their research and Microsoft can claim it is old. Truth is opengl is opensource standard and evolves at a much faster rate than closed does because it is more than 1 room of developers paid to work on it. Also Microsoft has contracts with many companies to release using only Microsoft's software, this causes more business for Microsoft and less to use the more advanced OpenGL standard. It is a interesting lock up if you will, Microsoft creates these contracts so that many programs are written in DirectX to keep business for Microsoft, and no company will refuse it because Microsoft has about 80%+ home user market.
This article (from the Windows engineering team) says:
WOA [Windows On ARM] will not support any type of virtualization or emulation approach,
and will not enable existing x86/64 applications to be ported or run.
Does that mean I won't even be able to recompile an x86/64 application from source for ARM?
If yes, what exactly prevents me from doing that? My understanding is that the Win32 API is present on Windows 8 ARM.
If no, what do they mean by not being able to port x86/64 applications to ARM?
From the Windows article you link to, the second quoted paragraph is the killer. Porting existing apps is definitely NOT supported.
Developers wishing to target WOA do so by writing applications for the WinRT (Windows APIs for building Metro style apps) using the new Visual Studio 11 tools in a variety of languages, including C#/VB/XAML and Jscript/ HTML5. Native code targeting WinRT is also supported using C and C++, which can be targeted across architectures and distributed through the Windows Store. WOA does not support running, emulating, or porting existing x86/64 desktop apps. Code that uses only system or OS services from WinRT can be used within an app and distributed through the Windows Store for both WOA and x86/64. Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
If we enabled the broad porting of existing code we would fail to deliver on our commitment to longer battery life, predictable performance, and especially a reliable experience over time. The conventions used by today’s Windows apps do not necessarily provide this, whether it is background processes, polling loops, timers, system hooks, startup programs, registry changes, kernel mode code, admin rights, unsigned drivers, add-ins, or a host of other common techniques. By avoiding these constructs, WOA can deliver on a new level of customer satisfaction: your WOA PC will continue to perform well over time as apps are isolated from the system and each other, and you will remain in control of what additional software is running on your behalf, all while letting the capabilities of diverse hardware shine through.
Only a subset of Win32 is supported on Win8 for ARM:
http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx
If you try to build an application that uses a Win32 API that's not supported, it won't build because the API won't be in the library. If you try to create your own library to support the APIs, the application still won't be usable because the only way to deploy apps to customers will be through the MS app store, which will no doubt check for API conformance.
From The "Building Windows for the ARM processor architecture" article:
Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
It might be possible to do so on your development machine (but maybe not - I'm really not sure if such a 'hack' will be possible, supported or not), but you certainly won't be able to deploy it in any kind of widespread fashion.
In short, any existing Win32 application will likely need significant work to be ported to Win8 for ARM. It won't be a matter of recompile and fix any errors that pop out to get the application to run on ARM.
They do provide this caveat a little further in your cited article:
Additionally, developers with existing code, whether in C, C++, C#, Visual Basic, or JavaScript, are free to incorporate that code into their apps, so long as it targets the WinRT API set for Windows services.
They've got version of Office and IE available; I'm positive those weren't ground-up reimplementations.
Lazarus Ide can use several gui libraries. I am on Windows. I wonder what are difference among them...
It is clear that lcl is most stable.
Why would anyone use Qt and fpgui once they will be of good quality?
LCL is the abstraction. IOW the core part of the LCL works on all platforms. It's a bit Windows centric since it derives base principles (and compatibility) from Delphi's Windows centric VCL.
Under Windows, the LCL typically uses the win32/64 GDI API layer as backend, but it can also use others, most notably QT and GTK2 (though these are more in testing stages)
If you have majorly invested in making a complex GUI app under Linux, and have used QT specific functionality, the LCL-with-QT backend would e.g. allow you to more easily port this code over.
IOW using anything but win32/64 (GDI) on Windows is only in interesting specific purposes, with codebases that go beyond the LCL from non Windows origin.
FPGUI is a one man mission to create an own (owner drawn) widgetset. The LCL port was planned, but never delivered. Typically these kind of GUIs are used in embedded POS environment where the application essentially runs fullscreen.
It probably also works on Windows since it's ownerdrawn and probably requires only a few basic primitives to get it working, and porting it to windows eases development.
Has anyone out there created a version of GDI32.dll that takes advantage of hardware acceleration available on the machine? gdiplus.dll?
Starting with Windows Vista, GDI is no longer hardware accelerated. (GDI+ was never hardware accelerated). Without Microsoft fixing GDI (and GDI+) to be able to run well on the computer: native applications (C++ MFC, Delphi, etc), and managed WinForms applications, will continue to run poorly forever.
While i could use Direct2D for business applications, i cannot control the fact that the development environment still creates controls, with decades of library support code, that assumes the presence of GDI.
Application Compatibility: Graphical Device Interface (GDI):
GDI primitives such as LineTo and
Rectangle are now rendered in software
rather than video hardware, which
greatly simplify the display drivers.
Windows And Video Memory
In XP GDI is GPU accelerated to
various degrees depending on how the
OS is configured or the device driver
(for details see Hooking Versus
Punting).
In Vista, GDI is not GPU accelerated
Comparing Direct2D and GDI
As a result, in Windows Vista, the GDI
DDI display driver was changed to be
only implemented by a Microsoft
supplied driver, the Canonical Display
Driver (CDD). GDI rendered to a system
memory bitmap. Dirty regions were used
to update the video memory texture
which the window manager uses to
composite the desktop.
It seems that Vista was a special case in the history of GDI performance.
Both articles below show that the future for GDI looks bright again.
http://msdn.microsoft.com/en-us/library/ff729480%28VS.85%29.aspx
GDI is hardware accelerated on Windows
XP, and accelerated on Windows 7 when
the Desktop Window Manager is running
and a WDDM 1.1 driver is in use.
Direct2D is hardware accelerated on
almost any WDDM driver and regardless
of whether DWM is in use. On Vista,
GDI will always render on the CPU.
http://blogs.msdn.com/b/e7/archive/2009/04/25/engineering-windows-7-for-graphics-performance.aspx
Based on real-world application
statistics, ... we worked with our
graphics IHV partners to provide
support in their drivers to accelerate
the most commonly used GDI operations.
Well, yes, GDI is the "it works anywhere anytime" API for rendering graphics. It puts very low demands on the video driver. Everybody got that right a long time ago. Which took a while, I got a distinct memory of a ATI Mach video card that gave me no end of trouble. It stopped me from buying ATI products for quite a while.
Everybody got DirectX right a lesser long time ago too. It is being taking advantage of in the WPF rendering model, it completely relies on DirectX to get the job done. Milcore is the shim name. You won't get it until you buy into the WPF programming model.
What do you mean by hardware acceleration?
I mean, GDI doesn't do a lot other than raster blits, but those were hardware accelerated. And, given that Vista and Windows 7 arn't terribly slower with desktop apps, still are.
GDI still gets the video drivers to do all the heavy lifting, so if GDI isn't hardware accelerated, then its the driver vendors fault, not GDI's.