On Thu, May 12, 2011 at 4:42 PM, <gunnar.sle...@nokia.com> wrote: > > On May 12, 2011, at 3:15 PM, ext Marius Cirsta wrote: > >> It is said that Qt 5 will have a dependency on OpenGL ES 2.0. From >> what I understand this will be a must to run any Qt 5 application. >> >> 1) Suppose I write a simple window with an OK button which I then >> press and the windows closes, all in Qt 5 of course. >> How will this work on an older PC that doens't support OpenGL ES >> 2 or DirectX 9 for Angle to work ? A software renderer would also be >> slow and consume useful CPU. > > We are considering if we Qt should ship a software GL implementation by > default that we could fall back to in cases where no GL is available. Bear in > mind that QPainter on windows also is 100% software based. A good GL software > implementation should not be any worse. In fact it has potential for being > better. Such a GL software implementation doesn't exist today, but > initiatives like llvmpipe are showing good promise. > > When only showing widgets, no QML, we might even stick to the traditional > path and just blit the rasterbuffer used to render widgets to screen. This > means a bit of added complexity in the software stack, but technically > doable. You wouldn't be able to run any of the new QML things coming out, but > the QPushButton will show. > >> 2) How will something that runs very smooth now without any 3D >> acceleration ( Unity 2D ) run in Qt 5 ? What about KDE which runs just >> fine right now and doesn't need 3D capabilities ? > > A good software implementation of GL should not be any worse than our raster > paint engine. Neither for battery nor for performance. > > There are however fewer and fewer chips that ship without any GL > capabilities, so over time (we are talking a year or two before this is > mainstream technology after all), we expect GL to be common in most netbooks > >> 3) What about embedded devices where the manufacturer hasn't and >> doesn't even want to add 3D capabilities to that product. Let's say >> it's a POS. Shoud a 3D accelerator be added just so he can use the Qt >> toolkit ? > > The cost difference to support OpenGL for a System on Chip is dropping fast > and most of the industry is changing towards these types of chips. And in the > extreme cases where a GL chip is absolutely not possible, there is still the > option of using a software implementation of GL. > >> 4) And last but not least , what about serious bugs in the OpenGL >> drivers ? What do you tell someone that finds his Qt 5 programs looks >> weird , ah it's your drivers not supporting OpenGL ES 2.0 correctly , >> sorry. Please contact your driver manufacturer, nothing I can do about >> it , not my fault. > > We have briefly discussed this internally, and if we ship a software driver, > we could offer to fall back to software GL in the case of bad drivers. How > this would look in practice, I don't know, but it is an option. > >> I know the code will be simpler if OpenGL ES 2.0 is a requirement, I >> can imagine adding alternative code paths and such would require some >> serious effort. Still I think it's the right thing to do. > > Here I disagree. We have learned a hard lesson over the last few years. We > are not able to make good use of modern hardware with our current graphics > architecture and we need to change it to stay relevant in the future. I've > written several blogs about this on labs in the past. > > If we had provided a QML-only API without any C++ then we could have offered > the QGraphicsView/QPainter based QML 1 based implementation as a drop-in, but > we want to open up for advanced views implemented in C++ for users to support > what they need. > > And once we have raised the bar to include OpenGL, we can start to offer a > lot more. > >> >> Even Microsoft provides a solution to run Windows 7 without a good >> graphics card ( DX 9 capable ). Sure it doesn't look so good and of >> course you loose some eye candy but it works, it gets the job done. >> Same thing with OS X or KDE. > > > A software implementation of GL would solve that, though OSX hardware always > guarantees GL these days, so there it wouldn't be needed. > > So to sum up.. We believe that GL problems can be solved by GL hardware being > more common in the coming years, at least on embedded this is a very clear > trend. The remaining ones could be solved by a software renderer. We don't > have such a software renderer yet, but maybe someone is willing to help us in > getting it.
Are you guys completely certain that in the timeframe when you expect Qt5 to be released and adopted, an OpenGL-to-DirectX translation layer for Windows and an OpenGL software renderer for platforms without appropriate hardware acceleration, capable of performing and rendering to Qt's exacting standards, will both be available? It seems vaguely odd to make big, fundamental decisions like this on the basis of "well, maybe things will work themselves out by then". I'm not disputing that these are solvable problems, and that considerable progress may already have been made in solving them. But by the time Qt5 ships you presumably don't want these things to be "mostly done", you need them to be flawless. > > cheers, > Gunnar > _______________________________________________ > Qt5-feedback mailing list > Qt5-feedback@qt.nokia.com > http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback > -- Work is punishment for failing to procrastinate effectively. _______________________________________________ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
