QEventLoop - unique event?
-
Hi,
What kind of event do you have in mind ?
-
@SGaist said in QEventLoop - unique event?:
Hi,
What kind of event do you have in mind ?
I'm lost...?
I just send a lot of event to the eventLoop, they get executed and update gui as they should, however at some point they just stop app from working while they process/update gui. I have no need for it, as all I need is last event of given type to be executed.
Say moving an object in 3d space. You would push update every value change while mouse drag, but when user release button, you don't care about any mid-position of object except for last one. So we would discard the 6000 move events and only execute last one.
-
@SGaist said in QEventLoop - unique event?:
Hi,
What kind of event do you have in mind ?
I'm lost...?
I just send a lot of event to the eventLoop, they get executed and update gui as they should, however at some point they just stop app from working while they process/update gui. I have no need for it, as all I need is last event of given type to be executed.
Say moving an object in 3d space. You would push update every value change while mouse drag, but when user release button, you don't care about any mid-position of object except for last one. So we would discard the 6000 move events and only execute last one.
This is called event compression, and no, there's no ad hoc process to handle that for you. You must process the events yourself (e.g. process everything pending as it comes, and repost an update event that you always respond to).
-
This is called event compression, and no, there's no ad hoc process to handle that for you. You must process the events yourself (e.g. process everything pending as it comes, and repost an update event that you always respond to).
@kshegunov Hey. sweet thanks for the name info, I'll google that compression thini! But if I'm using QEventLoop, then how can I access the event queue/etc etc to be able to determine what to process and what to remove? Or do I need to write my own process worker from ground up ?
-
AFAIK, it's not something that is currently publicly accessible.
See QTBUG-19711
-
I think if you're filling up the event queue with superfluous events then that's a clear sign of a poor design, and you need to reconsider your overall architecture. Trying to deal with the events already in the pipe is an ugly hack. Stop them at the source!
-
I think if you're filling up the event queue with superfluous events then that's a clear sign of a poor design, and you need to reconsider your overall architecture. Trying to deal with the events already in the pipe is an ugly hack. Stop them at the source!
Hai
@SGaist I would love to get my hand on to it somehow. Qt event loop has been quite awesome for my app so far to do background processing/etc/etc. But not being able to have a way to discard obsolete events its a bit of a bummer. How does qt do it internally? I mean does it discard lots and lots of setText() on the same widget so that it does not set a million texts but just last one ?
@Kent-Dorfman well I have no idea how to solve it now... so not sure how to bite it. Essentially I'm moving geometry in viewport and processing all the transforms. As far as I can tell a mouse move can generate 1000 events. Given the multithreaded approach and internal logic, if the user release mouse and queue is at event 200, the object will be already updated in correct position. Since the matrices are being calculated in another thread and are valid (its a miracle I don't have threading crashes ) Hmmm I think I'll try to somehow detect if the transform is finish and cut the calculation short with bool and let events run. Might help if there is no math to solve...
-
One approach is to start a timer which then triggers the update and only restart it once it fired.
-
Unless you are doing multithreading or forcing the connection type to queued. There's no event involved in signals and slots. To avoid a signal storm, the first thing you do is check if the value you are setting is different than the one your currently have and if not you stop there.
-
Hai
@SGaist I would love to get my hand on to it somehow. Qt event loop has been quite awesome for my app so far to do background processing/etc/etc. But not being able to have a way to discard obsolete events its a bit of a bummer. How does qt do it internally? I mean does it discard lots and lots of setText() on the same widget so that it does not set a million texts but just last one ?
@Kent-Dorfman well I have no idea how to solve it now... so not sure how to bite it. Essentially I'm moving geometry in viewport and processing all the transforms. As far as I can tell a mouse move can generate 1000 events. Given the multithreaded approach and internal logic, if the user release mouse and queue is at event 200, the object will be already updated in correct position. Since the matrices are being calculated in another thread and are valid (its a miracle I don't have threading crashes ) Hmmm I think I'll try to somehow detect if the transform is finish and cut the calculation short with bool and let events run. Might help if there is no math to solve...
@Dariusz said in QEventLoop - unique event?:
well I have no idea how to solve it now...
You said this is some kind of cumulative transformation you're doing, right? What about keeping only the info about the transform instead of actually doing it. Then on the update event you can calculate the accumulated result. Say you're moving a thing in space, you can keep the offset from the original position, you don't need to actually do to the move yet, just sum up the vectors. Finally construct the transformation matrix and apply. The same thing could be done for rotations, skews etc.
The only thing that you need to be careful about, however, is that affine transforms aren't commutative. If you have move and then rotate, you can't invert the order to rotate and then move. Either way you can process the similar transformations in batches based on similarity.PS. I went on a limb here, as I have no clue what you're doing exactly. If you provide more info, we may end up suggesting something better.
