[Interest] Input Latency Issues in QtQuick

[Agocs Laszlo]

Yes, the "laggy" behavior is perfectly reasonable on some configurations, given that the movements of the mouse cursor, the mouse event input rate, etc. are all up to the system and Qt has no synchronization between that and the display. When vsync is enabled, which is true by default for pretty much all platforms (except Windows in pre-5.3), such a "lag" is expected. (but may not be present on all systems, depending on how the cursor handling/drawing is done)

The exception are of course the platforms without a windowing system that draw the mouse cursor themselves (like eglfs). These have no such issues since the cursor is rendered by the application itself.

Cheers,
Laszlo
________________________________________
From: interest-bounces+laszlo.agocs=digia.com at qt-project.org [interest-bounces+laszlo.agocs=digia.com at qt-project.org] on behalf of Sean Harmer [sean.harmer at kdab.com]
Sent: Monday, March 24, 2014 10:02 AM
To: interest at qt-project.org
Subject: Re: [Interest] Input Latency Issues in QtQuick

Hi Damian,

On Monday 24 March 2014 07:42:43 Damian Ivanov wrote:
> Hmm 2 options Jason:
> a) You are not affected by the bug but are uneducated about QML (it
> should run on embedded systems and slow systems too)
> b) You have some sickness about hand-eye coordination.

No need to be rude. There are a multitude of configuration options that may
lead to Jason seeing different behaviour to yourself. Perhaps he does not have
his display tied to vsync, exact driver version and implementer, choice of
render loop type in QML,...

Cheers,

Sean

>
> 16G, FX8320 Radeon 5750 for the bug report, do we have one yet?
>
> 2014-03-24 3:07 GMT+01:00 Jason H <scorp1us at yahoo.com>:
> > Yeap, I did that. No delay.
> >
> > Perhaps you need a faster computer?
> >
> >
> > ________________________________
> > From: Damian Ivanov <damianatorrpm at gmail.com>
> > To: Jason H <scorp1us at yahoo.com>
> > Cc: Willem Bennekom <cumulatm at gmail.com>; "<interest at qt-project.org>"
> > <interest at qt-project.org>
> > Sent: Sunday, March 23, 2014 1:44 PM
> >
> > Subject: Re: [Interest] Input Latency Issues in QtQuick
> >
> > go to one corner and move the mouse cursor fast diagonal to the other
> > corner. you will see that sometimes the rectangle is 1cm away from
> > your mouse cursor.
> >
> > That's called delay.
> >
> > 2014-03-23 16:55 GMT+02:00 Jason H <scorp1us at yahoo.com>:
> >> I don't have a problem with the test case.
> >> AMD A6 Laptop Mint 16/64bit
> >>
> >> ________________________________
> >> From: Damian Ivanov <damianatorrpm at gmail.com>
> >> To: Willem Bennekom <cumulatm at gmail.com>
> >> Cc: "<interest at qt-project.org>" <interest at qt-project.org>
> >> Sent: Saturday, March 22, 2014 6:28 PM
> >> Subject: Re: [Interest] Input Latency Issues in QtQuick
> >>
> >> hmm I can confirm the problem with the test case, depending on what
> >> application you have this can be from absolutely not important to
> >> quite a deal-breaker...
> >> I would fill a bug.
> >>
> >> 2014-03-22 23:09 GMT+02:00 Willem Bennekom <cumulatm at gmail.com>:
> >>> For me, the lagging is clearly noticeable on all platforms where vsync
> >>> is
> >>> enabled.
> >>> (Macbook Pro (Nvidia), Linux/Windows Desktop with Nvidia, Windows
> >>> Desktop
> >>> with AMD + Angle.
> >>> It hapopens with all Qt Quick versions.)
> >>>
> >>> Here's a minimal test scene (rectangle follows mouse):
> >>> http://pastie.org/pastes/8959817
> >>>
> >>> 2014-03-22 18:37 GMT+01:00 Damian Ivanov <damianatorrpm at gmail.com>:
> >>>> for the record: I can't confirm this, QML input is instantly here free
> >>>> radeon driver (5series) on openSUSE 13.1 64bit.
> >>>>
> >>>> 2014-03-22 15:46 GMT+01:00 Willem Bennekom <cumulatm at gmail.com>:
> >>>> > With its current architecture, QtQuick has input latency issues:
> >>>> > The scene reacts to user input with a slight, but noticeable delay,
> >>>> > which
> >>>> > makes
> >>>> > QtQuick apps feel clumsy and unpleasant to use.
> >>>> >
> >>>> > I guess this is related to vsync handling, where input events don't
> >>>> > immediately
> >>>> > trigger a repaint while the render thread waits until the framebuffer
> >>>> > is
> >>>> > swapped.
> >>>> >
> >>>> > The only exception are Windows platforms with native OpenGL on ATI
> >>>> > cards,
> >>>> > where the framerate seems to be uncapped:
> >>>> > The rendering is super responsive, almost like Qt Widgets.
> >>>> > The drawback is that render thread animators are broken, as they
> >>>> > aren't
> >>>> > synced to 60 Hz.
> >>>> >
> >>>> > 1. Is there a way to hack Qt to get this Windows+OpenGL+ATI rendering
> >>>> > behavior on all platforms?
> >>>> >
> >>>> >    Maybe some tweaks in qsg*renderloop.cpp?
> >>>> >
> >>>> > 2. Are there plans to implement a rendering scheme that reduces input
> >>>> > latency?
> >>>> >
> >>>> > Thanks
> >>>> > Willem
> >>>> >
> >>>> > _______________________________________________
> >>>> > Interest mailing list
> >>>> > Interest at qt-project.org
> >>>> > http://lists.qt-project.org/mailman/listinfo/interest
> >>
> >> _______________________________________________
> >> Interest mailing list
> >> Interest at qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/interest
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
_______________________________________________
Interest mailing list
Interest at qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest