[mythtv] [mythtv-commits] Ticket #1381: Slow keyboard response over

[Isaac Richards]

On Saturday 25 February 2006 22:48, mythtv at zacglen.com.au wrote:
> >> >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-level 
design error' in mythtv, again?  I'm confused, please explain.  Remember, you 
said:

"But isn't is quite possible that there is some flakey code which is causing 
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 such 
code exists in mythtv.'  This doesn't mean that 'there are no selects() used 
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 has 
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.

> 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.

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.

> 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.

> 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 are 
parsed at the start of the program, or when the user changes something in the 
appearance settings.  All it does when the current selection changes is draw 
different stuff (which, incidentally, can be fairly slow depending on your 
chosen resolution, what theme you're using, and if your X server has limited 
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 the 
source to see what it's doing.  It's not like profiling stuff like this is 
difficult.

Isaac