Conference bulova::decw_jan-89_to_nov-90

For fastest results, please QAR this problem in the V54-FT database.

The SPX hardware supports clip lists.  Unfortunately they must live in offscreen
memory.

The error message means that you can not get the clip list into offscreen
This is probably because it is too many rectangles.

One more side note, in all the servers so far, clip bitmaps are turned into
a list of clip rectangles.  Trying to draw thru a fairly complicated bitmap
can get you into the same situation.

Mike

    
    Re: .2
    
    The product in question is version 1.3 of the VAXcluster Console
    System.  The C� application, which I coded, uses many clip bitmaps to
    modify pixmaps on the screen.  VCS monitors up to 32 system console
    lines.  Each console line is represented on the screen by a push button
    widget with a background pixmap that looks like the system it
    represents.  The background pixmap has three colors; forground,
    background and 'icon color'.  The pixels of 'icon color' are all of
    the background pixels that are on the inside of the icon boundry�.
    
    We have an icon converter application that takes a .DDIF file and
    converts it into the .UIL source for a push button widget. The widget
    is given background pixmap and highlight pixmap resources.  The
    highlight pixmap has a black pixel in every bit of the icon that is
    'icon color'.  The highlight pixmap is converted into the clip bitmap
    using Copy Plane.
    
    The icon clip mask is used when an 'event' is reported on one of the
    systems.  All of the pixels of 'icon color' are chaged to red, yellow
    or green depending on the priority of the event.  The change is done
    using a Fill Rectangle with a GC that has the correct forground color
    and a clip mask to match the icon to be changed.
    
    Is the failure because one of the bitmaps is too complex or because
    there are too many clip bitmasks on the server?  There are only two
    GC's that have a clip mask.  One has a static clip mask with a moving
    clip mask origin. The other has its clip mask changed each time an
    icon needs to have its 'icon color' pixels updated.
    
    What limits the size of offscreen?  Is there a server error reported to
    the client when offscreen is out of space?
    
    The SPX seems to be the only server that has a problem with the clip
    bitmasks that we use.  Is it possible that there is a leak in the
    offscreen memory allocation?
    
    If you want to see what the clip bitmasks look like, copy the following
    file from my public area and look at the highlight resources for the
    push buttons:
    
    VINO::MOSEL:[MCARLETON.PUBLIC]VCS$DW_ICON_DFN.UIL
    
    						Thanks,
    							Mike Carleton
    							VCS Project Leader
    
    �The icon color clip mask is formed by flooding the outside of the icon
    with background color.  Inside pixels that are still icon color form
    the clip mask.

Can you create a program that will reproduce this problem?

The SPX is the first piece of hardware from digital that supports clip lists in
hardware.  It is NOT the last, there are curently two more under development.

In all cases I have seen where people are using bitmap clip lists, there are
faster ways of doing what they want.  It normally involves using copy area's
and something like the OR writing modes.

In your case it would probably be faster to create a few pixmaps with the
correct colors and keep them running around for use when you need them.

The SPX should give you 4K rectangles without fail.  It looks like some of your
bitmaps are pretty worce case and can get above that number.

Mike

    > Can you create a program that will reproduce this problem?

    I'd have to toss something together.  I'm chasing a CLD at this moment
    so it will have to wait a few days.  VCS 1.3 is a layered product that
    is distributed on the July CONdist CD ROM.  You can always install it to
    run a test.  It is installed on the SQM system (HILO::) for
    Connectathon if you want to pipe a display back to an SPX machine from
    there.

    > In all cases I have seen where people are using bitmap clip lists,
    > there are faster ways of doing what they want.  It normally involves
    > using copy area's and something like the OR writing modes.

    The first version used a clip pixmap and about 5 CopyArea's to do the
    same thing.  Using the GC clip mask seemed much cleaner and was much
    more likely to be optimized in the server or hardware in the future.

    My assumption was that the clip mask GC would cause the server to do
    the kind of AND and OR CopyArea's that I was doing by hand from the
    client side of the wire.  Is it not this kind of operation that the
    clip mask GC was made for? 

    > In your case it would probably be faster to create a few pixmaps with
    > the correct colors and keep them running around for use when you need
    > them.

    This is what is done.  Each variation of each icon is created only once
    and the pixmap is reused.  It may end up that there are 20 different
    icons with 9 variations for each stored in the pixmap array.

					Thanks,
    						MJC

>    My assumption was that the clip mask GC would cause the server to do
>    the kind of AND and OR CopyArea's that I was doing by hand from the
>    client side of the wire.  Is it not this kind of operation that the
>    clip mask GC was made for? 

Since a clip pixmap can be used to clip any drawing operation not just CopyAreas
The clip pixmap is converted into a clip list.  The bottom line is that the
hardware doesn't know that it is drawing to a clip pixmap, it just draws to a
clip list same as for ocluded windows.

Mike.

P.S.  This is QAR material.  thanks

    This problem is QAR 1650 in the V54-FT database on TRIFID.
    
    I'll look into creating a modified image that does the coloring of the
    icons a different way.  Is there a SPX machine around that I can test
    this on?
    
    						MJC

    If you are in reasonable driving distance of ZK there is a lab with "one
    of every workstation".

    Re: .4
    
    There is a test case for this problem that can be copied from:
    
    VINO::MOSEL:[MCARLETON.PUBLIC.SPX]*.*
    
    Source code is included.
    
    Could someone with a VS3100/SPX try this code out to see if it will
    cause the reported error?
    
    						Thanks,
    							MJC