Graphics on Windows from a different angle

Published Wednesday October 24th, 2012
70 Comments on Graphics on Windows from a different angle
Posted in Graphics, OpenGL, Qt, Windows

With Qt 5 we are making the bold move of making OpenGL 2.0 a requirement for using  QtQuick2. There are several challenges with this new requirement, many of which have been discussed on the blogs and mailing lists already, but today I want to talk about one issue in particular and that’s OpenGL on Windows.

Microsoft has included OpenGL in Windows since Windows 98 (or earlier?), however the initial version was a software implementation and only supported version 1.1 of the API. Over time, the implementation has been improved so that today it is implemented as a wrapper on top of Direct3D. This is great, but unfortunately the version of the API that is supported has remained the same and that means it is not sufficient for running QtQuick2 or even Qt’s GL paint engine. You can insert your own conspiracy theory about why Microsoft has let OpenGL stagnate on Windows, but every theory will likely involve Direct3D. D3D is a component of DirectX that offers similar functionality to OpenGL. It is most commonly used by game developers to target desktop Windows and also XBox, but is also used by CAD applications.

Typically when a developer wants to run or develop something that requires OpenGL on Windows, the first place they go is to their hardware vendor’s website and download the latest drivers from Intel, NVidia, AMD or whoever.. This is fine, but can be somewhat inconvenient for end users of OpenGL applications. We wanted to avoid this problem with Qt applications so deployment would essentially be the same as with Qt 4 (but with possibly more DLLs). Luckily for us, we weren’t the first people to experience this problem. Most browsers these days (except IE) are supporting WebGL out of the box. WebGL is a 3D canvas API available through Javascript. The API is based on OpenGL ES 2.0 and the shader language is GLSL ES. So how can browsers offer an OpenGL 2 API without requiring new drivers? The solution is called the ANGLE (Almost Native Graphics Layer Engine) project.

ANGLE is a BSD licensed project that implements the OpenGL ES 2.0 API on top of DirectX 9.0c. In addition to this, it also implements the EGL API and contains a shader cross compiler that takes GLSL ES code and converts it to HLSL which is the shader language used in DirectX. So ANGLE allows us to essentially run the Qt Scene Graph on top of DirectX without modifying any of our code. Friedemann has already done most of the hard work by adding support for GLES2 and EGL into the Windows platform plugin and as a result it has been possible to use Qt 5 with ANGLE for quite some time now. However, to make this experience more painless, we are including ANGLE in Qt’s 3rdparty directory and making it the default OpenGL configuration on Windows.

For QML applications and lightweight OpenGL apps, you can use this new configuration to deploy your apps without requiring your end users to install new graphics drivers. On the other hand if your application requires full desktop OpenGL, then it’s simply a matter of configuring Qt with “-opengl desktop” and you get the same behavior as before.

One additional benefit of using ANGLE on Windows is that our graphics pipeline and multimedia pipeline are now based on the same underlying technology (DirectX) so we can take some shortcuts to get video frames into the Scene Graph more efficiently. Taking this one step further, Windows Vista introduced a new driver model called WDDM and one of the features here is that DirectX surfaces can now be shared across processes. This little feature will come in handy for our WebKit2 work which has seperate processes for the web renderer and the ui. All of this goodness might not make it into the 5.0 release, but it’s  all in progress so hopefully it makes an appearance soon!

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Graphics, OpenGL, Qt, Windows


DBoosalis says:

Jason. I am curious why you are standardizing on version 2.0 which came out in 2004, and not version 4.0. Do not all the major card manufactures now support version 4 ?

Also what about for classic widgets in Qt 5.0. By default will they be using the OpenGL paint engine?


Lilian says:

I think it has to do with open source drivers on *nix(Linux, BSD…) not supporting OpenGL 4.0.
And there is no need for OpenGL 4.0.

d3fault says:

>I am curious why you are standardizing on version 2.0 which came out in 2004, and not version 4.0. >Do not all the major card manufactures now support version 4?

For the same reason Qt uses C++ 98: compatibility. Personally I am turned on by the perfect choice of license, exposed API version, and target API version:
“ANGLE is a BSD licensed project that implements the OpenGL ES 2.0 API on top of DirectX 9.0c”.

