Skip to content
GitLab
Select Git revision
  1. 12 Dec, 2013 - 1 commit
  3. 03 Dec, 2013 - 1 commit
  5. 27 Nov, 2013 - 1 commit
    • Robin Burchell's avatar
      Delay renderWindow with a timer · 7811c22f
      Robin Burchell authored 
      
Add an exhaust delay to QSGGuiThreadRenderLoop. Some updates
may be done with posted events, and maybeUpdate event competed
with those, leading to partial updates and frames drawn twice.

Change-Id: I532bff692c597eeba5bbd6def89ae68c80fdd69b
Done-with: Mikko Harju <mikko.harju@jollamobile.com>
Reviewed-by: default avatarGunnar Sletta <gunnar.sletta@digia.com>
      7811c22f
  7. 19 Nov, 2013 - 1 commit
  9. 18 Nov, 2013 - 1 commit
  11. 05 Nov, 2013 - 1 commit
  13. 01 Nov, 2013 - 1 commit
  15. 30 Oct, 2013 - 1 commit
    • Gunnar Sletta's avatar
      Use one render loop per QQuickWindow · 906d5c5c
      Gunnar Sletta authored 
      
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: default avatarSean Harmer <sean.harmer@kdab.com>
      906d5c5c
  17. 30 Sep, 2013 - 1 commit
  19. 26 Sep, 2013 - 1 commit
  21. 21 Sep, 2013 - 1 commit
    • Gunnar Sletta's avatar
      Animators - Render thread animation system · a0f8be40
      Gunnar Sletta authored 
      
This introduces 6 new QML types for animating state in the
scene graph when the UI thread is blocked. The QObject property
being animated is updated after the animation completes.

It works also with the "windows" and "basic" render loops, but
offer litte benefit then compared to in the "threaded" case.

Change-Id: Ic19e47c898c0b8bd53e457db922b3c9c457c8147
Reviewed-by: default avatarLars Knoll <lars.knoll@digia.com>
      a0f8be40
  23. 07 Jun, 2013 - 1 commit
    • Alan Alpert's avatar
      Set incubation controller when a Window{} is loaded via QQmlApplicationEngine · 9d75626b
      Alan Alpert authored 
      
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: default avatarAlan Alpert <aalpert@blackberry.com>
Reviewed-by: default avatarGunnar Sletta <gunnar.sletta@digia.com>
      9d75626b
  25. 06 May, 2013 - 1 commit
  27. 24 Apr, 2013 - 1 commit
    • Gunnar Sletta's avatar
      Renderloop for Windows · 73d8bcda
      Gunnar Sletta authored 
      
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: default avatarFriedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: default avatarSamuel Rødal <samuel.rodal@digia.com>
      73d8bcda
  29. 17 Apr, 2013 - 1 commit
    • Gunnar Sletta's avatar
      Remove dead code. · 909d3a57
      Gunnar Sletta authored 
      
The renderWithoutShowing was a piece of functionality that we
experimented on long ago and it never quite worked and has
it currently only adds bloat.

It would be sensible to be able to render a window without showing
it on screen, such as for testing purposes, but then it should
be done through proper public API and thouroughly supported
cross platform.

Change-Id: I6bea7335f769c038a8167bad77c2dba171359be9
Reviewed-by: default avatarYoann Lopes <yoann.lopes@digia.com>
Reviewed-by: default avatarSamuel Rødal <samuel.rodal@digia.com>
      909d3a57
  31. 04 Apr, 2013 - 2 commits
  33. 13 Mar, 2013 - 1 commit
  35. 21 Feb, 2013 - 1 commit
  37. 18 Feb, 2013 - 1 commit
  39. 18 Jan, 2013 - 1 commit
    • Gunnar Sletta's avatar
      Complete rewrite of threaded render loop. · ebe8b940
      Gunnar Sletta authored 
      
This change starts using the superior implementation of the scene graph
render loop which has been worked on in the scenegraph-playground
project for a while. It uses a far more straightforward locking/sync
paradigm compared to the existing one and is less deadlock and error
prone. It also enables the scene graph thread to run on its own when
the GUI thread is blocked, enabling threaded animations.

This changes also introduces a naming change inside Qt Quick from
"Window Manager" -> "Render Loop" as that fits better to what the
code does.

Change-Id: I1c2170ee04fcbef79660bd7dae6cace647cdb276
Reviewed-by: default avatarSamuel Rødal <samuel.rodal@digia.com>
      ebe8b940
  41. 10 Jan, 2013 - 1 commit
  43. 23 Dec, 2012 - 1 commit
    • Thiago Macieira's avatar
      Fix other warnings in qtdeclarative found by GCC 4.7 · 6a36bcb7
      Thiago Macieira authored 
      
qml/qml/qqmlimport.cpp:982:30: error: unused parameter 'errors' [-Werror=unused-parameter]
quick/util/qquickanimationcontroller.cpp:66:6: error: unused parameter 'job' [-Werror=unused-parameter]'
quick/items/qquickshadereffectnode.cpp:160:17: error: case value '38' not in enumerated type 'QVariant::Type' [-Werror=switch]
quick/items/qquickwindowmanager.cpp:286:60: error: 'renderTime' may be used uninitialized in this function [-Werror=maybe-uninitialized]
quick/items/qquickitem.cpp:5267:67: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]

and a few more repeated from the above

Change-Id: Id1950c6ba98f7f8475975716b21bd795ecb4bd20
Reviewed-by: default avatarAlan Alpert <aalpert@rim.com>
      6a36bcb7
  45. 16 Nov, 2012 - 1 commit
    • Samuel Rødal's avatar
      Use threaded renderer even without BufferQueueingOpenGL. · fb870763
      Samuel Rødal authored 
      
Without threaded rendering QML 2 often ends up running at half the
screen refresh rate on X11. Not having BufferQueuingOpenGL shouldn't
prevent us from using threaded rendering, since the issue of four
animating windows running at 1/4th of the screen refresh rate will
happen regardless of whether rendering happens on the main thread or in
a separate rendering thread.

Change-Id: I0edc818e6d762fa1faf13e7f2f47dfda132b6fdf
Reviewed-by: default avatarFriedemann Kleint <Friedemann.Kleint@digia.com>
      fb870763
  47. 20 Oct, 2012 - 1 commit
  49. 15 Oct, 2012 - 1 commit
  51. 28 Sep, 2012 - 1 commit
  53. 23 Sep, 2012 - 1 commit
  55. 10 Sep, 2012 - 3 commits
  57. 04 Sep, 2012 - 1 commit
  59. 24 Jul, 2012 - 1 commit
  61. 17 Jul, 2012 - 2 commits
  63. 01 Jun, 2012 - 1 commit
  65. 29 May, 2012 - 1 commit
    • Gunnar Sletta's avatar
      Enable QML_FIXED_ANIMATION_STEP by default with buffer queueing. · 4baa3f71
      Gunnar Sletta authored 
      
On Mac OS X and other systems with buffer queueing GL,
we have very jerky animations as the pipeline
does not block at regular intervals, causing the
current-time based animations to come out very jerky
despite us rendering at 60 FPS with a very good margin.

To remedy this, we switch the default so that we by default
advance with a fixed increment, making the uneven frames
not a problem. This then comes at the cost of that animations
will slow down if the application does not manage to render
within 16 ms, but this is an acceptible compromise. Aka,
now it will occationally look bad, as opposed to always bad
which it currently does.

Change-Id: I44a6c3e51f434e4235e49485182380ea531876d9
Reviewed-by: default avatarMichael Brasser <michael.brasser@nokia.com>
      4baa3f71
  67. 24 May, 2012 - 1 commit
  69. 22 May, 2012 - 1 commit
    • Gunnar Sletta's avatar
      Add QQuickCanvas::update() · 6a942251
      Gunnar Sletta authored 
      
We would like to make a distinction between QQuickItem::update()
which triggers updatePaintNode() to synchronize the scene
graph and requesting the toplevel QQuickCanvas to be repainted.

If we have this distinction in place it is possible for the
scene graph to detect that the scene is unchanged and avoid
rendering unless the user has explicitely asked for the
canvas to be repainted, which is often the case when hooking
into QQuickCanvas::beforeRender().

Change-Id: Ibe77f58423593deb217ef9f8082fa12009f45daf
Reviewed-by: default avatarSamuel Rødal <samuel.rodal@nokia.com>
      6a942251
  71. 21 May, 2012 - 1 commit