[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

2374.0. "XCopyArea performance on VAXstation" by ZSAZSA::READINGS (Richard Readings) Wed Feb 28 1990 09:57

My customer is using several full-screen pixmaps on a 4-plane VAXstation 2000, 
under VMS 5.3 (DECwindows V2.0). They copy pixmaps to the screen using 
XCopyArea. If the pixmap is in virtual memory then the server loads the source 
pixmap into off-screen video RAM first, which takes about 2 seconds. If there 
is already another pixmap in off-screen video RAM, which has been modified, 
then it unloads that into virtual memory first - the whole operation then takes 
about 6 seconds! Furthermore copying from one full-screen pixmap to another 
takes more than 10 seconds.

There seems to be a major bottleneck when XCopyArea moves pixmaps between video 
RAM and virtual memory.  We have tried a 14-Mbyte VAXstation 2000 but that 
makes virtually no difference.

Using XGetImage and XPutImage to move images in and out of a single off-screen 
pixmap is faster but involves the (remote) client to a much greater extent and 
increases traffic on the wire. 

Can anyone suggest a way of improving the performance? 


Richard

T.R	Title	User	Personal Name	Date	Lines
2374.1	match hardware to the job	TOOLEY::B_WACKER		`Wed Feb 28 1990 12:06`	9
	>Can anyone suggest a way of improving the performance? Reduce the depth of your pixmaps and use XCopyPlane or get more display memory via 8 plane or SPX. That's just the way it works. There's limited area for pixmaps and it does the best it can to handle the overload. There's a good explanation of how the server uses display memory back quite a ways, but I couldn't find it.
2374.2	SPX on a VAXstation 2000?	ZSAZSA::READINGS	Richard Readings	`Thu Mar 01 1990 04:04`	17
	> Reduce the depth of your pixmaps and use XCopyPlane or get more > display memory via 8 plane or SPX. That's just the way it works. > There's limited area for pixmaps and it does the best it can to handle > the overload. Has anyone tried SPX on a VAXstation 2000? I understand that its not supported but it could be a solution. The customer needs 4 plane pixmaps (minimum) for colour. The main problem seems to be moving data between video RAM and virtual memory. Is there any way of speeding this up? Even SPX would run out of off-screen video RAM pretty quickly with this application. Thanks for the help Richard
2374.3		GALAXY::MCLEMAN	Jeff McLeman, VMS Development	`Fri Mar 02 1990 07:47`	4
	I believe the SPX WILL NOT work on the VS2000. The VS3100 had a compatiblity mode on the graphics interconnect to run the GPX module, but the SPX takes full advantage of the native mode. But then again, I could be wrong.
2374.4	While we're on the subject ...	GOFER::HARLEY	Skyking, Skyking, do not answer...	`Fri Mar 02 1990 11:36`	6
	... Will SPX work on a MVII/GPX? (wishfull thinking) if so, does the VCB02 need to be replaced, or can I get the chips to upgrade it to SPX? /harley
2374.5		GALAXY::MCLEMAN	Jeff McLeman, VMS Development	`Fri Mar 02 1990 15:04`	2
	The SPX is not a Qbus device. It was designed for the VS3100 only. So you have to stick with the GPX on the Qbus machines.
2374.6	Could you deal with MFB?	DECWIN::FISHER	Burns Fisher 381-1466, ZKO3-4/W23	`Tue Mar 06 1990 15:30`	11
	As has been said a number of times here, there is really no way to increase the performance of "pageing" from virtual memory to video memory. The best you can do is try to minimize it. That is the way the h/w is designed. The GPX is a pig for moving data between VM and display memory. Actually, a bitonal system is best for this, since everything is in memory to begin with! Burns