[Moved] Timer used to repaint (advance) delayed by event flood processing
-
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.
-
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.
-
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).
-
peppe, according to OP timer events are invoked once in 1-2 seconds.
-
[quote author="Denis Kormalev" date="1293486729"]peppe, according to OP timer events are invoked once in 1-2 seconds.[/quote]
Instead of the desidered 30 updates per second.
[quote]“background” thread does all the ball calculations and sends a signal to the main thread which in turn does the graphics update.[/quote]
Again, HOW does the main thread update the view if the main event loop is flooded by input events?
-
Volker, exactly what I am saying :) Also I think not only ball, but bat calculations can be moved to background thread too.
-
[quote author="Volker" date="1293486907"]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.
[/quote]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.
-
peppe, at least OP can try it and maybe it will solve the problem.
-
peppe, forum is "try this thing" at 85% of questions.
dflorin, try to count how often paintEvent is invoked. If it invoked in good frequency then using background thread will help. -
peppe, I don't know forum where you can ask any question you have stucked with and receive answer correctly and quickly. And this discussion is offtopic. If you have something to add about subj of topic then add.
-
Back to the subject. I made some measurements:
When not moving the bat:
- Bat::paint() called 30 times (how many times the bat is repainted as a result of setPos() called from the event() method)
- Ball::advance() called 30 times (this is called by the timer and should be 30 calls instead) - this will trigger paint()
NOTE: the Bat is also repainted because I use:
view.setViewportUpdateMode(QGraphicsView::FullViewportUpdate);
This should not have any impact on my problem.When moving the bat as fast as I can using touch events:
- Scene::event() called 47 times (this is how fast I move the bat by touching the screen)
- Bat::paint() called 50 times (how many times the bat is repainted as a result of setPos() called from the event() method and as a result of paint() done for the ball)
- Ball::advance() called 13 times (this is called by the timer and should be 30 calls instead) - this is my problem: the ball has slowed down at less than half speed.
And one more thing: this is noticeable on a Symbian device. Running it in the simulator on Windows and using mouse events instead of touch events does not slow down the ball. Should the post be moved to Mobile and Embedded?
-
dflorin, looking at this measurement I think it is worth to try moving ball coordinates calculation into another thread.
-
[quote author="Denis Kormalev" date="1293490361"]dflorin, looking at this measurement I think it is worth to try moving ball coordinates calculation into another thread.[/quote]
Even if the advance() only does x=x+1?
Please note my comment related to reproducibility on Symbian only.
-
dflorin, problem is not in calculation complexity, problem is in a big count of mouse and paint events which don't allow your timer to work in needed frequency.