hi,
i am developing an application that uses a 3D mouse for navigation. It is written in C++, linux x64 on fedora core 8, Qt 4.3.4
in some situations, the openGL renderer is slower than the the 3D mouse sending events. Resulting in a long history of 3D mouse movements even when you have released the button. Since you can have only one thread sending commands to X, threading is not an option. Is there a way to perhaps change the frequency of X events ? Or ( better ) perhaps not queue unprocessed events, but just store the last X event ?
Using QCoreApplication::removePostedEvents( this, 0 ); does not seem to help...
Any suggestions ?
Cheers
Frequency of Xevents in Qt
Moderator: Moderators
Hi stage,
there is an undocumented/hidden command line option in 3dxwareunix:
"-slowUSB <n>", where <n> is the amount of motion events that should be dropped (valid values: 0...20). Example n=1: one event dropped, one event used.
But this is surely not what you want, because it makes the device and your application feel slow and kind of imprecise.
My suggestion would be - although you say its not an option - to have two threads:
Thread 1 handles the X part, which would be the connection/receiving window to 3dxwareunix. This thread consumes all events, stores the last motion event received and queues button events (otherwise you'll lose button presses).
Thread 2 draws the OpenGL object and reads the events from the thread 1 when its finished drawing.
If button events are present at thread 1 those will get priority over motion events. Of course you can add some time stamp info to this events and process them chronological. If a button event is read, it has to be cleared from the button event queue of thread 1.
Hope I could help - somehow.
If you still have questions, feel free to ask!
Regards,
Christian Robl
3Dconnexion
there is an undocumented/hidden command line option in 3dxwareunix:
"-slowUSB <n>", where <n> is the amount of motion events that should be dropped (valid values: 0...20). Example n=1: one event dropped, one event used.
But this is surely not what you want, because it makes the device and your application feel slow and kind of imprecise.
My suggestion would be - although you say its not an option - to have two threads:
Thread 1 handles the X part, which would be the connection/receiving window to 3dxwareunix. This thread consumes all events, stores the last motion event received and queues button events (otherwise you'll lose button presses).
Thread 2 draws the OpenGL object and reads the events from the thread 1 when its finished drawing.
If button events are present at thread 1 those will get priority over motion events. Of course you can add some time stamp info to this events and process them chronological. If a button event is read, it has to be cleared from the button event queue of thread 1.
Hope I could help - somehow.
If you still have questions, feel free to ask!
Regards,
Christian Robl
3Dconnexion
