Conference bulova::decw_jan-89_to_nov-90

SPX has a 4Mpixel frame buffer about 2.5Mpixels of which are usable for
large pixmaps.

FYI, the follow-on is planned to have an entry level config that includes only
2Mpixels and only supports the 1024x864 or smaller monitors but will have
an option card that will raise the frame buffer size to 6Mpixels.

						Bill

>SPX has a 4Mpixel frame buffer about 2.5Mpixels of which are usable for
>large pixmaps.

But the question is whether we'll keep enforcing the artificial 1024x864 
limit as we do now.  GPX has more that 1024x864 available, but you 
can't create a pixmap larger than those numbers.

>FYI, the follow-on is planned to have an entry level config that includes only
>2Mpixels and only supports the 1024x864 or smaller monitors but will have
>an option card that will raise the frame buffer size to 6Mpixels.

6M is great news.  I've gotten lots of complaints that the frame 
buffer just isn't big enough to do the jobs.

Yes, pixmaps larger than 1024x864 are supported for SPX. GPX really only
has 1024x864 available for large pixmaps. Glyphs, room for at least part\
of a tile/stipple pattern and a mask take up most of the rest of offscreen
memory on a gpx.
						Bill

Note, however, that we discovered only a few days ago that the wrong test
was being made and that, in fact, spx machines were only allowing the
smaller size of pixmap.

This should be fixed in VMS V5.4 EFT (not IFT).

Burns

    This is causing us problems porting from the DECstation to the VAXstation.
    At least one vendor (Xilinx) depends on being able to create a 1024x1024
    pixmap, and can do so on the DECstation.  I'd rather have the fallback
    that VMS can create the larger pixmap, even if it's slow on a GPX.
    
    Is there any reason this can't be done?
    
    Best,
    -pk 
       
    

Well, almost anything is a mere matter of software, but this one is a real pain.
The problem is that the GPX can't draw to virtual memory, only to its frame buffer.
So it is not just a matter of paging in and out and being slow.  It is a matter
of developing a whole new set of drawing routines that draw into virtual memory.
Yes, I know we could use the CFB code on the MIT release or the DECstation CFB
code, but that would still require a lot of porting work.

Let's put it this way...would you rather have bigger pixmaps, or would you rather
have backing store?

(I should not make it sound like a couple notes here will
change priorities.  Customers have spoken quite loudly that they really want
backing store.)

Burns

    
    Both.  And for largely the same reasons.  If each pixmap could be
    managed as a list of "chunks", then a "logical" pixmap could be of
    any arbitrary size (probably up to the 16-bit limitation of X11).
    
    In addition, you could decompose the backing store pixmaps into smaller
    chunks - and updating of the backing store pixmap then could be selective
    based on the actual need to maintain a specific area.
    
    While there is a cost for this - operations might need to be executed
    in the hardware multiple times for operations that span chunks... I
    think that the reduced thrashing of large pixmaps would balance the
    cost.
    

I agree that both is what customers want.  The main problem with the 
current limitation is that it is not documented, nor is there any 
reasonable discussion of the costs/benefits of pixmaps.

We need to face the fact that the GPX is inadequate for large or 
multiple pixmap applications and communicate that to the customer in 
an appropriately gentle fashion.

The worst manifestations are people porting from DECstations or just 
running the client there and pointing to a GPX type.  All of a sudden 
interoperability, standards, XUI, X and hence DEC get a bad name.  This 
could be avoided if we'd at least document the limitation.

Users are accustomed to virtual memory and expect the hardware to 
accept any size pixmap that is common in the industry.  I realize 
this is unreasonable from a technical standpoint, but we haven't 
yet and may not ever be able to educate our customers on the 
limitations.

Ugly as it may be, I think we need to bite the bullet and provide for 
larger pixmaps even on the GPX's.  More and more software will be 
written on our or other's more capable hardware.  Pixmaps kill the 
client/server advantage and seriously disable X.  Note that it is no 
more reasonable to ask users to write their code to use arrays of 
smaller pixmaps than it is for us to do it in the server.

If the technical problems of paging in and out of display memory are
too great, just use the software graphics routines and document why it is
slow.  I wouldn't even spend too much time optimizing it.  The first
thing customers need is to be able to run common applications at any 
speed.  BadAlloc is simply an unacceptable surprise when an
application works everywhere else.  If it runs a lot slower then they
can decide to accept it, upgrade to an SPX, or switch to another
workstation.