I feel like anything requiring > gl 2.0 or dx 9 is just an attempt to sell graphics cards (see the numerous “dx 10/11 only” games that have had dx 9 support hacked in :-D).

>There are several challenges with this new requirement, many of which have been discussed on the >blogs and mailing lists already

I’m the curious type and would like to read about those challenges. Can anyone provide links?

I also have a decent relevant question: Will the Windows platform plugin be (rather, is it technically… ) able to detect if the vendor OpenGL drivers are available and to opt into using those? I do like having ANGLE by default, but would be even better if it could detect/choose to skip an unnecessary layer automagically :).

Jason Barron says:

@DBoosalis: OpenGL (ES) 2.0 is just the minimum that we require. If an application wants to use OpenGL 4.0, it can certainly do so, but has to use “-opengl desktop” as the configure option. OpenGL ES 2.0 is very popular on mobile and embedded so by ensuring that we stay within this subset as much as possible, most of our GL code can be shared across the platforms. The widget’s do not use OpenGL.. except for QGLWidget obviously 😉

@d3fault: I agree that having runtime switching between ANGLE and desktop OpenGL would be great. At the moment it is not possible because there is a fair amount of “#ifdef QT_OPENGL_ES_2” scattered throughout the various modules. Might be something to look into for the future though.

Stephen Chu says:

For QWidget based. non-OpenGL, Windows app, does this increase the install size of the deployment?

Jason Barron says:

@Stephen: Nope, if you don’t use OpenGL or QtQuick2 then there are no additional dependancies to deploy.

Stephen Chu says:

I tried to build Qt 5 from git with mingw and got this error:

Project ERROR: Cannot determine DirectX SDK location. Please set DXSDK_DIR environment variable.

Is mingw still supported?

ray stevens says:

Sorry but the fact that these things are being done this late in the Dev cycle shows how qt5 has simply not been thought through from a platform perspective. Not blaming you just how qt5 is being developed.

Jason Barron says:

@ray: Fair comment. Note however that this change involved very few changes in C++ and the ones that were added simply fixed legitimate bugs. The bulk of the work for ANGLE integration was done quite some ago by Friedemann Kleint so ANGLE has been part of the plan for a while. What we added here now was just a copy of the library as a convenience to avoid people having to build it themselves. It probably could have been added earlier, but we felt it needed to be done and wanted to do it before beta2 so it could be properly tested before the final release.

Davis says:

Where does this leave Qt5 for *nix platforms with no good GPU drivers?

Many months ago there was talk of using llvm-pipe for Qt5. But, there has been no update since. (!)

Can someone from Digia chime in? Hopefully with updated benchmarks.

Thank you!

Jason Barron says:

@Davis: This change has no impact whatsoever on *nix platforms. I’m afraid I don’t have any numbers for you, but I can say that llvm-pipe certainly provides a usable OpenGL implementation, but it’s up to the developer or end user of a Qt application to enable llvm-pipe in favor of poor hardware drivers.

Davis says:

@Jason : After all the organization, is anyone still working on making sure Qt and llvm-pipe play well together these days? If so, can you poke them for an update? 🙂

My target platform is generic Linux desktops that don’t have any vendor “binary blob” video drivers, and I’d love to use the new QtQuick2 stuff.

Thank you!

Jason Barron says:

@Davis: I’m not sure how much maintenance is required in Qt to keep them working together. I’m not aware of any llvm-pipe specific code in Qt so as long as it continues to pass the Khronos conformance tests it should work fine for QtQuick2. It might be that we use llvm-pipe as the backend in the CI system virtual machines, but someone else would have to comment on that.

Davis says:

@Jason : thanks for the heads up.

Since a good llvm-pipe implementation will help speed Qt 5 (w/ QtQuick2) adoption, do you know if Digia has plans to contribute to optimizing the upstream llvm-pipe code base?

Davis says:

Actually same question could apply to ANGLE as well. I just think driver-less *nix desktops might more common.

kromain says:

Small correction: Windows DOES support OpenGL 2.0 out of the box (and even 3.0 and 4.0 afaik). What isn’t supported is OpenGL/ES2 as well as EGL, which is what ANGLE provides.

Jason Barron says:

@kromain: I did not find that to be the case. It’s quite possible that hardware shipped with Windows pre-installed would have the updated version of OpenGL pre-installed as well, but as for the version that you get after a fresh install of Windows, I’m fairly certain that it’s version 1.1, but please send me a link if you find otherwise and I can post an update 🙂

Wojciech Cierpucha says:

Microsoft was supposed to ship 1.4 with Vista+, but apparently they dropped that idea and both Vista and 7 still have 1.1 preinstalled.

Joakim Dahl says:

Regarding what version Windows support and that “everyone” now has OpenGL 4.0 I can give some actual numbers. Since I created a screensaver/music visualizer that I intend to convert to Qt and QML. It collects anonymous usage info and since it’s not a gaming application it should match a normal user a bit better than valves steam survey. About 11% has OpenGL 1.x. 23% has OpenGL 2.x. 34% OpenGL 3.x. 25% has OpenGL 4.x. So targeting as a maximum OpenGL 2.1 would be advisable. Latest stats can be found at Stats

Jason Barron says:

@Joakim: Thanks for the stats! One interesting thing there is at least 95% of those use the proper vendor version of OpenGL instead of the Microsoft one. That’s much higher than I would have thought actually. It would be interesting to see if others have similar data. As for targeting OpenGL 2.1, like I said above, we aim to stay as compatible with OpenGL ES 2.0 as possible to maximize code re-use across desktop and mobile/embedded.

Sean Harmer says:

I’m not too surprised by the high percentage of people using vendor provided drivers. Certainly for nVidia, the driver bundle installs DX and OpenGL drivers. It is also the very first thing I install after installing the OS so I can get a higher resolution than something that looks like it’s made out of Duplo bricks 😉

I’m pretty sure that also the driver finder tool in Win7 also installs vendor provided drivers – maybe not the latest and greatest version but still a lot better than the MS 1.1 default implementation.

I know this change is good in that it helps ensure people have a working QQ2 out of the box but it does make it more difficult for those with desktop applications that need to use newer desktop OpenGL.

As somebody incorrectly pointer out earlier in this thread there actually are very good reasons for doing so not just selling more GPUs. A lot more is possible using OpenGL 3.x or 4.x and although QQ2 and Qt3D do not yet take advantage of these features they could be made to do so for even more awesomeness where the hardware supports it.

Morty says:

One interesting thing there is at least 95% of those use the proper vendor version of OpenGL instead of the Microsoft one. That’s much higher than I would have thought actually.

Why? To me it actually sounds perhaps a little on the low side.

Primarily since most people run the pr-installed OS they get when buying the machine. And even the worst crapware filled OEM installs usually have a vendor versions of drivers for most hardware. Specially when it comes to the video drivers(hence also OpenGL). Since the OEMs have had a very long time to learn with XP(shipping HW without vendor drivers to customers making it unable to run mor than 600×800, is not a good way to increase sales), including vendor drivers is common practice.

As for the remaining users, the self assemblers and users installing from regular MS media, they usually have the skill and knowledge to install the vendor drivers anyway.

Jason Barron says:

@Morty: I admit my surprise was based on personal experience, having installed Windows twice in the last month and both times having to manually install drivers, but you have a point. The OEM vendors typically pre-install the drivers and those that are confident enough to install Windows from scratch, probably know where to find the drivers they need.

Megan says:

Well, you won’t learn how Google Earth works exactly. The book gives an ovveriew of some state-of-the-art algorithms, but the implementation of Google Earth is still (and probably will be) a proprietary. If I remember correctly, Rage uses some kind of ray-casting for terrain rendering

SABROG says:

I understand you correctly, if i use parameter “-opengl desktop”, then my app use NVidia (etc) OpenGL drivers and my application must be work/render faster?

Jason Barron says:

@SABROG: If you build Qt with “-opengl desktop”, your application will use the OpenGL drivers from your Windows installation. Which version of OpenGL depends on the computer it is running on. On your machine, it might use NVidia (assuming you have it installed), however, if your neighbor runs the application, then it will use whatever OpenGL drivers he/she has installed which hopefully isn’t the Microsoft version 🙂 If you use ANGLE instead, then you *deploy* OpenGL along with your application and at runtime it will use DirectX from the Windows installation which should work on pretty much everything since WinXP SP2. As for performance, I haven’t run any benchmarks or anything, but ANGLE seems to have no trouble running most QtQuick2 apps at 60 FPS on my laptop. So this patch isn’t about performance, it’s more about offering an alternative deployment method.

Carlos says:

I’m not sure if I have understood well, if I want to createa Qt application that uses an extension or OpenGL 3 then I have to compile Qt myself?

If this is the case, I think that this is a major inconvenience.

Jason Barron says:

@Carlos: Yes. As of Qt 5.0 Beta2, we are planning to have the binary version of Qt built with ANGLE instead of desktop OpenGL. I agree this is suboptimal for applications that want to use OpenGL features outside of the scope of OpenGL ES 2.0 and if this turns out to be a major problem for the majority of Qt users then it’s worth revisiting this decision. Ideally we could make this a runtime decision, but I’m not sure we really studied the feasibility of that yet. My impression however (and correct me if I am wrong) is that many (most?) Qt customers actually compile Qt themselves so that it suits the application they are building. It would be interesting to hear some other opinions on this..

Ter says:

I like the idea, install it, use it. Most of the people I know as commercial license holders don’t want to compile Qt (compilation time, deployment…) for normal uses.
I really think that’s a bad idea to force the most of devs to compile Qt.

Interested Person says:

Benchmarks? Would be nice to see how it performs.

Interested Person says:

Oh, and… does it make you wonder about WebGL in QtWebKit as well? 🙂

Jason Barron says:

@Interested Person: I haven’t run any myself, but if I do, I’ll post the results. I looked through some of the ANGLE bug reports though and it seems that they have experienced performance as good or better than desktop OpenGL. As for WebGL, both WebKit and Mozlla use ANGLE to implement WebGL.

Joakim Dahl says:

For Qt I doubt there will be any performance problems using angle. What I do know is that Angle has issues with complex shaders. It’s quite frequent too see the advanced WebGL shader writers telling everyone to disable angle. Again I doubt this will be a serious issue for the target audience of Qt but it’s worth being aware of since a perfectly valid GLSL shader will crash in this case for reason you can’t easily find out.

Interested Person says:

I’m actually asking whether WebGL be enabled in QtWekKit…? 🙂

Chris says:

Wait a minute! Is that related somehow to QGLWidget? Or ist just QtQuick2? How about mixing QGLWidget and QtQuick2???

Jason Barron says:

@Chris: Well QGLWidget uses the same OpenGL implementation as the rest of Qt so by using ANGLE, any GL code you write in QGLWidget will go through ANGLE. Apart from that though, there were no changes to QGLWidget. As for mixing QGLWidget and QtQuick2, I don’t see any reason why you would do that. QtQuick2 is already implemented on top of OpenGL using the Qt Scene Graph. You can implement your own custom scene graph nodes in OpenGL and QQuickWindow has two signals (beforeRendering/afterRendering) that let you render whatever you want to the window before or after the QML is rendered.

Chris says:

@Jason Barron
I am not sure I understand you exactly what I mean. What I generally intend to do is to use QGLWidget to display my 3D Scene and to use QtQuick to draw UI on top of it or. I will develop on the desktop and then port the application to the supported mobile devices. I hope that that is feasible for my ideas about multimedia applications.

How about the performance of ANGLE is it faster, slower or about the same as native? Anyway in that case it might be nice to have the option to choose ANGLE or native OpenGL at runtime as you have stated above.

Thank you for your reply.

Chris says:

I have read the documentation and I understand now what you mean. It sounds great.

Slartibart says:

Does this mean we’ll see a WinRT version of Qt not in the too distant future too?

Jason Barron says:

@Slartibart: I’m not aware of anyone investigating this outside of some preliminary stuff here: It would be great to have, but I think there are still quite a few hurdles to overcome.

Thorbjørn Lindeijer says:

Does ANGLE also make it possible to use QML for implementing the UI of a game based on Direct3D? What if the version of DirectX this game is written for is 10 rather than 9.0c? Would it still work or would an ANGLE version targeting DirectX 10 be required then?

