Conference bulova::decw_jan-89_to_nov-90

No idea why it's slow (other than the server people probably didn't thing it
needed to be fast, so they didn't work on it too hard).

As to a workaround, can't you flip-flop between the two to get the desired
effect?  example:

pA is Pixmap A, pB is Pixmap B.

today, you do:

pA is refresh, pB is Undo.

1) user does "draw"
2) you copy pA to pB.
3) you do draw to pA.
4) goto 1

right?

could you:

1) user does draw 1
2) you do draw 1 to pA	(pB is the Undo here)
3) user does draw 2
4) you do draw 1, draw 2 to pB 	(now pA is Undo)
5) user does draw 3
6) you do draw 2, draw 3 to pA  (pB is Undo)
etc.

??

The problem is that both large full depth pixmaps can't fit into
offscreen memory at the same time and thrashing of offscreen memory
to/from host memory is occuring and that transfer since it probably
involves paging is slow. To draw to a pixmap requires that the pixmap
be completely in offscreen memory so draw to pixmap A loads pixmap A
into offscreen memory, draw to pixmap B copies pixmap A to host memory
and then copies pixmap B from host memory to offscreen memory, draw to
pixmap A again cause pixmap B to be copied to host memory and then pixmap
A is copied to offscreen memory. If there is physical memory available
for both pixmaps so no paging occurs then the copy of each pixmap between
host memory and offscreen memory is at about 350kb/sec. Copies between
pixmaps that are in offscreen memory is 8mb/sec.
							Bill

RE: .2 - Well, at least I know what the problem is.  Thanks.

RE: .1 - It's a good suggestion.  I Wouldn't think it would be any quicker
	 in most cases than my method (my copy pA to pB copies the smallest
	 rectangle enclosing the last operation - which in most cases would
	 probably take about the same time as redrawing the operation - more
	 time for diagonal lines - less for difficult operations like flood
	 fill)  But after reading .2, im may be a good deal better, since 
	 both drawings are into the same pixmap.  (In my method, one into the 
	 undo pixmap, one into the current pixmap).  Of course, it may be just
	 as bad, since after each operation, the filp-flop will mean reading
	 a new pixmap into offscreen mem before doing the operation.  I'll 
	 give it some thought, thanks for the suggestion.

-Jonathan

If you got thrashing, you've got thrashing.  My scheme won't help.

How difficult would it be to keep the Undo buffer on the client side?  Might
be a real killer across an ethernet, but it might be faster to ask for
the changed area of the pixmap back than to move it to another pixmap.

I don't see why you need 2 pixmaps. How do you update the window? Do you
draw to both the window and the pixmap or do you draw to the pixmap and copy
to the window? Couldn't you use the following scheme?

W is the window and gets all draws immediately
P is the pixmap for undo's and for refresh minus the most recent draw.

User draws D1. Draw D1 to W.
User draws D2. Draw D2 to W, Draw D1 to P.
User draws D3. Draw D3 to W, Draw D2 to P.
ETC.

For undo copy from P to W.
For refresh copy from P to W and re-draw most recent request.

						Bill

Well, it's not that easy.  If it were always simple to save a drawing operation
it might be feasable.  The problem is that operations like flood fill, or 
scaling part of the picture are not simple.  It wouldn't be very nice if on an
expose event, the application had to reproduce one of the more time consuming 
operations.  It would also interfere with the way zoom works.  Zoom has to be 
updated from the pixmap (can't be updated from the screen because that might be
 obscured) - there wouldn't be any way to get the last drawing operation into 
the zoom window.  There are probably other problems as well, it's a mess, and 
there aren't really any neat solutions thay I have come across yet.  But I'm 
still open to suggestions.  Of course, not to mention the fact that at this
point any major changes to the basic implementation I have now would be a
real paint. 

-Jonathan

I think it would be much less annoying to have all of the draws fast and
an expose have to do a copy and 1 draw then it would to have each and every
draw to be slow. For zoom just use the window copy obscured or it. It used
to be that way and I rather liked the old behavior. The only way you can
get the paint window obscured while doing zoom is by shift clicking on the
push to back icon. Normally the zoom user interface causes the paint window
to be popped to the top.
						Bill