It is particularly important that third party applications run on our
platforms.  Otherwise, we'll be bad-mouthed before they even send out
a demo, and customers will feel angry at us because they can't even
look at something without switching hardware. 

As to backing store, judging from customers' responses to BadAlloc, I
doubt if the ones who are clamoring for it understand the inevitable
cost in display memory/paging.  It sounds like it is free, but
probably won't really help much on 1024x2048 machines.  Small pixmaps,
on the other hand, leave no alternative but to switch and we may lose
customers' allegiance if the path is too painful.

Bruce, CSC/CS

Every day spent on making the old, crippled GPX work better is a day spent not 
making SPX and other future graphics hardware faster and more functional.
If the tradeoff is having a customer that's unhappy because it doesn't work
or unhappy because it's intolerably slow, I'd take the path that is the least
effort for DEC, which is to freeze GPX where it is and get on with things.

>freeze GPX where it is and get on with things.

I could agree if we'd just document it, but experience shows that 
without software/hardware changes it is next to impossible to get 
anything documented.  The pixmap limitations should be in the DW SPD as 
well as all the sales literature and comparison charts.

Unfortunately, it is probably more likely to get the software graphics
into the server!

We need to eliminate the unpleasant surprise factor.  We preach that a 
VAX is a VAX and X is X, but can't develop on a GPX to run on an 
SPX or DS and the customer feels betrayed by us.  We're told that 
customers are not renewing support contracts in increasing numbers and 
anything we can do to keep them from getting mad at us will help 
insure all of our futures.  Do you really want to "freeze" thousands 
of GPX users?

RE: .10

It's a fundamental part of the architecture of the X Window System that pixmaps
are a scarce resource, the size of pixmaps available is server-implementation-
dependent, and applications must be prepared to have their requests for pixmaps
rejected by the server.

Documenting the implementation-dependent maximum size of a pixmap on the GPX is
not a good idea.  It merely encourages customers to write broken applications
that have specific server dependencies in them.

--PSW

>It's a fundamental part of the architecture of the X Window System
>that pixmaps are a scarce resource, the size of pixmaps available is
>server-implementation- dependent, and applications must be prepared to
>have their requests for pixmaps rejected by the server.

True, but the fact is that it is not practical to write something
that, for instance, pans over a 2000x2000 area by breaking it up into
n separate pixmaps.  We may have the luxury of sizing our calendars,
etc., but some fendors don't.  Third parties will write to fit some
minimum level of support and not worry about a 300x500 PC.  By not 
publishing our limits we prevent them from making informed decisions.  
Buried in the "architecture of the X Window System" is not visible 
enough to keep customers happy.  Our documentation doesn't discuss it, 
suggest workarounds, or otherwise give them any help.  If we 
documented the limits the maybe we'd acknowledge the architecture 
enough to help the customer.  Just being "right" or having our @#$ 
"covered" doesn't keep customers happy and coming back.  What we 
really sell is happy customers and every time they get surprised or 
disappointed it doesn't make any difference how "right" we are, we 
lose.

>Documenting the implementation-dependent maximum size of a pixmap on
>the GPX is not a good idea.  It merely encourages customers to write
>broken applications that have specific server dependencies in them.

Bull!  Tell them the limit and how using it may "break their
application" and then let them make the decision.  That's what X is all
about!  Is an application any less broken because (in their view) we let 
them do it because they aren't experts in X architecture?

You'd be amazed at the (low) level of understanding many of our 
customers have.  If we assume some arbitrary level of understanding 
must be reached to program X or XUI then we're going to miss a lot of 
the market.  Maybe that's not the way it SHOULD be, but that's the way 
it IS!

If you really want to know what X is all about, come spend a couple of 
days on the phones with us.  Technical understanding is only the tip 
of the iceberg.  The success of X depends more on our ability to 
communicate than you'd imagine.  An unsophisticated VMS user would 
have a chance with a %XLIB-F-PIXTOOBIG error.  You really expect them 
to understand BadValue???

Sorry if this has been too flamy, it's been a hard day trying to get 
stuff across to customers who often don't have a clue.

Bruce

RE: .12

>Tell them the limit and how using it may "break their
>application" and then let them make the decision.  That's what X is all
>about!  Is an application any less broken because (in their view) we let 
>them do it because they aren't experts in X architecture?

