Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!ames!uhccux!virtue!comp.vuw.ac.nz!munnari.oz.au!labtam!graeme From: graeme@labtam.oz (Graeme Gill) Newsgroups: comp.windows.x Subject: Re: what's most important to you for R5? Summary: Re: Re: poly-copy Message-ID: <4884@labtam.oz> Date: 28 Jun 90 05:34:57 GMT References: <9006222202.AA17654@expire.lcs.mit.edu> <2493@acorn.co.uk> Organization: Labtam Limited., Melbourne, Australia Lines: 96 In article <2493@acorn.co.uk>, john@acorn.co.uk (John Bowler) writes: > > In article <4865@labtam.oz> graeme@labtam.oz (Graeme Gill) writes: > > While I understand there > >would be restrictions in poly-copy operations, in that the copies would > >have to be independent (ie. the source for one must not overlap the > >destination of a previous copy), > > Why? Handling overlapping source regions is easy. The sample server > already has a body of code which does this (the region code). It is > easy to implement a general purpose ``move region'' interface (and > this is quite useful in general). > My comment about non-overlapping copies was really made with the general case in mind - ie. if each copy allowed different source/destination drawables for each copy. If however a poly-copy operated in a similar manner to other poly operations, and assumed the same drawables within one operation (the only practical assumption), then I agree that there would not be any problem with overlapping copies as long as the order was preserved. > > some applications make extensive use of > >copies, and the ultimate performance is currently limited by the number > >X operations/sec the server and communication medium are capable of. > > I don't understand the point. Poly{CopyArea,CopyPlane} is easy to > simulate at present:- > > < stuff about using clip region > Two points: A poly-copy would be different from setting a clip region in that the displacement of the copy could be different for each rectangle. ie a client could then load an image set (ie "font" or colour images) as a single pixmap, and in one operation copy many different sub images from the pixmap to different position on the screen. I think this capability would make for a more symmetric range of graphics primitives. The other thing is that poly operations transmit information and work faster than a series of separate operations. ie. our X terminal will do about 11000 separate invert 10x10 rectangles/sec, while as a poly-fill invert rectangle it can do 18700 10x10 rectangles/sec. The difference is that done separately there may be separate packets sent for each invert, a validate is done on the gc and drawables each time, and other setup code is executed for each operation. For a poly-operation all this is done once, and the server then just has to sit in a tight loop, whipping rectangles off the poly list and executing the operation. Doing them one at a time also suffers from the problem that the performance varies a great deal depending on how much opportunity xlib gets to package separate operations up into poly operations (if they are available !), and also the ability of the networking code to combine X buffers into larger buffers for transmission. The above mentioned 11000 figure was under favorable condition - under other conditions I have seen this particular test drop as low as 3500 rectangles/sec. > The ``some applications'' which you > mention wouldn't happen to be FrameMaker would they? FrameMaker has a > specific problem - it has large numbers of fonts which it really wishes Yes, one of the applications I had in mind was FrameMaker, although I agree that it is not doing things properly. I don't claim to understand enough about fonts to know why it does things the way it does instead of using the X font capability. I am told there is an assumption in the X11 server that fonts are stored locally (ie. the server is running on a workstation), and that this creates problems downloading fonts from different hosts. From a server code point of view, it would be nice to have the option of caching fonts in expanded form (ie. expanded to the depth of the screen drawable), and/or having separate external and internal packing and bit/byte order so that fonts could be downloaded from any machine a client might run on. > my session produced 359 NoExposure events corresponding to 145 CopyArea and > 214 CopyPlane requests (plus over 1000 PutImage requests from, I think, > downloading the fonts). > > John Bowler (jbowler@acorn.co.uk) Another major advantage of supporting a poly-copy primitive would be the reduction in NoExposure events that have to be transmitted by the server and thrown away by the client. A poly-copy consisting of perhaps hundreds of copies would produce only one event - a NoExpose event or an expose region. From my look at how FrameMaker works, it seems to cache some things in the server as bitmaps, but draws most of its text line by line as loadimage requests. This is rather slow over a limited bandwidth medium like ethernet (400 Kbytes/sec) compared to copying from locally stored bitmaps (7 Mbytes/sec) or pixmaps (14 Mbytes/sec). Graeme Gill graeme@labtam.oz.au Labtam I.S.D. Pty. Ltd. Telephone +61 3 587 1444 43 Malcolm Road, Fax +61 3 580 5581 Braeside, 3195. Victoria, Australia.