Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Shawn Rutledge]

> On 26 Apr 2016, at 14:56, Simon Hausmann  wrote:
> 
> Hi,
> 
> The way you describe the problem sounds like it is specific to tablet events 
> on X-Windows. In my opinion a solution to the problem applied to the 5.6 
> branch of Qt
> should also be limited to tablet events on X-Windows. Wouldn't it therefore 
> be easiest to simply not do tablet event compression on X-Windows without any 
> changes to the API?

I had that idea early on, but somebody warned me that the disadvantage is 
having to dig into the event too much just to decide.  This decision is 
preliminary, before really handling the event, so it needs to be quick.  But 
the compression code already spends a little time, and detecting whether it’s a 
tablet event isn’t much more work.  Maybe we will solve the problem that way 
then.

https://codereview.qt-project.org/#/c/157348/

> The day somebody really wants event compression for tablet events, we can 
> consider introducing new API perhaps in a new minor release.

Yeah.  But we could still get https://codereview.qt-project.org/#/c/157011/ 
into 5.7, in case somebody wants to disable all event compression.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Boudewijn Rempt]

On Wed, 27 Apr 2016, Lisandro Damián Nicanor Pérez Meyer wrote:


On Wednesday 27 April 2016 08:50:48 Boudewijn Rempt wrote:
[snip]

As a Debian developer, you might also consider that you should never
ever package Krita 3 for Debian with a Qt 5.6 without this fix. You'd have
to carry the patch for Qt 5.6 or forego packaging Krita (and later on,
OpenToonz).


The only Qt patches we accept are the ones ACKed by upstream (ie, someone from
the Qt project) or the ones that are really debian-specific. Projects using Qt
should use whatever the official Qt releases ship.

So backporting a merged fix is OK, but a patch to alter standard Qt behavior
not yet accepted is not ok.


Well, deciding upon your policy is certainly your prerogative.

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Lisandro Damián Nicanor Pérez Meyer]

On Wednesday 27 April 2016 08:50:48 Boudewijn Rempt wrote:
[snip]
> As a Debian developer, you might also consider that you should never
> ever package Krita 3 for Debian with a Qt 5.6 without this fix. You'd have
> to carry the patch for Qt 5.6 or forego packaging Krita (and later on,
> OpenToonz).

The only Qt patches we accept are the ones ACKed by upstream (ie, someone from 
the Qt project) or the ones that are really debian-specific. Projects using Qt 
should use whatever the official Qt releases ship.

So backporting a merged fix is OK, but a patch to alter standard Qt behavior 
not yet accepted is not ok.


-- 
Geek Inside!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Boudewijn Rempt]

On Tue, 26 Apr 2016, Lisandro Damián Nicanor Pérez Meyer wrote:


Please correct me if I'm wrong: the feature which will break API was added in
5.6.0, and we can say that most of the people out there are not using it.

Ideally API/ABI should not be broken without a SONAME change. If I had some
Qt5 app using it already I would be forced to do a hack in our packaging:
faking a SONAME change.

Now it just happens that we in Debian haven't pushed 5.6 to unstable yet (we
are waiting for 5.6.1) so it's not a problem for us now. It will be if pushed
with 5.6.2 instead of 5.6.1.

Of course I'm only speaking for us Debian, I don't know the impact on other
distros.


As a Debian developer, you might also consider that you should never
ever package Krita 3 for Debian with a Qt 5.6 without this fix. You'd have
to carry the patch for Qt 5.6 or forego packaging Krita (and later on,
OpenToonz).

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Thiago Macieira]

On terça-feira, 26 de abril de 2016 20:51:30 PDT Lisandro Damián Nicanor Pérez 
Meyer wrote:
> Please correct me if I'm wrong: the feature which will break API was added
> in 5.6.0, and we can say that most of the people out there are not using
> it.

No ABI breakage happened. There's a change in behaviour that most applications 
will want, but some don't. We're trying to figure out a way to allow those 
exceptions to revert to the old behaviour.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Lisandro Damián Nicanor Pérez Meyer]

Please correct me if I'm wrong: the feature which will break API was added in 
5.6.0, and we can say that most of the people out there are not using it.

Ideally API/ABI should not be broken without a SONAME change. If I had some 
Qt5 app using it already I would be forced to do a hack in our packaging: 
faking a SONAME change.

Now it just happens that we in Debian haven't pushed 5.6 to unstable yet (we 
are waiting for 5.6.1) so it's not a problem for us now. It will be if pushed 
with 5.6.2 instead of 5.6.1.

Of course I'm only speaking for us Debian, I don't know the impact on other 
distros.