Jason Barron says:

@Thorbjørn Lindeijer: There is a GL extension in ANGLE to get a pointer to a DirectX surface that is created from an EGL Pbuffer surface so it *could* potentially be possible to render to this surface using DirectX and then just bind this whole surface as a texture in some scene graph node. I think that would be your best bet, but QML items themselves will still have to be GL. As for compatibility, ANGLE only uses DirectX 9.0c API and runtime loads some other libraries if they are available (eg: dwmapi.dll is only on Vista on higher) so compiling it against DirectX 10 wouldn’t be a problem, but obviously if you started using API from DirectX 10 you wouldn’t be able to run on pre-Vista machines.

uuhhh says:

> Microsoft has included OpenGL in Windows since Windows 98 (or earlier?)
At least since NT 3.51 (the screensavers used it), and I think 3.5 had it too. Windows 95 had OpenGL from the start as well, I believe.

Jason Barron says:

@uuhhh: Yeah, I thought Win98 sounded a bit late, but I blame Khronos 🙂

7 says:

Qt should implement their own hardware accelerated graphics API and port it natively to Direct3D, OpenGL and ES. Just keep ES compatible stuff on a layer that is guaranteed to work across the entire range of supported devices and keep the extra stuff for developers who need it.

Jason Barron says:

@7: I’m not sure an entirely new API would be the right solution since it’s not simply translating API calls like most other areas in Qt, but also shaders which need to be compiled/linked at runtime. I think what we have now works pretty well actually by using OpenGL ES 2.0 as the common base. If you keep your API calls and shaders inside the scope of GLESv2, then you have something that runs on mobile GL, desktop GL, and now DirectX and it’s a standard, documented API so we get it for free 🙂

Qb says:

It would be really useful to enable ANGLE depending on the actual runtime system configuration, and not at compile time. When an app is executed with a lower-level graphic card which doesn’t support OpenGL 2 , it should use ANGLE, else it should use direct OpenGL instead. Could this be possible?

Jason Barron says:

@Qb: Fully agree that this would be ideal, but it means that all OpenGL calls would have to be resolved at runtime. It’s possible, but we really need to look at the feasibility of it first. At the moment, we still have a lot of #ifdef’s in the code so this would need to be cleaned up. A good place to start would probably be to make QOpenGLFunctions resolve everything at runtime instead of compile time as it does today.

MB says:

ANGLE is OpenGL *ES <= 2.0* only. In consequence, desktop OpenGL-based QT applications still have to deal with hardware/driver issues on their own. A llvmpipe based fallback would resolve all issues for QT AND QT-based desktop OpenGL applications together – and, more important, not only on Windows platforms. Besides, llvmpipe would be runtime selectable if no appropriate hardware OpenGL is provided.

ANGLE may be a fallback with limited ES 2.0 functionality for Windows. But, do you really wish to have this as a default dependency, which a developer has to go for or not at compile-time?

Jason Barron says:

@MB: As stated before, I agree it is unfortunate that this is a compile time decision for now, but perhaps we can change that in the future. For now, it does give apps that do not require desktop OpenGL an alternative method for deployment and it might improve things in QtMultimedia as an added bonus.

As for deploying Mesa/llvm-pipe as a fallback for all platforms, I’m a little more skeptical. On Mac we always have OpenGL so it wouldn’t be used there. On Linux, I would assume it’s fairly common (?) to have llvm-pipe as a fallback already so not sure it would make sense for Qt to build it’s own there either. So that leaves applications on Windows that require desktop GL as the main customer for this. In that category, I would then ask:

1) How many applications experience enough problems with OpenGL driver quality that a SW fallback would be preferred?
2) How suitable is the performance of llvm-pipe for these applications?

If the overwhelming answer to these questions indicated that llvm-pipe would make sense, then perhaps it’s worth it, but it would come with some maintenance cost since we would also need to include LLVM and any other dependencies needed to build it (cmake?). I’m not ruling this out completely, but we would have to consider the cost/benefits here 🙂

MB says:

@Jason: Thank you for this detailed response.

I see the improvements for QtMultimedia. Will they be available for applications that use QT with “-opengl desktop”, also?

