PDA

View Full Version : QTimeWaster



qtoptus
26th December 2011, 21:02
Does setting the QTimer interval to 0 help anyhow? I've been struggling with creating an idle event for a rendering loop and everytime I got a different problem. 4.8 fixed one problem I had before but now I'm facing another. Whenever I add my graphics window custom control to the form, the timer is no more triggered until I either resize or move the window. Should I go back to MFC and leave open-source buggy libraries? Come on, gimme a break!!!

ChrisW67
26th December 2011, 21:53
Does setting the QTimer interval to 0 help anyhow?
Yes, the QTimer fires immediately when the program returns to the Qt event loop. Any slot attached to the timeout() signal gets run at that time.

I've been struggling with creating an idle event for a rendering loop and everytime I got a different problem. 4.8 fixed one problem I had before but now I'm facing another. Whenever I add my graphics window custom control to the form, the timer is no more triggered until I either resize or move the window.
How about trying to help yourself. Sounds like your "rendering loop" is doing things the wrong way. We cannot guess the creative way you have achieved this effect with absolutely no information from you.

Should I go back to MFC and leave open-source buggy libraries?
Yes... especially if all you are going to do is complain that a perfectly good programming framework does not meet your needs.

Come on, gimme a break!!!
http://www.bbc.co.uk/cbbc/shows/gimme-a-break

qtoptus
27th December 2011, 16:13
I cannot understand why sometimes it's taken personal...anyway


Sounds like your "rendering loop" is doing things the wrong way

How? Example?


Yes, the QTimer fires immediately when the program returns to the Qt event loop. Any slot attached to the timeout() signal gets run at that time.

Not always, not perfectly.


We cannot guess the creative way you have achieved this effect with absolutely no information from you.

It sounds like Qt requires achieving stuff in a "creative" way in order to work.


http://www.bbc.co.uk/cbbc/shows/gimme-a-break

Cute!

amleto
27th December 2011, 16:44
qtimer works without needing to resize/move a window, so it suggests there is something wrong with your control that keeps the event queue from emptying - qtimer (0) fires when the event queue is empty.

you have not provided any code at all.

you only asked two questions in your op -

does setting timer to 0 help?
should you go back to mfc?

How do you expect us to answer with the information you have provided?

ChrisW67
28th December 2011, 01:11
I cannot understand why sometimes it's taken personal...anyway
I wasn't taking anything personally. I was merely pointing out that the best way to get an answer to a question about doing X with Y is to provide some information about what X is, how you are trying to do X, what you expected to happen, what actually happens, and why you think that Y is at fault. X and Y apply to your problem and Qt just the same as they would to your problem and MFC, .Net, or Lisp. Simply stating that Y is broken and threatening to take your bat and ball and go home is not going to get you anywhere.



Sounds like your "rendering loop" is doing things the wrong way
How? Example?
There are many more ways to do something wrong or sub-optimally than I have had dinners. Amleto has one general mechanism by which your code can break things. How are we supposed to know how you are doing anything? You have yet to tell us anything about your code, your "rendering loop", and how you are achieving the unusual effects you describe... only that you think it is Qt's fault. Yes, they are unusual behaviours coming from your program, but only you seem to have them. They are a huge number of people, myself included, who have had no issues with zero QTimers. When we can see what you are doing then we could possibly tell you how to do it better.



Yes, the QTimer fires immediately when the program returns to the Qt event loop. Any slot attached to the timeout() signal gets run at that time.
Not always, not perfectly.

Prove it. Provide an example of how it doesn't work [docs=QTimer.html#details]as documented[/qtimer].


It sounds like Qt requires achieving stuff in a "creative" way in order to work.

Programming in general has a creative element. Qt requires you to use Qt in the way it designed to be used. This is absolutely no different to MFC, .Net or any other programming tool or framework.

amleto
28th December 2011, 12:37
Chris, it's in the docs that qtimer will silently discard timeout events/signals in some circumstances. I don't know if that is what the op was referring to or not.

qtoptus
28th December 2011, 15:53
Sometimes frustration of a problem puts the blame on the framework...

After investigating the problem, I could find that adding a graphics widgets has nothing to do with the timer not being triggered. It only happens when making the widget a Direct3D capable window.
I pass the window handle of the widget to Direct3D stuff which resides in a DLL.

qtoptus
29th December 2011, 18:01
Another finding, if it's an OpenGL window then it works fine. All I'm doing is a simple form using VS plugin and QtDesigner, add a class derived from widget to the form, and inside the form I have the QTimer. This timer also calls boost::chrono timer functions.

qtoptus
30th December 2011, 05:31
Ok now problem solved when setting the timer anything but 0. Setting it to 1 works fine...weird...

amleto
30th December 2011, 13:06
Ok now problem solved when setting the timer anything but 0. Setting it to 1 works fine...weird...
there is a fundamental difference in behaviour of qtimer when the timeout is changed from 0 to 1. Just because it works, doesn't mean the original problem now gone.

wysota
1st January 2012, 20:23
It would really help if you shared some of your code. A good guess would be some routines in the d3d dll are screwing up something in regard to what Qt expects.