One thing which really needs to be stressed on this list: The historical pattern of:
1) User A buys a laptop with system A on it 2) Obliterates it 3) Installs an OS which uses Qt on it 4) Struggles to restrain the hardware from eating the family cat is clearly not Qt 5's primary design focus/use case. Most hardware manufactured over the past 5 years has some kind of dedicated GPU; the problem is access to drivers and utilization of said hardware. When the OEM does the integration you can rely on these drivers being present and being nicely preintegrated/tested against Qt on arrival. Platforms like Meego already spec OpenGL (ES 2) as part of their compliance requirements: http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.1.80.1.pdf So Qt 5 would not be making this demand, it would already be set by the underlying platform, and to be frank any competitive platform is going to have a similar baseline. Yours sincerely, Donald Carr 2011/5/18 Gábor Lehel <[email protected]>: > 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 > -- ------------------------------- °v° Donald Carr /(_)\ Professional Penguin lover ^ ^ _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