If we did that, they'd just be right back on the phone again when they tried
to set the display for the application to some PC or other X server that had
a lower pixmap size limit.  And then we'd have you back here in this conference
bellyacheing about why did we tell customers the specific limits, thereby
giving them the false impression that they can rely on the figures.

This is a no-win situation.  The best thing is to say up front and clearly
that programs that depend on 100% availability of arbitrary-sized pixmaps are
incorrect.  The DECwindows documentation already says this in several places,
although not in such strong terms.  Perhaps we need to be more forceful about
saying that.

>An unsophisticated VMS user would 
>have a chance with a %XLIB-F-PIXTOOBIG error.  You really expect them 
>to understand BadValue???

No, I don't.  I'm in total agreement with you.  However, the Xlib error
reporting (or what passes for error reporting in Xlib) is a separate issue.
All I can say is that's what you get when you rely on a crowd of propeller-
headed dweebs at a university for your software.  Product-quality software from
universities is VERY rare, and X ain't even close.

--PSW

>If we did that, they'd just be right back on the phone again when they
>tried to set the display for the application to some PC or other X
>server that had a lower pixmap size limit.  And then we'd have you
>back here in this conference bellyacheing about why did we tell
>customers the specific limits, thereby giving them the false
>impression that they can rely on the figures. 

Let the people on the phones express opinions about what the customers 
will call about.  I'm damned tired of having to explain display 
memory, X architecture, error codes, "propellor headed dweebs", etc.
every time someone calls with pixmap failure.  Documenting the limits
of each server/graphics combination would allow us to just say "see
page n.  It's documented." Instead we have to give a course in X and
graphics over the phone and listen to their abuse about the lack of 
interoperability even among DEC platforms.  It takes too much time
away from problems that can't be documented away. 

Part of the problem is that X conveniently says "don't plan on getting a 
pixmap" without providing a reasonable alternative or workaround.  
That we hide behind X architecture's inadequate treatment of the 
subject is what makes it difficult to justify to customers.  If we 
laid out the specifications for our products at least they'd realize 
the limits exist.  Now they don't find out until one of their 
customers complains that their software doesn't work.

If you don't want to document the specifications then why don't you 
write a section on programming workarounds to pixmap create failure?  
Pointing our finger at X does not solve the customer's problem!

    Part of the problem here is that PIXMAP's are so damned important and
    we are insisting in the peverse notion that not being able to handle
    the lack of sufficient PIXMAP resources is a bug in the USERS code.
    
    I've got a application that I used for testing UISX, it is a PC board
    layout editor.  A layout can put up on the order of 100,000 vectors or
    more on the screen.  The recomputation, paging and drawing time to 
    redraw these vectors makes the application unusable if this were
    required for an expose event - so client-side backing store is
    required.  It needs a PIXMAP backing store.  I have (many) applications
    that use fill patterns, fill patterns require a PIXMAP, no PIXMAP,
    no pattern, no go.
    
    We should make PIXMAP's work so well that a PIXMAP allocation failure
    should be so rare most users never see one in there entire lifetime.
    
    

>On the futility of documenting the amount of pixmap space available:

Lets say that a given server has 5000x5000 available for pixmaps.  How much
can the application use?  It could very easily get ZERO!!  Why?  The USER
determines how much is available to any given application based on what
applications he runs and in what order.  There is no way to provide any
reasonable estimate of the amount of server storage available to any given
application, so it is ridiculous to even attempt to do so.

(Think of it this way, what number would you use as the minimum amount of
physical memory available to an application running on a VAX with 512 meg
of memory?  512 meg?  256 meg?  64 meg?  I will refuse to accept any answer
less than 32 meg of physical memory as the absolute minimum, but I get to
decide on the number of processes...)

>On the futility of the server always providing even poor performance for
>an unbounded amount of backing store:

If you want an unlimited amount of backing store, use UIS.  Of course, UIS
had a history of getting hung when this unlimited backing store exceeded the
size of the pagefile.

