[mythtv] [mythtv-commits] Ticket #1381: Slow keyboard response over
mythtv at zacglen.com.au
mythtv at zacglen.com.au
Sun Feb 26 04:50:29 UTC 2006
>> >> >We might be waiting for a while. There's no such select() (or similar
>> >> > stuff)
>> >> >
>> >> >in the code that could be causing that. =)
>> >>
>> >> Yes, there is.
>> >> Try an strace and find out the *truth*.
>> >>
>> >> Anyone who has done any programming (like myself) will know
>> >> that QEventLoop()::exec invokes select().
>> >
>> >I didn't realize that I had to specifically put "in mythtv" in that
>> > sentenc e,
>> >
>> >since this is the mythtv mailing list & bug tracker and not the Qt one.
>> >
>> >Silly me.
>> >
>> >> This is probably a major top-level design error.
>> >
>> >That only happens to a few people? That's highly doubtful.
>>
>> Really? So top level design flaws always immediate manifest themselves
>> and are instantly corrected?
>
>A 'major top-level design error' would generally be happening to more than
>2
>
>people. You're 0 for 3 so far in coming up with ideas as to this 'major
>
>design' issue.
>
>> Anyhow, for all those doubters out there, here are some stack traces.
>>
>> A)
>> #0 0x05449490 in select () from /lib/libc.so.6
>> #1 0x07173b68 in QEventLoop::processEvents () from
>> /usr/lib/qt-3.3/lib/libqt-mt.so.3 #2 0x071e222b in QEventLoop::enterLoop
>> () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #3 0x071c94cf in
>> QApplication::enter_loop () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #4
>
>> 0x045a750d in MythDialog::exec () from /usr/lib/libmyth-0.19.so.0 #5
>
>> 0x0806497d in RunMenu (themedir=@0xbfd2b100) at main.cpp:498
>> #6 0x0806c93a in main (argc=1, argv=0xbfd2b1b4) at main.cpp:1062
>
>Wow, look at that, a select() in Qt. How's that mean it's a 'major top-lev
>el
>
>design error' in mythtv, again? I'm confused, please explain. Remember, y
>ou
>
>said:
>
>"But isn't is quite possible that there is some flakey code which is causin
>g
>
>keystroke events to only be processed after the select() times out?"
>
>To which the answer was, and still is: 'no, it's not possible, since no suc
>h
>
>code exists in mythtv.' This doesn't mean that 'there are no selects() use
>d
>
>anywhere, ever, when running mythtv'. That would just be stupid, and
>
>interpreting that statement like that, which you've apparently chosen to do
>,
>
>is even sillier.
>
>Yes, Qt uses a select() to know when to wake up and process events. This h
>as
>
>absolutely nothing to do with the code, or the design of code, in myth
>
>itself. If you believe there is a bug in that part of Qt, which is _ever_
>so
>
>slightly doubtful, take it up with Trolltech, not us.
Ok, so in your view everything is _ever_ so slightly doubtful.
In your world there is no bug in MythTV, and none in Qt either.
I am very happy for you.
>
>> B)
>>
>> > #0 0x05449490 in select () from /lib/libc.so.6
>> > #1 0x07450f48 in QSocketDevice::waitForMore () from
>> > /usr/lib/qt-3.3/lib/libqt-mt.so.3 #2 0x0478db0d in SipFsm::CheckRxEvent
>> > () from /usr/lib/mythtv/plugins/libmythphone.so #3 0x047911e2 in
>> > SipThread::CheckNetworkEvents () from
>> > /usr/lib/mythtv/plugins/libmythphone.so #4 0x04792b27 in
>> > SipThread::SipThreadWorker () from
>> > /usr/lib/mythtv/plugins/libmythphone.so #5 0x04792fbb in SipThread::run
>> > () from /usr/lib/mythtv/plugins/libmythphone.so #6 0x071c2378 in
>> > QThreadInstance::start () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #7
>
>> > 0x00373947 in start_thread () from /lib/libpthread.so.0
>> > #8 0x054502ce in clone () from /lib/libc.so.6
>
>Wow, another select(), but lookithat, it's in a separate thread that has
>
>nothing to do with input processing. Crazy, that.
Here you go again! "Nothing to do with input processing".
Everything that runs on same CPU can affect input processing!
Try running:
dd if=/dev/zero of=/file1 &
dd if=/dev/zero of=/video/file2 &
Then check your keystroke response time.
But I am very pleased that I have wowed you and sent you crazy.
>
>Might as well point out the joystick code's select() too, but <gasp> that's
>
>also happening in a separate thread and won't impact keypress processing at
>
>all, either.
Rubbish.
Just because something is running in another thread doesn't insulate
it from affecting any other thread.
Anybody who has written a program would know that.
It depends entirely on what your stupid threads are up to - and
what other threads they might be blocking.
I cannot believe how ignorant some so-called developers can be!
>
>> Goodness knows what the 'mythphone' stuff is trying to do - call home
>> I suppose. I have it disabled so why doesn't it just close itself and die?
>
>You don't have it disabled, since it's obviously running and installed.
>
>Remove the plugin to disable it. I never got around to making a way to
>
>disable a plugin aside from not installing it.
It is already disabled.
>
>> Anyhow I figure that there might be excessive traffic from creating
>> new pixmaps when a menu selection highlighting needs to change.
>> But shouldn't they already exist as offscreen pixmaps?
>> That would certainly be much more efficient, not to mention faster.
>
>All the pixmaps for the menus are loaded + scaled when the menu xml files a
>re
>
>parsed at the start of the program, or when the user changes something in t
>he
>
>appearance settings. All it does when the current selection changes is dra
>w
>
>different stuff (which, incidentally, can be fairly slow depending on your
>
>chosen resolution, what theme you're using, and if your X server has limite
>d
>
>amounts of accel for blending pixmaps). It only redraws the section of the
>
>screen that's needed, as well. You might want to try actually looking at t
>he
>
>source to see what it's doing. It's not like profiling stuff like this is
>
>difficult.
>
I have decided to drop MythTv because it seems to be essentially reinventing
the wheel. Besides a scheduler which knows how to assign non-overlapping
events to hardware, all interfacing can just as easily be done
via a browser.
And the advantages a browser has are:
a) They already exist and are well tested and relatively bug-free.
b) A remote client can do big fonts with minimum of HTML coding.
c) It kills two birds with one stone - true media convergence (non-myth).
d) I am sure there are plenty more reasons.
Besides, I can also arrange for the recorded files to be in whatever
format I wish, with/without any processing of my choosing.
Additionally I can totally avoid a database and use a simple filesystem
based scheme. I have already drawn on up on the back of an envelope.
I prefer configurations to be in plain files anyhow.
Have a nice development experience.
Bye.
More information about the mythtv-dev
mailing list