| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2120.1 | Try SPX. $3500 MLP - GPX trade in | STAR::BMATTHEWS | | Wed Jan 24 1990 07:47 | 16 |
| I am working with a customer who's application uses two large pixmaps,
possibly more in the future.He is experiencing noticable delays when
switching operations between the two pixmaps.After the first
operation on a pixmap,subsequent operations are fast.Monitoring the
application indicates that there is no page faulting going on but
quite a lot of direct IO. Is this because the pixmap has to be paged
into video RAM from the application working set on the first operation?
Can anyone confirm or explain this?
> Yes, that is exactly correct. On the GPX based graphics systems there is
> 1024x864 area for large pixmaps. With the new SPX graphics option the
> area is about 2560x1024 but is allocatable linerally with a max width of 8k.
> In 5.3-1 the max size for a single pixmap is still the screen size. With
> 5.4 the limit for the largest single pixmap will be raised to the size of
> the available offscreen memory.
> Bill
|
| 2120.2 | A supplementary question... | SHARIF::BULLARD | Seize the day !! | Mon Jan 29 1990 10:10 | 10 |
| Thanks for the information.The customer has now decided to improve the performance
by always updating from the pixmap held in offscreen memory.He does this by
doing a XCopyArea of the pixmap that needs to be updated into the pixmap that
is held in offscreen memory.He has observed that even small pixmap copies consume
quite a lot of CPU.The relationship between the CPU usage and the pixmap size
does not appear to be linear. Is there any thing that can be done to improve the
performance of this operation e.g tuning SYSGEN parameters?
regards Mark
|
| 2120.3 | More info | DECWIN::BMATTHEWS | | Mon Jan 29 1990 10:50 | 21 |
| <<< Note 2120.2 by SHARIF::BULLARD "Seize the day !!" >>>
-< A supplementary question... >-
Thanks for the information.The customer has now decided to improve the performance
by always updating from the pixmap held in offscreen memory.He does this by
doing a XCopyArea of the pixmap that needs to be updated into the pixmap that
is held in offscreen memory.He has observed that even small pixmap copies consume
quite a lot of CPU.The relationship between the CPU usage and the pixmap size
does not appear to be linear. Is there any thing that can be done to improve the
performance of this operation e.g tuning SYSGEN parameters?
> There is no single pixmap that is held in offscreen memory. Whenever the
> server needs to draw to a pixmap it must be first copied into offscreen
> memory if it is not already there.
>
> You could try defining the decw$server_ws* logicals before decw$startup is
> invoked to give the server a larger working set.
>
> Bill
|
| 2120.4 | More questions...
| SHARIF::BULLARD | Seize the day !! | Fri Feb 02 1990 12:12 | 13 |
| Thanks again for the info.I appreciate that there is no single pixmap
in offscreen memory.The customer I am dealing with has at least two
large pixmaps.At times he needs to update the screen with just part
of the pixmap.To avoid moving a large pixmap into offscreen memeory
every time he wants to update the screen he is using XCopyArea
to move the portion of the pixmap that is required first
to a pixmap in offscreen memory,which the application maintains,and
then to the screen.However he has noticed that this takes quite a lot
of CPU (about 0.3 seconds for a 50 x 80 pixmap) even for quite small
areas.There is no paging occuring which would imply that the server
working set is adequate.Can anyone explain why this operation is so
CPU intensive.The server is running on a VS2000 and the application
is running on remote Microvax 3600.
|
| 2120.5 | Copy Area Moves tries to move both the source and dest into offscreen | DECWIN::ROSENBLUM | | Tue Feb 06 1990 17:27 | 19 |
| Copy Area moves both the source and destination of the copy into offscreen, or
at least it tries to.
If it can't fit the whole pixmap into offscreen then it takes the
full scanline of the source and puts that into offscreen then copies the one
scan line into the destination pixmap. It keeps moving this one or two scan
line chunks till the copy is complete.
As you can tell it is a long, time consuming process.
My suggestion is to use a lot of very small pixmaps I.E. 32 by 32 if he can,
These are stored in a small pixmap cache seperate from the large area of
offscreen memory, also try to use single bit deep pixmaps if he can, you can
stack those in offscreen and then copy between them and the screen using copy
planes.
What size is his source pixmap and his off screen pixmap.
Mike
|
| 2120.6 | Thanks that's exactly what I needed to know | SHARIF::BULLARD | Seize the day !! | Wed Feb 07 1990 05:55 | 7 |
| Unfortunately the customers source and offscreen pixmap are both full
screen pixmaps.I have passed the information to the customer and we
are now considering how to approach the problem .
Thanks again
Mark
|
| 2120.7 | | ZSAZSA::READINGS | Richard Readings | Mon Feb 26 1990 12:52 | 11 |
| The customer tried creating a mosaic of smaller pixmaps instead of one large
pixmap but it was hard to implement and not really practical.
In this application the customer simply wishes to overwrite the destination
pixmap with the source pixmap. Is there any way to avoid attempting to load both
source and destination pixmaps into off-screen memory in this case, and thus
speed up the process? The current level of performance is causing the customer a
lot of pain.
Richard
|