UIS and X use different trade offs.  UIS assumed that it could somehow manage
to hide the hardware realities from the application.  What that doesn't address
is what happens when the applications start using these `free' resources
without bound.  On the other hand, X doesn't attempt to hide the limitations
of the hardware from the application.  While it is theorectically possible to
use a low end hardware platform for X, the reality is that X eliminates a few
platforms immediately (the �VAX I, for example) that sort of ran UIS.  However,
if we had the applications for UIS that we have today for X, you would certainly
find that those platforms were totally unusable.  In fact, I don't think that
any of the supported UIS platforms are able to support what is a normal workload
for a windowing system today.

There are two solutions:

1. the applications simply stop working when resources are depleted and so
   the user buys bigger systems

2. tha applications deal with the lack of resources as best they can and the
   user buys bigger and/or faster systems to maintain adaquate performance

The third solution that everyone wants, isn't possible:

3. the server provides infinite resources, or when infinite resources aren't
   available, cuts the PO, schedules the hardware delivery, and upgrades the
   system, all without noticable service interruption

As a person who has implemented a server, I have found this thread very
interresting.  I am also very glad that I opted to use the CFB/MFB code.
I would make 3 observations:

1) Restricting pixmaps to live in a frame buffer (and I mean ``frame
buffer'' in the restricted sense of the memory that directly used by
the screen hardware for display, as opposed to general memory used to
store other server resources) is probably poor server design.  This is
because the offscreen portion of the frame buffer is likely to always
be smaller than that desired by applications.  I personally would
expect, for example, that a competant server would have space for a
MINIMUM of 3 or 4 large pixmaps equal in size to the root window in
addition to the myriad of smaller pixmaps used for other purposes.
Few frame buffers have this kind of offscreen memory available and
unfortunately this makes GPXish display hardware a poor impedance
match for X in many cases. 

2) I think that users/developers can and do understand that pixmap
storage is a limited resource, just as they understand that CPU time,
I/O bandwidth, memory, etc. are limited resources.  But they have an
expectation that a server will provide ``enough'' of these resources
to be usefull.  For example, I think most (but not all ;-) )
developers would understand if their attempt to allocate a 30000 x
30000 pixmap failed.  On the other hand, I'd bet that many developers
would demur at not being able to create 1 pixmap the size of the root
window, especially since any mfb/cfb based server would have no
problem with this. 

3) As PSW points out, a program that blithely attempts to allocate
large pixmaps and urps when it fails is of questionable correctness.
Application developers, however, are free to define the minimum level
of resources required to use their product.  If customers find that,
considering this, the code runs on all common servers EXCEPT Digital
ones, you won't be making sales by complaining that the application
code is broke! 

RE -2:

You missed the point.  The current gpx server allows multiple 1024x864 
pixmaps by paging them to ram.  The only implication of lots of 
pixmaps is performance.  The problem is that no pixmap greater than 
1024x864 can ever be created even if it is a fresh boot with no other 
users.  I don't believe the announcement of SPX justifies excluding 
thousands of GPX's in the field from working.  There are many more 
customers using the old systems than there will be using new ones.  

"Buy new or die" may be an effective short term philosophy, but it 
certainly won't gain customer loyalty, approval, or reorders when they 
have another alternative.

RE -1:
I agree that in most situations 3 or 4 root windows would be enough, 
but some applications need 1 pixmap that is 3 or 4 times the size of 
the root.  That's what can't be done on GPX.

    Not to defend UIS, since I no longer work for them - but .16 is a
    little off base.  Don't try to paper over a problem with DECwindows/X11
    by taking pot shots.  The reasons for doing DECwindows/X11 had
    *nothing* to do with the relative performance of UIS to X11 or the
    ease of tuning - if it were, X11 would have lost.  DECwindows provides
    us flexibility and compatability that UIS did not.  DECwindows allows
    integration with Unix and MS-DOS that UIS did not.  And we pay a
    price for this.  Believe me, I just spent the last 6 months
    implementing UIS on top of DECwindows and VWS *is* more efficient
    and faster than DECwindows on the monochrome and GPX platforms (the
    only things its written for).  VWS more closely matches the VMS
    environment it was written for.
    
>If you want an unlimited amount of backing store, use UIS.  Of course, UIS
>had a history of getting hung when this unlimited backing store exceeded the
>size of the pagefile.
    
    This isn't an inherent flaw in UIS, just simply a resource problem
    that was never addressed before the group left to do DECwindows.  And
    even with the current badness in the way it handles this condition -
    it can be corrected by tuning the system.  In addition, the need for
    unlimited backing store *isn't* a good reason to use UIS - fix the
    DECwindows problem!
    
>UIS and X use different trade offs.  UIS assumed that it could somehow manage
>to hide the hardware realities from the application.  What that doesn't address
>is what happens when the applications start using these `free' resources
>without bound.  On the other hand, X doesn't attempt to hide the limitations
    
    Indeed, UIS does attempt to "hide" hardware differences, and does a
    damn good job.  At this point I know of no other software than UISX
    that can successfully span Visual types which are all portions of the
    same virtual worksurface.  UIS *didn't* hide resource problems - if
    there weren't resources UIS is *supposed* to signal an error (not
    crash or hang :-) and the correction (again) is system tuning.
    