-- 
Wiki participants are, by nature, a pedantic, ornery, and unreasonable bunch.
So there's a camaraderie here we seldom see outside of our professional
contacts.
  http://www.c2.com/cgi/wiki?WhyWikiWorks

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Alejandro Exojo]

El Tuesday 26 April 2016, Shawn Rutledge escribió:
> Personally I think event compression should be a cross-platform feature if
> we’re going to have it.  The event-pileup problem can happen also on
> Windows for example, but it seems that we never implemented event
> compression on any platform other than X11.  I’m not sure why.  But we
> don’t plan to do that in the 5.6 series, anyway.

Are you thinking in a generic event compression feature, not only for input 
events? For example, I emit a signal with a "last value" parameter with a 
queued connection (or I just post the event manually), and the receiver can 
discard previous values that it did not have time to process because it was 
slower than the sender. That's not an input event, but it happens through the 
event system anyway.

Now I would think of reimplementing QCoreApplication::notify, but there is the 
warning about Qt6 change, and there is no way to access the already posted 
events (that I know of). There are some reports asking for the feature, BTW:

https://bugreports.qt.io/browse/QTBUG-2688
https://bugreports.qt.io/browse/QTBUG-44293

I suppose if notify() was "soft deprecated" there is not that much 
time/interest in doing this?

> I was told to request this exception on the mailing list, because we
> usually try to maintain source compatibility between releases.

This change being added doesn't worry me much (I don't think it will set my 
computer on fire), so I'm not opposing to it (honestly!) but I don't think the 
issue is source compatibility. It's adding features on already released 
branches. There is a process to ensure that code released has gone through a 
testing procedure. Adding this is bypassing it, while other much innocent 
changes have to wait.

Let me point at some examples, for illustration purposes:

A one line change that fixes QPalette::resolve. It's an obvious fix, but it 
wasn't unit tested, and it changes behaviour, so who knows what might break:

https://codereview.qt-project.org/148552

A microoptimization that looks entirely safe to everyone, but it's not 
critical, so it wasn't committed to the stable branch:

https://codereview.qt-project.org/138746

A simple setter/getter/member addition to QIcon and one line addition to the 
OS X platform plugin to make the system tray icons look properly on Yosemite 
and newer. It's trivial, but it was new API, so it could not go in the stable 
branch:

https://codereview.qt-project.org/115120

Again, honestly, I don't have an axe to grind. Two of this issues affected me, 
but not a lot, and it's already solved, so no big deal now. I'm just a bit 
confused when I see this differences in interpretation of the rules, because I 
don't know what to expect and what not.

Thanks.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Thiago Macieira]

On terça-feira, 26 de abril de 2016 10:02:46 PDT Matthew Woehlke wrote:
> Since when does SC mean that code written for version Y must compile
> against version X (X < Y)? Usually it's only the other way around... Or
> do I not understand what would break, here? (Is the problem just that
> code written against 5.6.1 would not compile with 5.7.0?)

We offer bi-directional source and binary compatibility inside the same minor 
version. Code written for 5.x.y also compiles and runs on 5.x.z, whichever 
values of y and z are.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Matthew Woehlke]

On 2016-04-26 08:08, Shawn Rutledge wrote:
> If the application does not handle high-frequency events (mouse 
> movements and window moves/resizes) quickly enough, some events will 
> be dropped.

Do you really mean dropped? Or do you mean merged? There is a HUGE
difference...

Please don't EVER simply discard input events (at least, not without
being specifically asked to do so); that is a form of data loss.

> https://codereview.qt-project.org/#/c/157011 adds an application
> attribute, AA_CompressHighFrequencyEvents, which is true by default
> on X11, and you can unset it to disable the compression. The
> advantage of doing it this way is that you can control it
> dynamically: maybe you want to have compression only some of the
> time, depending on what the application is doing with the events. But
> it requires an exception to the source compatibility rule: if you
> have used that flag in your application, then you won’t be able to
> compile it with 5.6.0 anymore.

Since when does SC mean that code written for version Y must compile
against version X (X < Y)? Usually it's only the other way around... Or
do I not understand what would break, here? (Is the problem just that
code written against 5.6.1 would not compile with 5.7.0?)

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Simon Hausmann]

Hi,

The way you describe the problem sounds like it is specific to tablet events on 
X-Windows. In my opinion a solution to the problem applied to the 5.6 branch of 
Qt
should also be limited to tablet events on X-Windows. Wouldn't it therefore be 
easiest to simply not do tablet event compression on X-Windows without any 
changes to the API?

