[Interest] Any possible workaround for QTBUG-40889 ?

[Elvis Stansvik]

2016-07-01 14:49 GMT+02:00 Elvis Stansvik <elvstone at gmail.com>:
> 2016-07-01 14:01 GMT+02:00 Elvis Stansvik <elvstone at gmail.com>:
>> 2016-06-30 18:59 GMT+02:00 Thiago Macieira <thiago.macieira at intel.com>:
>>> On quinta-feira, 30 de junho de 2016 17:16:54 PDT Elvis Stansvik wrote:
>>>> Would it be possible to install a QAbstractNativeEventFilter and
>>>> somehow "fix-up" the event combination that makes the event
>>>> compression fail? Has anyone else been in the same boat?
>>>
>>> Yes, in combination with a non-native filter that detects when the event has
>>> been delivered and processed. You need to keep a state:
>>>
>>>  if event has been seen
>>>  and event has not been delivered
>>>         swallow event
>>
>> I'm not actually sure I understand this approach, would be great if
>> you could elaborate just a little.
>>
>> Also, how would I determine if an event has been "seen"? And how would
>> I correlate the non-native event and the native when I receive the
>> non-native one?
>>
>> Using this code:
>>
>> static inline bool isXIEvent(xcb_generic_event_t *event, int opCode)
>> {
>>     xcb_ge_generic_event_t *e = (xcb_ge_generic_event_t *)event;
>>     return e->extension == opCode;
>> }
>>
>> static inline bool isXIType(xcb_generic_event_t *event, int opCode,
>> uint16_t type)
>> {
>>     if (!isXIEvent(event, opCode))
>>         return false;
>>
>>     xXIGenericDeviceEvent *xiEvent =
>> reinterpret_cast<xXIGenericDeviceEvent *>(event);
>>     return xiEvent->evtype == type;
>> }
>>
>> MotionEventFilter::MotionEventFilter(QObject *parent) : QObject(parent)
>>   , m_xiOpCode(0)
>> {
>>     // Query the XInput extension for its major opcode
>>     int xiEventBase, xiErrorBase;
>>     XQueryExtension(QX11Info::display(), "XInputExtension",
>> &m_xiOpCode, &xiEventBase, &xiErrorBase);
>> }
>>
>> bool MotionEventFilter::nativeEventFilter(const QByteArray &eventType,
>> void *message, long *result)
>> {
>>     Q_UNUSED(result);
>>
>>     if (eventType == "xcb_generic_event_t") {
>>         auto event = static_cast<xcb_generic_event_t *>(message);
>>
>>         switch (event->response_type & ~0x80) {
>>         case XCB_MOTION_NOTIFY: {
>>             std::cout << "XCB_MOTION_NOTIFY" << std::endl;
>>             break;
>>         }
>>         case XCB_GE_GENERIC: {
>>             if (isXIType(event, m_xiOpCode, XI_Motion))
>>                 std::cout << "XI_Motion" << std::endl;
>>             break;
>>         }
>>         default:
>>             break;
>>         }
>>     }
>>     return false;
>> }
>>
>> I've been able to determine that the XCB_GE_GENERIC events I'm getting
>> are actually XI_Motion events from the XInput2 extension: The above
>> prints:
>>
>> XI_Motion
>> XI_Motion
>> ...
>>
>> when I move the mouse.
>>
>> But I'm not seeing the symptom described in that bugfix commit
>> message, which says:
>>
>> "The current version of the mouse motion event compression
>> algorithm does not work with certain configurations -
>> situations where we get one XCB_GE_GENERIC event between
>> every XCB_MOTION_NOTIFY event."
>>
>> So I'm now unsure if this is really the bug I'm seeing, or if
>> something else is causing event compression to fail.
>>
>> If I'm going to compress events on my own, wouldn't I need to maintain
>> my own event queue like Qt does? Or is there an API to inspect the Qt
>> event queue?
>
> In fact, I don't think this is really possible on the application
> side. At least not in a satisfactory way. Because doesn't Qt poll XCB
> for events, possibly taking in a whole bunch of them at once into its
> queue, and then decides what to deliver and what to discard? I don't
> see how I could do something similar at the app level, where I'm not
> in charge of the XCB connection so to speak.
>
> I'd love to hear if anyone thinks what I'm seeing is really the bug fixed by
>
>     https://codereview.qt-project.org/#/c/126136/
>
> or if it's something else.
>
> To me it looks like it might be something else, since I'm not
> receiving any XCB_MOTION_NOTIFY at all, only XI_Motion (are those
> supposed to be compressed in 5.5.1?).

In the meantime, I think I've found a way to work around the bug in
the framework I'm using (VTK) together with Qt. There was a way to
make it not issue a render in its GL window in response to every mouse
move, and instead direct it through a call to update() on the QWidget
in which I had the GL window.

So I think I'll use that workaround instead of trying to work around
it using event filtering.

Thanks for the input anyway!

Elvis

>
> Elvis
>
>>
>> Elvis
>>
>>>
>>> --
>>> Thiago Macieira - thiago.macieira (AT) intel.com
>>>   Software Architect - Intel Open Source Technology Center
>>>
>>> _______________________________________________
>>> Interest mailing list
>>> Interest at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest