[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

3450.0. "vms server "features" with motif application" by BLKPUD::THOMASA (Wow I,ve got a colour ....) Wed Oct 10 1990 11:01

		cross posted motif/decwindows

Hi all,

	I have a customer, who has sent in a large motif application that
basically fills the sceen with a large window widget and draws a multicoloured
map inside (very pretty). Around this map is a green line box that can be moved
by holding down the MB2 button. The application does some xdrawlines while this
is happening to get the old "rubber band" effect.

	This all works fine (and quickly) until he maps a large complex widget
onto the screen (plays with it) and then unmaps it. From this point onwards the
"rubber banding" is unbelievably slow -- you can watch it drawing, line segment
by line segment.

	What is also of interest is that if you do a show proc/cont/id="the
decw$server_nn process id" , when the rubber banding is ok the decw$server
process DOES NOT do any direct i/o, but when the rubber banding becomes slow it
does 100's of direct i/o's 

	All this has been tested on vms 5.3-1 and 5.4 using motif 1.0(customer)
and motif 1.1 (me).

	Interestingly if a utrix server is used to display the output we don't
see the same problem.


so:

  q1. Anybody seen anything similar with the decwindows xserver on vms before ?

  q2. What else should I look for to investigate further  ?

  q3. Since the only other time I've seen performance slow so dramatically, is
      when "synchronization" has been turned on  

      Does the source for any of the motif toolkit routines call Xsynchronise
      to turn synchronization "on" ?, that in someway could manifest itself
      only with the vms xserver ? (outside chance question)



			Andy

p.s.  if anyone out there is interested enough I'll post the location of the
      source.

T.R	Title	User	Personal Name	Date	Lines
3450.1	Tight display memory	TOOLEY::B_WACKER		`Wed Oct 10 1990 11:40`	7
	It sounds like you've filled up display memory with pixmaps, forcing paging to ram and don't have enough working set to satisfy that so the server has to page to disk. Just a wild guess. Bruce
3450.2	hmm -- no I don't think so	BLKPUD::THOMASA	Wow I,ve got a colour ....	`Wed Oct 10 1990 11:53`	6
	Hi, re: .1, no I don't think so the decw$server process although it was doing direct i/o, didn't clock up any page faults, I also changed the file decw$startserver.com to double its working set quotas and wsextent values, restarted decwindows and re-tested -- no defference, (my workstation has lots of memory and pool (lookaside space,npagedyn)as well)
3450.3	Why do io	TOOLEY::B_WACKER		`Wed Oct 10 1990 12:30`	6
	The only thing I can think of that would beat on i/o would be font loading. What does a show dev/files give you on the server? Could you have loaded so many fonts that display memory is full? What's your hardware and versions? Bruce
3450.4	more info	BLKPUD::THOMASA	Wow I,ve got a colour ....	`Thu Oct 11 1990 08:05`	32
	Hi, Ok I've looked at this a bit more :- 1. the decwindows server has been restarted with very large wsdef and quota and pfrath and wsinc set up so it soon gets all the working set it needs. The server NEVER does any paging before during or after its slow operation. I think we can rule out lack of memory and paging as causes. 2. I notice that not only does the line drawing become slow but the refreshing of the screen from xcopyarea during exposure processing. Since the line drawing is implemented by refreshing from the pixmap and then drawing to the window, I began to suspect the large PIXMAP I use for backing store had been "de-cahced" somewhere by the server. 3. Next I did a Xdrwawpoint to the pixmap to "write" to it -- behold this restored full working speed. conclusion: It seems that the loading of the large widget somehow caused my large pixmap I use for backing store to be "de-cached somewhere". Here it remains until its changed in someway which would seem to re-cache it. The evidence as to where this pixmap gets de-chached to isn't clear to me -- if it was the pagefile why don't I see the decw$server process clocking up page faults ? -- the only difference I do see its lots more direct i/o's where is it putting the pixmap -- surely it doesn't "de-cache" it back down the wire somewhere does it ? any thoughts anyone ?? Andy
3450.5		DECWIN::FISHER	I like my species the way it is" "A narrow view...	`Thu Oct 11 1990 15:28`	18
	You misunderstand "paging" from .1. I think .1 and .4 are right. The pixmap is "paged" out of the workstation offscreen memory into virtual memory. If you have enough physical memory, it never gets VMS-paged to disk. In other we are not talking about real paging that working set et al will help. We are talking about what the server does when offscreen memory is full. An SPX will help this...there is a lot more offscreen memory. Also MFB which does not have to worry about this at all. Ultrix systems with color frame buffers don't have to worry about it either, but the more recent systems with graphics accelerators have the same problem. The only thing that you, as a client, can do is to (1) use fewer pixmaps, or (2) change the access order of your pixmaps so that you don't thrash or (3) break up big pixmaps into several small pixmaps. These may be able to fit into memory better and/or you may need to access only one of them at a time. Burns
3450.6	the solution	BLKPUD::THOMASA	Wow I,ve got a colour ....	`Fri Oct 12 1990 05:26`	32
	re: .5 et all from MOTIF conference :- My guess is that the application is using multiple large pixmaps and the pixmaps are thrashing in offscreen memory. If all the pixmaps do not fit in offscreen memory then some pixmaps are copied into main memory and copied back to offscreen memory when needed. Once a pixmap is kicked out of offscreen memory it doesn't get copied back in to stay unless the pixmap is drawn to. If the pixmap is only copied from then it will be copied from main memory piecemeal and it will not kick out other pixmaps that have been drawn to that are in offscreen memory. That is because kicking out those pixmaps is more expense then just copying in a pixmap that is in main memory. Now if the pixmap that is in offscreen memory and has been drawn to but is no longer needed by the app then of course it is the wrong decision to keep copying a pixmap from main memory. The workaround is to draw something to the pixmap that you want in offscreen memory. The problem is their is no good way for the server to predict the future pixmap usage and to know which pixmap should be in offscreen memory. Bill so .5 and the above have hit on the problem -- the solution for my customer was to write to his pixmap (xdrawpoint to toggle a pixel ) hence forcing it into offscreen memory just before he started to use the pixmap "in anger" Thanks everyone Andy