Bug 88985

Summary:	Screen preview makes life difficult over slow link
Product:	[Retired] Red Hat Linux	Reporter:	Jason Tibbitts <j>
Component:	redhat-config-xfree86	Assignee:	Brent Fox <bfox>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	low
Version:	9	CC:	mharris, mitr
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-05-27 21:55:41 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jason Tibbitts 2003-04-16 00:09:31 UTC

Description of problem:
Occasionally I need to run redhat-config-xfree86 over a relatively slow link to
a remote site.  I don't always know what monitor is attached or what calls are
installed so the command-line options don't really help (since I don't know what
to pass to --set-resolution etc.).

While this does work, it takes a very long time to start up.  It seems the
bottleneck is sending a complete snapshot of the local display over the link for
the desktop preview.  This actually locks the local server while it's taking the
snapshot, which means that the local machine is essentially unusuable for
several minutes.  The UI runs at acceptable speed once everything's going.

Would it be possible to have an option that skips the screen preview and just
uses some other pixmap?

I tried to hack this out of screenSizePreview.py but my naive attempt failed
miserably.

Version-Release number of selected component (if applicable):
All versions of redhat-config-xfree86 that I've tried (Red Hat 8.0 and 9).

How reproducible:
You must run it over a somewhat slow link, otherwise you don't notice.  The
average cable modem or ADSL connection should be sufficient.

Steps to Reproduce:
1.ssh root.link
2.redhat-config-xfree86

Comment 1 Mike A. Harris 2003-04-16 01:27:40 UTC

The screen preview is *NOT* a snapshot of the screen.  The screen preview
already is a few very small pixmap images.  It is the same code that
Xconfigurator used to use called "Xtest", which has had the graphics updated
to look like the modern desktop.

Unless something was changed that I'm not aware of.

Brent?

Comment 2 Jason Tibbitts 2003-04-16 01:47:12 UTC

If that's true then you folks managed to choose images that always look exactly
like whatever my desktop looks like.

Seriously, though, redhat-config-xfree86 has (since I first tried it in the
pre-8.0 betas) always used the local desktop for the preview.  I just tried it
on a work machine across a cable modem (2.5Mbps down, .5Mbps up) and it took six
minutes for the initial window to appear, during which time my desktop was
useless.  The cursor would move but windows would not update their contents, the
focus would not change, etc.

I just don't think anyone envisioned a sysadmin running this application
remotely, especially across a slow link.  (Really, I pine for an interactive
text-mode application to do this, but someone's already filed that enhancement
request.)

Comment 3 Mike A. Harris 2003-04-16 05:25:49 UTC

/usr/X11R6/share/Xtest/pixmaps/desktop_icons.png
/usr/X11R6/share/Xtest/pixmaps/panel_left.png
/usr/X11R6/share/Xtest/pixmaps/panel_mid.png
/usr/X11R6/share/Xtest/pixmaps/panel_right.png

Comment 4 Mike A. Harris 2003-04-16 05:28:29 UTC

I'm not sure that the application is designed nor intended to be ran remotely.
Brent will have to comment on that.

Comment 5 Brent Fox 2003-05-27 21:55:41 UTC

redhat-config-xfree86 does take a snapshot of the current desktop in order to
draw the preview screen.

Alex originally wrote the program, so it's hard for me to say what exactly he
had in mind.  My guess is that he assumed that the tool would be run on the
local machine.  I'm not surprised that there might be some strange behavior by
running it remotely.  

I agree that the behavior is a little strange, but I'm not sure it's bad enough
to warrant fixing.  Over a high speed network connection, it seems to run pretty
fast.  I think that using pretty much any X application of any complexity over a
remote link is going to be pretty darn slow over a slow connection.