Bug 1703

I confirm. This is related to bug 1583. I haven't added that bug report to the R14 etherpad check list, but there are days I'm tempted to do just that. I've been frustrated with krdc the past many months. I use krdc often.

(Odpověď na komentář #1)
> I confirm. This is related to bug 1583. I haven't added that bug report to the
> R14 etherpad check list, but there are days I'm tempted to do just that. I've
> been frustrated with krdc the past many months. I use krdc often.

Also for me is krdc very frequently used tool.
Therefore, this bug is also important to me.

Okay, I added both reports to the R14 etherpad check list.

Slavek, with respect to this bug report and to bug 1583, do you see the same problems with 3.5.13.2?

I ask because although I have been using pre R14 on my main system for a very long time, early in my R14 usage, often I connected to my HTPC, which way back then was using KDE 3.5.10. I remember crisp and responsive sessions.

Seems everything now is sluggish.

If sessions are responsive in 3.5.13.2, then perhaps the problem in R14 is some kind of Q->TQ error?

On 3.5.13.2 problem does not occur.
Changes on the remote machine is in krdc renewed continuously.

Have you noticed problems already before it was integrated into TQt3 glib event loop?

Could be a threading wake problem.  For me, even KDE 3.5.12 is difficult to use via krdc (I still have older machines with various KDE/TDE versions on them), so this problem may have existed for some time.

(In reply to comment #5)
> On 3.5.13.2 problem does not occur.
> Changes on the remote machine is in krdc renewed continuously.
> 
> Have you noticed problems already before it was integrated into TQt3 glib event
> loop?

Good point.  This could easily be a glib event loop issue--try compiling TQt3 without glib event loop support to see if that fixes the issue.

You raised the same threading/glib concern in bug 1172.

Do all packages need to be rebuilt of just TQt3?

>Do all packages need to be rebuilt of just TQt3?
Should be:
Do all packages need to be rebuilt or just TQt3?

(In reply to comment #9)
> >Do all packages need to be rebuilt of just TQt3?
> Should be:
> Do all packages need to be rebuilt or just TQt3?

Just TQt3.  I do remember weird menu behaviour in TDM right after the event loop switch, so a similar fix may need to be applied to krdc.

> I do remember weird menu behaviour in TDM right after the event
> loop switch, so a similar fix may need to be applied to krdc.
That was bug 1484 and commit c69c3400 from 2013-05-01?

I'll rebuild and report.

According to my backups, I started using -glibmainloop about May 20. Do you recall discussions last spring that might have prompted me to build TQt3 with -glibmainloop? Was -glibmainloop ever considred stable?

I tried tqt3 without glib event loop and did not helped.

Which is preferred, -glibmainloop or tqt3 internal main event loop?

For me, compiling without -glibmainloop resulted in a nominal improvement in sluggishness. After rebuilding TQt3 I updated two systems. I then watched the two systems side by side. There is still a delay between screen display updates, but not as bad as before.

I notice some significant improvements related to bug 1583, which I'll post there.

(In reply to comment #13)
> Which is preferred, -glibmainloop or tqt3 internal main event loop?

-glibmainloop

Okay, so we have to fix the associated problems when using -glibmainloop?

I posted observable improvements when not using -glibmainloop in bug 1532 and bug 1583.

(In reply to comment #16)
> Okay, so we have to fix the associated problems when using -glibmainloop?

Yes we do.

Okay. I'm going to build a full package set overnight without -glibmainloop in TQt3. I'm curious to see whether any other bugs I've reported disappear. But when we're ready to test associated patches I'll rebuild with -glibmainloop.

(Odpověď na komentář #10)
> (In reply to comment #9)
> > >Do all packages need to be rebuilt of just TQt3?
> > Should be:
> > Do all packages need to be rebuilt or just TQt3?
> 
> Just TQt3.

Today I tested a second time - on the other machine. Rebuild only TQt3 (without -glibmainloop), the rest of the packages are from the nightly-builds.

Sloppy rendering without any visible changes.

I tested three computers with krdc and krfb. The desktops are 3.5.10, 3.5.13.0, R14 with glib main loop and R14 with tqt3 main loop. I am unable to test 3.5.10 vs. 3.5.13.0 (same machine, multi-boot).

The results varied with no repeatable consistency.

Most combinations were sluggish. I saw very fast responses when the krdc system was 3.5.10 or 3.5.13.0, and the krfb system was R14 glib main loop.

(In reply to comment #20)
> I tested three computers with krdc and krfb. The desktops are 3.5.10, 3.5.13.0,
> R14 with glib main loop and R14 with tqt3 main loop. I am unable to test 3.5.10
> vs. 3.5.13.0 (same machine, multi-boot).
> 
> The results varied with no repeatable consistency.
> 
> Most combinations were sluggish. I saw very fast responses when the krdc system
> was 3.5.10 or 3.5.13.0, and the krfb system was R14 glib main loop.

This would seem to isolate krdc as the problem.

Tim

(Odpověď na komentář #21)
> (In reply to comment #20)
> > I tested three computers with krdc and krfb. The desktops are 3.5.10, 3.5.13.0,
> > R14 with glib main loop and R14 with tqt3 main loop. I am unable to test 3.5.10
> > vs. 3.5.13.0 (same machine, multi-boot).
> > 
> > The results varied with no repeatable consistency.
> > 
> > Most combinations were sluggish. I saw very fast responses when the krdc system
> > was 3.5.10 or 3.5.13.0, and the krfb system was R14 glib main loop.
> 
> This would seem to isolate krdc as the problem.
> 
> Tim

My observations are easier. Clients are krdc - TDE 3.5.13.2 and krdc - TDE R14. Servers are different, but constant - VNC console for KVM virtual machine, TightVNC on Windows.

Krdc in TDE 3.5.13.2 is always brisk
Krdc in TDE R14 is always sluggish

For me it thus clearly points to krdc problem.

Noticeable improvements with the patch from commit 8dd4535 (bug 1583)!

There still seems to be a lag between when an event occurs in the remote krfb screen and the local krdc screen updating. Often I have to move my mouse pointer before the krdc screen updates. For example, when I click the Quit/Close button in the title bar often I have to move the pointer before the krdc screen updates.

I'm testing with the two machines next to one another and can see both screens. I'm tested between two R14 systems both with TQt3 built without glibmainloop. I'm rebuilding TQt3 with glibmainloop to test further.

Machines updated with TQt3/glibmainloop. Overall everything responds much better. Snappier. Still some lag at the krdc screen updating compared to the krfb screen. I'll await opinions/observations from others.

Bottom line, is krdc/krfb no longer should be a blocker to releasing R14.0.0.

This should be fixed in GIT hashes 56999a2 (qt3) and eeaba43 (tqt3).  Please test and verify.

Great, works well.
This bug message can be closed.

Sessions are very responsive now. The Authenticating dialog disappears almost immeidately. Good job!