The day somebody really wants event compression for tablet events, we can 
consider introducing new API perhaps in a new minor release.

Simon


From: Development  on 
behalf of Shawn Rutledge 
Sent: Tuesday, April 26, 2016 2:08 PM
To: development@qt-project.org
Subject: [Development] Exception to source compatibility: adding 
AA_CompressHighFrequencyEvents flag

In 5.6.0, an event compression feature was added to the xcb platform plugin, to 
fix QTBUG-40889 and QTBUG-47069.  That is here: 
https://codereview.qt-project.org/#/c/126136/  Qt 4 had a similar feature, and 
then it was possible to turn it on or off, using widget attribute 
WA_NoX11EventCompression.  Using a widget attribute doesn’t make sense now, 
because you might not be using widgets, and the platform plugin isn’t 
necessarily aware of them even if you are.  This time the compression was done 
with no way to turn it off, and QTBUG-44964 was written up as a task to come up 
with a way to enable/disable the compression.  If the application does not 
handle high-frequency events (mouse movements and window moves/resizes) quickly 
enough, some events will be dropped.  So, sufficiently responsive applications 
shouldn’t experience any event compression.

This causes some trouble for drawing-tablet applications like Krita though.  
It’s not right to compress move events from tablet devices by default, because 
the application may be using some complex brush-painting algorithm, but 
nevertheless the artist using it expects to get smooth brush strokes, not 
jagged piecewise ones.  So maybe the XCB plugin simply shouldn’t compress 
those; but then we’d have a behavior change in 5.6.1 relative to 5.6.0, and 
anyway the decision to compress or not doesn’t pay attention to which device 
it’s coming from, so far.  It might be possible though.

Personally I think event compression should be a cross-platform feature if 
we’re going to have it.  The event-pileup problem can happen also on Windows 
for example, but it seems that we never implemented event compression on any 
platform other than X11.  I’m not sure why.  But we don’t plan to do that in 
the 5.6 series, anyway.

https://codereview.qt-project.org/#/c/156755 makes it possible to turn off the 
compression feature by setting an env variable; that works OK, but it’s meant 
as a short-term hack: we know that we need proper public API eventually.  The 
question is whether we should be adding API in a patch release like 5.6.1.  Of 
course this time it’s an LTS release, so it seems reasonable to expect 
long-term solutions to problems like this, rather than short-term hacks.  And 
it was brought up that env variables are inherited by child processes, so if 
for some reason your paint program starts child processes, you might need to 
unset the env variable first.  And as usual, env variables which affect 
behavior in platform plugins need to be set before the QGuiApplication is 
created, because the platform plugin reads it at static-initialization time, 
when it is loaded.

https://codereview.qt-project.org/#/c/157011 adds an application attribute,
AA_CompressHighFrequencyEvents, which is true by default on X11, and you can 
unset it to disable the compression.  The advantage of doing it this way is 
that you can control it dynamically: maybe you want to have compression only 
some of the time, depending on what the application is doing with the events.  
But it requires an exception to the source compatibility rule: if you have used 
that flag in your application, then you won’t be able to compile it with 5.6.0 
anymore.  (You could ifdef it though.)  Of course forward compatibility 
shouldn’t be a problem.  And even if we implement compression as a 
cross-platform feature eventually, we can still use that flag to enable/disable 
it.

I was told to request this exception on the mailing list, because we usually 
try to maintain source compatibility between releases.

So, any objections?

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Giuseppe D'Angelo]

On Tue, Apr 26, 2016 at 1:08 PM, Shawn Rutledge  wrote:
>
>
> I was told to request this exception on the mailing list, because we usually 
> try to maintain source compatibility between releases.
>
> So, any objections?

(Having been the one asking for bringing the matter up to the ML): an
exception in this case can be agreeable. (Note that however these
exceptions may have an impact in the "current" release branch too,
that is, suppose that 5.7 was already released, a 5.6->5.7 merge would
then break compatibility there too.)

-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Morten Sorvig]

> On 26 Apr 2016, at 14:08, Shawn Rutledge  wrote:
> 
> Personally I think event compression should be a cross-platform feature if 
> we’re going to have it.  The event-pileup problem can happen also on Windows 
> for example, but it seems that we never implemented event compression on any 
> platform other than X11.  I’m not sure why.  But we don’t plan to do that in 
> the 5.6 series, anyway.

For OS X: My first thought is that we should let the OS compress events for us. 
Which it does, at least for wheel events. Event compression in Qt can then be a 
feature for those platforms that need it (implemented in cross-platform code), 
but not mandatory.

Cheers,
Morten
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development