Of course, I can hardly give an objective answer to your question 1). Typically, people always name industry (CAD), medical application etc – Note that it’s not only quality issues, but considerable aspects of hardware/driver validation and compatibility maintenance.

As for question 2), the answer is: For any OpenGL application that does not target HD resolution gamers, llvmpipe is quite sufficient. With current llvmpipe, CPU-based OpenGL gains comparable performance to budget GPUs.

Unfortunately, llvmpipe is hard to build… LLVM / CMake / SCons / Python / Flex & Bison. Moreover, Windows is not Tier 1 platform of the Mesa people.

Jason Barron says:

@MB: The QtMultimedia improvements will not benefit desktop OpenGL users since desktop GL is not based on DirectX and that’s where our improvements will come from. That being said, the improvements are rather targeted at QML2 and WebKit use cases since that code path is currently not optimal (video frames get uploaded to a texture each frame). If you only want to render video to a window and do not need it in a texture than the implementation is already fairly optimized for that case.

Indeed llvm-pipe is a bit of work to get working on Windows, but even if we don’t add it as an option in Qt, having instructions on the wiki about how people could build and use this in their own applications would probably be helpful. *hint* *hint* 🙂

MB says:

Quite a bit paradox that with QT 5, applications that follow the QT-paradigm of platform independence by relying on OpenGL now have drawbacks compared to DirectX based applications. However, I can follow your consideration of cost/benefits.

I built llvmpipe just recently for Windows, but I guess a build instruction should be mailed to mesa users list first, as people there are struggling at all time.

DRFrederik says:

I’ve been trying to compile Mesa on Windows XP embedded on a Geode machine. When finally all pre requisites concerning scons were ok (required me to hack in on one of the py files to ommit an exception), after 20 minutes, compilation of libgallum module exits with a compiler error (no info whatsoever, thank you scons).
I’ve found the same issue in several mailing lists but always without any reply on how to solve this.

So here I am stuck with the Geode platform and only Windows gl 1.1 vanilla …

Of course I will be sticking to Qt 4.8 for now, though that would be a shame in the long term, especially when at some point the target platform is upgraded.

7 says:

It is just me or is Qt continuously getting harder to work with, with more and more dependencies, requiring more and more tools to build and more and more complex build procedures??? I remember back in the days what I really liked about Qt was how easier it made to develop with C++, but now that looks like distant past.

I was kind of hoping with the transfer to Digia Qt would go back to to its C++ roots, stop investing the majority of development efforts in that nonsense QML. Yet what I see is Qt becomes even harder, more complex and more tedious to work with, all in the name of QML and the requirements it has. The development at Qt has been so disappointing the last few years I migrated most of my non-performance-intensive projects to php/js/html – just code, save and run…

What is ironic is I’ve never been a fan of inefficient, interpreted languages, so the direction of Qt moving me from C++ to what I dislike is very indicative of how l feel about it, as well as many other developers. And surely, I hear plenty of superlatives addressing the development at Qt, but still I feel like noting the fact that more than 2/3 of qt-center’s forum users are not that big fans of QML:

Yetistr says:

7 wrote:
>I was kind of hoping with the transfer to Digia Qt would go back to to its C++ roots,
>stop investing the majority of development efforts in that nonsense QML.


Indeed, QML is dragging to Qt to an endless and pointless state of:

– bad architectural decisions
– over complexity/dependency (unnecesary and unwanted as stated by so many)

… and what is worst is that nobody seems to care.

I think that these are sad days for Qt users (the ones that made the kind of software that puts Qt in high place in industry) and I hope more important aspects can be addressed in regards to:

1) restore the *cross-platform* feature and (of course)
2) bring back to C++ to be first class citizen, because (please let’s be honest) is not.

Fortunately there is more interesting and promising options like:

Juce :

Jason Barron says:

@7: @Yetistr: I would really prefer if this thread did not deteriorate into yet another QML bashing thread.

This change is about improving deployment of OpenGL applications on Windows and yes the fact that this applies to QtQuick2 is not entirely coincidental. If you look at modern desktops today such as OS X Mountain Lion, Windows 8 and some of the flashier Linux environments there is more and more animation in the UI and with higher resolution displays it gets harder to do smooth animations without hardware acceleration. So regardless of whether or not you like these new animated UIs or whether or not you think QML is the best choice for implementing them, Qt needs to support hardware acceleration and this is just one more enabler for that 😉

