December 27, 2010

Flo Flo
Lab Rat
12 posts

[Moved] Timer used to repaint (advance) delayed by event flood processing

Page  
1

I have a scene with a ball and a bat. The ball is advance using a timer (frequency about 30 / sec). The bat is moved using the mouse events (or touch events).
The problem is that when I move the bat continuously, the ball is slowing down (stopping in between).

I printed out some traces and the issue seems to be related to the fact that the timer is not triggered because of the mouse (touch) events flood. In the worst cases the timer is called once or twice a second.

  1. const int TimerFreq = 1000/33;
  2. QTimer timer;
  3. QObject::connect(&timer, SIGNAL(timeout()), &scene, SLOT(advance()));
  4. timer.start(TimerFreq);

How can I rework this in order to get the ball moving smoothly, not depending on the mouse/touch events.

45 replies

December 27, 2010

Denis Kormalev Denis Kormalev
Lab Rat
1654 posts

You can move your ball work to another thread with its own event loop.

December 27, 2010

Milot Shala Milot Shala
Lab Rat
396 posts

As Denis suggested QThread [doc.qt.nokia.com] is the best place to start.

December 27, 2010

peppe peppe
Ant Farmer
1029 posts

How many events are we talking about? Which device is it, that is generating so many events (and they’re not somehow filtered)? Which platform?

You can move your ball work to another thread with its own event loop.

Nonsense. QGraphics* classes are not reentrant, thus they’re usable only from the main thread, whose event loop seems to be flooded by touch events.

 Signature 

Software Engineer
KDAB (UK) Ltd., a KDAB Group company

December 27, 2010

Denis Kormalev Denis Kormalev
Lab Rat
1654 posts

peppe, who is saying about moving QGraphics* to another thread? We can move all calculations of new ball position to another thread and left only painting at main thread. So calculations will be made every 1/30 sec and will be painted asap.

December 27, 2010

peppe peppe
Ant Farmer
1029 posts

They won’t be painted because painting requires the MAIN EVENT LOOP to be running.

 Signature 

Software Engineer
KDAB (UK) Ltd., a KDAB Group company

December 27, 2010

Denis Kormalev Denis Kormalev
Lab Rat
1654 posts

peppe, I think if all work about ball and about bat moving will be moved away from main thread (i.e. we will have only painting and catching events, all calculations will be done in background) then it will help.

December 27, 2010

peppe peppe
Ant Farmer
1029 posts

How can it help if the main thread’s event loop is flooded by those mouse/touch events? Even supposing that you can pick the data from the main thread, do your math in 1 millionth of a second, and schedule an update() for your item, the QPaintEvent for the QGV will be sitting in the main thread’s event queue and will actually be delivered after 1-2s (according to OP).

 Signature 

Software Engineer
KDAB (UK) Ltd., a KDAB Group company

December 27, 2010

Denis Kormalev Denis Kormalev
Lab Rat
1654 posts

peppe, according to OP timer events are invoked once in 1-2 seconds.

December 27, 2010

Volker Volker
Ant Farmer
5428 posts

Main thread does all the GUI stuff.

“background” thread does all the ball calculations and sends a signal to the main thread which in turn does the graphics update.

December 27, 2010

peppe peppe
Ant Farmer
1029 posts
Denis Kormalev wrote:
peppe, according to OP timer events are invoked once in 1-2 seconds.

Instead of the desidered 30 updates per second.

“background” thread does all the ball calculations and sends a signal to the main thread which in turn does the graphics update.

Again, HOW does the main thread update the view if the main event loop is flooded by input events?

 Signature 

Software Engineer
KDAB (UK) Ltd., a KDAB Group company

December 27, 2010

Denis Kormalev Denis Kormalev
Lab Rat
1654 posts

Volker, exactly what I am saying :) Also I think not only ball, but bat calculations can be moved to background thread too.

December 27, 2010

Volker Volker
Ant Farmer
5428 posts

I did not say, it solves the problem. I did say, it is possible to do it this way without violating the gui-update-only-in-main-thread rule.

December 27, 2010

Flo Flo
Lab Rat
12 posts

Volker wrote:
Main thread does all the GUI stuff.

“background” thread does all the ball calculations and sends a signal to the main thread which in turn does the graphics update.

Calculating the next ball position is just x=x+1. The problem is that the timer’s timeout() is not triggered as expected (30 times a second), because the main thread is busy handling the mouse/touch events.

December 27, 2010

Denis Kormalev Denis Kormalev
Lab Rat
1654 posts

peppe, at least OP can try it and maybe it will solve the problem.

December 27, 2010

peppe peppe
Ant Farmer
1029 posts

Wtf? Is this some kind of SERIOUS help or just “try this random thing”?

 Signature 

Software Engineer
KDAB (UK) Ltd., a KDAB Group company

Page  
1

  ‹‹ QtWebKit issue (tried with Sencha Touch)      (SOLVED)WINCE Shadow build: how to verify if it is correct? ››

You must log in to post a reply. Not a member yet? Register here!