>find that those platforms were totally unusable.  In fact, I don't think that
>any of the supported UIS platforms are able to support what is a normal workload
>for a windowing system today.
    
    You *are* joking.  Evidence from the field is that you need nearly
    twice the CPU and twice the memory to support the same GKS application.
    I have prototype applications for UIS that look remarkably like the OOTB
    applications and fileview for UIS that work as well or better. The only
    VAX based systems that UIS is not supported on is the SPX and Firefox
    systems.
    
    VWS does a reasonable job for the "traditional" workstation market it
    was written for.  It does not have the bells and whistles that are
    needed for the "desktop" market that DECwindows is targeted for.  It
    *does* have the horsepower for the workload.  It is VMS only and very,
    very proprietary - and *this* is what disqualifies it as a windowing
    system.
    

re:.-1

I'm not taking potshots at UIS.  I'm just making observations, perhaps
someone incorrect, but none the less based on the experience of most of
the people in my group.  About 8 of us use VS2000's with 14meg but our
PHYSICAL memory usage for each member of the group when using DECwindows
is on the order of 30-50meg and we at times draw on 5-10 VUPs.
So assuming that UIS were twice as efficient as X in both memory and
CPU, the applications would not run as well on UIS as they do on X.
Obviously, I'm not making an apples to apples comparison; not only are
we using vs2000's, but we're also making heavy use of two VAX6240's.

However, even if UIS had been modified to operate over the network
(something that was consider feasible), UIS would still be at a
disadvantage because it would have had to keep the backing store on
the server instead of relying on the applications to recreate it.
Most applications, not all, but most are able to recreate a window
with very minimal storage, while a UIS server's storage requirements
would be proportional to the size of the window, not matter how simple
the image.

The bottom line is that there is a trade off and X and UIS chose
opposite sides.

I wonder if the thing that bothers some people is that UIS had to
fight like the devil to get good performance on limited resource systems
in order to provide a good environment for applications and upping
the mnimum resources was not an option.

On the other hand, X doesn't have to address the resource problem since
it punts it back to the application, but X also set a minimum system
size that was twice what UIS had.  And in the end, the applicatons
are demanding and getting even more hardware resources.

So, by shifting the burden elsewhere and by being rather less efficient
in the use of resources, greedy X has achieved fame and fortune while
virtuous UIS has faded into the background.

I really do understand the feeling: I worked hard on the PRO and had
to endure its failure against the inferior MS-DOS.

    This isn't really the place to discuss why UIS *hasn't* faded (except
    within DEC itself).  Why?  Bells and whistles only sell when the
    applications are there.  But let's just stick to the prolems at hand
    rather than draw tenuous at best conclusions from a windowing system
    that is *still* in the top 10 list after 3 years of non-development.
    
    The memory demand for backing store is a predictable resource, the
    memory demand for client-side backing store is unbounded and
    unpredictable.  Backing store need not be a binary proposition on X11
    or UIS *some* applications (such as menu's) are easily refreshed...
    others are more difficult - even text based output like spreadsheets
    presents a challenge and entails a bit of overhead.  However, backing
    store as a "hint" is useless.  Considering one of the biggest demands
    I heard from the Mill regarding X10 was that it needed backing store -
    I can't see how we've gotten to this point.  And having forced *many*
    applications to do client-based PIXMAP backing store, we should at
    least try to make this resource as close to infinite as possible.
    PIXMAP's larger than the screen?  Well, since we've painted ourselves
    into following whatever defacto standards come along -- we'd
    better bite the bullet.  And if we have to allow segmented PIXMAP's
    in the server to accomplish this, then let's go all the way and try
    to address these other problems.