aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/scenegraph/qsgwindowsrenderloop_p.h
Commit message (Collapse)AuthorAgeFilesLines
* headers: Add missing override and remove redundant virtualAlexander Volkov2016-12-071-13/+13
| | | | | | Change-Id: Ifa816ebcd79372afca42dbd0dc0ecde006bb688a Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Enable building Qt Quick module with QT_NO_OPENGL definedAndy Nichols2016-03-221-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | Currently the Qt Quick module depends on either the OpenGL or OpenGLES headers being available at build time. Since we are adding support for adaptations that do not depend on OpenGL, it should be possible to build Qt Quick in environments that do not have OpenGL development headers. This does present many challenges though because in some cases GL types, and classes that require OpenGL are part of the public APIs. However since these classes were never available when QT_NO_OPENGL was defined, it should be possible to redefine the function signatures under this scenario, since it's not possible to break binary compatibility if there never were any binaries to break compatibility with. One of the bigger changes that was necessary to facilitate this change is creating interfaces out of QSGContext and QSGRenderContext. Here the default behavior was usage of OpenGL directly, even though subclasses could override all OpenGL usage. Making them interfaces should bring QSGContext and QSGRenderContext more in line with the other classes present in the adaptation layer. Change-Id: Iaa54dc0f6cfd18d2da1d059548abf509bd71f200 Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
* Updated license headersJani Heikkinen2016-01-191-14/+20
| | | | | | | | | | | From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new LGPL header instead of LGPL21 one (in those files which will be under LGPL v3) Change-Id: Ic36f1a0a1436fe6ac6eeca8c2375a79857e9cb12 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Add missing "We mean it" comments to private headers.Friedemann Kleint2015-10-061-0/+11
| | | | | | Task-number: QTBUG-48594 Change-Id: Ifc207938de7f0c8995fc712df92665f222612647 Reviewed-by: Alan Alpert <aalpert@blackberry.com>
* Update copyright headersJani Heikkinen2015-02-121-7/+7
| | | | | | | | | Qt copyrights are now in The Qt Company, so we could update the source code headers accordingly. In the same go we should also fix the links to point to qt.io. Change-Id: I61120571787870c0ed17066afb31779b1e6e30e9 Reviewed-by: Iikka Eklund <iikka.eklund@theqtcompany.com>
* Update license headers and add new licensesJani Heikkinen2014-08-251-19/+11
| | | | | | | | | - Renamed LICENSE.LGPL to LICENSE.LGPLv21 - Added LICENSE.LGPLv3 & LICENSE.GPLv2 - Removed LICENSE.GPL Change-Id: I84a565e2e0caa3b76bf291a7d188a57a4b00e1b0 Reviewed-by: Jani Heikkinen <jani.heikkinen@digia.com>
* Be even more tolerant towards broken platform behavior.Gunnar Sletta2013-11-221-2/+0
| | | | | | | | | | When the platform (Mac in particular) sends us exposes for windows which are not renderable, we store it for later and fake expose events when we get resized. Task-number: QTCREATORBUG-10814 Change-Id: I909bb5a920550589322afd97ae1834884754cf81 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Use one render loop per QQuickWindowGunnar Sletta2013-10-301-0/+5
| | | | | | | | | | | | | | | | | | | See the task for the full reasoning behind this patch. The threaded renderloop has been refactored to have one window per thread. This is mostly a simplification of the current code path where for loops over multiple windows are turned into if (window). The QSGContext has been split into two classes, QSGRenderContext for which there is one per OpenGLContext. The rest of the patch is name changes and a couple of cleanups in the hopes of simplifying this change. Task-number: QTBUG-33993 Change-Id: I31c81f9694d7da7474a72333169be38de62613c4 Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
* Fix license headers of QtQuick sources.Gunnar Sletta2013-09-301-1/+1
| | | | | Change-Id: I3750c47640bf21c3567c5fa1c4667e3e2552942e Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Allow QtQuick private headers to be used with QT_NO_KEYWORDS.Jocelyn Turcotte2013-09-121-1/+1
| | | | | | | | | | | This is necessary for the QtWebEngine module. This also adds an empty nokeywords test using the same mechanism as qtbase/tests/auto/tools/moc/no-keywords.h to find conflicts at compile time. Change-Id: I9df541720797dd61f078178c2af68ead18ff8bfe Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Set incubation controller when a Window{} is loaded via QQmlApplicationEngineAlan Alpert2013-06-071-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | This was the one convenience that was lost when transitioning templates from QQuickView + Item{} to QQmlApplicationEngine + Window{}. As the default window incubation controller was tied to the first window's frameSwapped, we could easily run into a situation where a secondary window required incubation while the first window was idle. This would then starve the incubation controller. Instead make it so that the renderloop emits "timeToIncubate" once it is done with a renderpass over all windows, so the incubator gets to run once and exactly once per vsync when animating. The incubator logic was also flawed in that it could post a lot of events to itself as a result of incubatingObjectCountChanged and thus starve system events while processing incubation requests. Now we start a timer and don't start it again until we have completed an incubation pass. Task-number: QTBUG-31203 Change-Id: Iea9e2c81efb46bb7875c70ccda0cdc4b3b3e58e7 Reviewed-by: Alan Alpert <aalpert@blackberry.com> Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
* Renderloop for WindowsGunnar Sletta2013-04-241-0/+114
The normal GUI thread render loop has several problems on windows. It does not do vsync animations and on some hardware, where the vsync delta is higher than the time it takes to fire a 16ms timer, the eventloop will always contain at least one event and we never return to processing non-client area events, like resize. Also, threaded OpenGL seems rather unstable, so the threaded renderer is not a stable option. So we introduce a windows based renderloop. It is fully cross platform but written to make the most out of the limitations which exist. The overall goal is: - vsync animations when allowed by the system. We get this by using an animation driver and advancing in sync with rendering - Keep system load low and allow for NC processing. The maybeUpdate function will start a short timer which will let the renderloop idle for few ms, allowing the eventloop to pick up system events. (this is similar to what the threaded renderer also does, btw) Change-Id: Ic192fd0ed7d5ecdaa2c887c08cbeb42c5de6b8a8 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>