If there are concrete areas where you think Qt is lacking in C++ API, then I suggest you create suggestions in JIRA and try to rally the community around them or if you have a commercial license, tell your account manager so your feedback is not lost. Posting comments on a blog saying “QML sux, C++ rulez” is a little too vague to convert into a roadmap intem :-p

7 says:

You are the only one saying “QML sux, C++ rulez”. And please, don’t immediately resolve to the “if you want it do it yourself” cliche, which is totally inapplicable in this particular case…

No one argues about the merits of hardware acceleration, I just associated its dependencies with all the rest of the negative development at Qt, which appears to be an utter waste of developer efforts for the sake of implementing a technology to which better and more widely supported solutions already exist.

As Yetistr pointed out, QML is an extremely poorly designed API, and with no native public API for QtQuick users get locked into this poorly designed API. QML is significantly lacking in its main claimed advantage – better separation, with HTML you can separate structure from design besides the separation from logic, but with QML you cannot separate UI structure from UI design. The purpose of separation is to produce more dynamic solutions, and the lack of better separation and UI abstraction of QML is actually pretty static which effectively voids most of the merits of being able to separate logic from UI. If you are to have a static UI you might as well put it with the logic.

You really need a good hardware architect to outline a flexible and easy to use UI API for you, one that has a good background with designing and implementing user interface, with good artistic and aesthetic sense. The Trolls are great programmers, but without the proper leadership their efforts are wasted on the half baked, poorly designed QML endeavor that is long overdue and vastly inferior to already existing, mature and popular solutions. I do not intend to insult anyone, I just really think Qt deserves to be more innovative. Just pointing out the fact good programmers have a very narrow scope of competence due to their tight specialization and intrinsically lack the large scale vision and diverse experience it takes to design something truly ground breaking, they can implement it but only if someone designs it for them.

Qt is a good foundation for not only a GUI but entire application development paradigm that is at least evolutionary if not revolutionary. But this needs a tight team made of its core developers, it is not an endeavor that can run on community efforts. An innovative development API can easily win Qt a developer base in the realm of millions and make it more popular than any other solution, which I think is deeply in the interest of Digia.

The big question is whether Digia really wants to make something out of Qt, or just take advantage of getting it for pennies in order to milk it dry???

7 says:

*make that “a good software architect” – got a little distracted with a hardware review there…

8 says:

@Jason Barron: Why do the changes in backend technology (OpenGL, also Scenegraph) as you describe here imply such a radical change in the middle (procedural vs declarative) and at the front layer (C++ vs JavaScript)? These should be independent choices. I am perfectly happy with your backend change. I remember I was less happy when I was told that raster painting was all I needed when Qt 4 came out. I am not so happy with having some magic engine bindings without me being able to control it. I am not happy at all with you inventing a new language in front and making that the only way to access the whole stack. This should not be needed in a properly engineered stack.

Jason Barron says:

@8: This backend change is not dictating any changes in the “middle” or the “front” of the stack. If anything, it is the other way around in that the UI language and the QtQuick items could be implemented more efficiently using an OpenGL backend. ANGLE simply provides an OpenGL implementation on top of DirectX. If you want to access this API using procedural C code instead of declarative QML, that is absolutely possible using the same approach you would for accessing any other OpenGL implementation.

danny77uk says:

7 wrote:
“I was kind of hoping with the transfer to Digia Qt would go back to to its C++ roots, stop investing the majority of development efforts in that nonsense QML. Yet what I see is Qt becomes even harder, more complex and more tedious to work with, all in the name of QML and the requirements it has”

I agree completely. QML is snowballing out of control, trying to be everything for everyone and it’s dependencies are everywhere if you use it or not.

Real languages need standards and cross-platform support. Real languages like C++ which have a future outside of any one platform or vendor. No one wants is going to build the next killer app using a ‘framework of the week’ maintained by a handful of guys in single company, usable through a single IDE.

I installed the latest Qt5 beta just recently on OSX and was shocked had just how poor it was. Every single QML executable crashed, the maintenance tool wouldn’t run (the .app bundle was damaged). Even the old QWidget demos were glitchy and unstable. I’ll be sticking to Qt 4.8 for the foreseeable future.

Qt is on the ropes. You guys don’t have the resources to create your own ecosystem any more. You need to concentrate on what made Qt great in the first place – the C++ API. If I wanted to use a high-level language to build UIs, I’d use PyQt.

C++ is going through a renaissance right now! You guys should be building on that.

Spin off QML into a ‘solution’ for those who want it and leave Qt alone.

Yetistr says:

>Posting comments on a blog saying “QML sux, C++ rulez” is a little too vague to convert into a roadmap intem :-p

… and this is how valid concerns are slighted … as I say: the worst is that nobody seems to care. Sad indeed.

Jason Barron says:

@Yetistr: It wasn’t my intention to downplay your concerns. The point I was trying to make is that this is not really the best place to raise those specific concerns.

Ettistr_no3 says:

>Posting comments on a blog saying “QML sux, C++ rulez” is a little too vague to convert into a roadmap intem :-p

… and this is how valid concerns are slighted … as I say: the worst is that nobody seems to care. Sad indeed.

Why I cannot see my old messages? I see, so the messages that are not align with the current nonsense are banned now.

I hope better winds for Qt development.

Jason Barron says:

@Ettistr_no3: I assure you that no one here is deleting any old messages you have written unless they are spam. I looked in the spam filter and couldn’t find anything belonging to you. If you are referring to older posts (pre-Digia) then it’s possible something was lost during the transfer from Nokia to Digia, but a quick look at older posts seems to indicate comments transferred successfully.

Qb says:

BTW, by doing compile time selection of ANGLE you are going to cause very big troubles to everyone who does Qt + opengl 🙂
Also angle seems to be very limited in respect to common opengl found nowadays.
In past, I did some interesting things by using OpenGL + QML view. A very nice thing was the possibility to mix opengl code within a QML view. Anyway, code can be adapted to use ANGLE anyway.

The fact that QtQuick2 requires opengl 2 is pretty reasonable (it doesn’t make sense at all to use older opengl functions anymore), but for scenarios like using QML to do desktop things and not interactive graphic (see QML desktop components) , a solution for very limited hardware would make it more portable and usable. I’m really looking forward for this kind of scenario to start adopting qt5.
And also eventually you’ll get easy support for DX10 + metro 🙂

I don’t see a problem in the QML shift, widgets as we know them are going to die, sooner or later. What I really like to see would be a good and flexible set of QML components, both for desktop and/or devices. By now the trolls concentrated very much on the infrastructure, using QML today is still “doing everything from scratch, again and again”.

Mika Pesonen says:

Correct me if I’m wrong but I have understood it so that ANGLE works only with DX9 and it translates GLSL shader language to HLSL and then uses the DX9 source compiler to compile the provided HLSL source.

However, Windows Phone 8 (and RT?) is using DX11 and there is no option to compile from a HLSL source file on the fly but you have to compile your shaders to binary format offline. There is no public specification for the new DX11 binary format so you cannot do your own GLSL to DX11 binary format converter.

So how is Qt 5.0 going to support WP8?

Coming a bit late, but AFAIK OpenGL from the Windows SDK is 1.1, but through glGetProcAddress() any API might be available depending on the driver. Since this is a big nuisance, there are certain workarounds – using gl3w, glew, glee, etc.

But most recently some nvidia folks created the REGAL project, which is binary replacement/wrapper for OpenGL and comes with emulation modes for missing features –

ANGLE is also very cool, since it’s D3D in OpenGL ES2 clothes (Chrome & Mozilla use it). But you should think about using one or another at runtime, not compile-time.

Then there is OpenGL ES2 provided by certain OpenGL ICD drivers (nvidia, ATI) but the API is exposed different everytime.

But then again (and again) due to Windows 8 miserable state, you might have to bite the bullet and use ANGLE… But Please check REGAL in the mean time.

Parhs says:

They still sell brand new hardware with Intel GMA that dont have OpenGl 2.0 (oh dude).
So probably this might work only ?

Commenting closed.

Get started today with Qt Download now