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 <development-bounces+simon.hausmann=qt...@qt-project.org> on behalf of Shawn Rutledge <shawn.rutle...@qt.io> 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
