2011/5/18 Gábor Lehel <[email protected]>: > On Thu, May 12, 2011 at 4:42 PM, <[email protected]> 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.
I forgot to add: this is if you don't want Qt5's suitability for cross-platform development on the desktop to noticeably regress compared to Qt4. (Of course, if the QWidget stack ends up bypassing the new OpenGL/scene graph architecture entirely then at least existing applications won't be negatively impacted -- but it sure would be nice if developers didn't have to choose between comparatively-outmoded QWidgets and impaired cross-platform portability going forward, either.) > >> >> cheers, >> Gunnar >> _______________________________________________ >> Qt5-feedback mailing list >> [email protected] >> http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback >> > > > > -- > Work is punishment for failing to procrastinate effectively. > -- Work is punishment for failing to procrastinate effectively. _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
