Dimitri Frederickx wrote:
> I'm having a nasty question, and I don't know how to solve the problem.
> 
> I have created a graphics view, in which I want to display graphical
> items, movies, SVG items, etc.
> Then I also have a scheduled, that is going to show and hide certain
> graphical items on the graphics view.
> 
> No my question: what is the best way to do this?
> 1. I have created a QTimer, and when the time expires, a signal is
> emitted and my method is executed. But it seems that the code behind
> it is executed in the same thread as my main method. This means that
> the current animation in my graphics view shows glitches sometimes,
> and the animation happens not fluent. Is it correct that it is
> executed in the same thread?

This is correct, QTimer is based on posting an event to the current 
threads event loop that will cause one or more timerEvent()'s to occur 
later on in this same thread. In the case of the timeout signal, this is 
invoked from the QTimers timerEvent(). When you create a timer in the 
GUI thread, the signal will be emitted from the GUI thread. QTimer's are 
extremely light-weight compared to a Thread, as it doesn't require 
context switches and local stack and all that stuff. For animations in a 
graphics view, I would recommend one or more "heartbeat" timers that all 
animations respond to.

In regards to animation you also have the problem that GC will kick in 
every once in a while and collect objects which will freeze any 
animation. The GC freeze is anything from a few milliseconds to several 
hundred milliseconds. You can reduce this by avoiding temporary objects. 
Specially in QGraphicsItems paint functions you should avoid allocations 
and instead allocate datastructures in the items constructor and reuse 
paths / polygons / rects / pens / brushes in the paint() function.

Another aspect of animation is the perceived motion. If you move 10 
pixels pr timeout() and there is a delay in timeouts this will be very 
visible because the motion is not time based, but timeout-tick based. If 
  you let the speed of items in the animation be a function of the time 
you can make animations appear a lot smoother. E.g. you check 
System.currentTimeMillis() (although this is extremely coarse) and say 
that the item moves 1 pixel per millisecond. If there is 50 milliseconds 
between timeouts it moves 50 pixels, if it there is a GC and 150 
milliseconds delay it moves 150. You will skip frames but the speed of 
the animation is not affected.

> 2. Then I was thinking that I could maybe execute my code in another
> thread. But how do I make the code execute in another thread? Is there
> an easy way to do this, or do I have to attach my method to the
> signal, and then create my own thread in my method? Or is there a way
> to force that the method executed by the signal is always in a new
> thread?

You could use a Thread, but I doubt that this will make things better. 
Quite the opposite, I think it will make it worse, but try it out if 
you're curious, I might be wrong.

If you want a signal / slot connection across threads, you should use 
the connect(recv, "slot()", Qt.ConnectionType.QueuedConnection) version 
of connect which will do an asynchronous call from the emit(). What 
happens here is that the emit call will be posted as an event to the 
eventloop of the receiver thread. This means you have no guarantee for 
the delivery time of the emit() on the receiver side, and you are no 
better off than doing a timer.

Also, please note that queued connections are only available when the 
receiver is a QObject.

best regards,
Gunnar
_______________________________________________
Qt-jambi-interest mailing list
[email protected]
http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest

Reply via email to