T.R | Title | User | Personal Name | Date | Lines |
---|
2100.1 | More offscreen memory on SPX | STAR::BMATTHEWS | | Mon Jan 22 1990 12:40 | 8 |
| 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
|
2100.2 | still limited? | TOOLEY::B_WACKER | | Mon Jan 22 1990 17:52 | 13 |
| >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.
|
2100.3 | Yes large pixmaps with SPX | STAR::BMATTHEWS | | Tue Jan 23 1990 08:37 | 6 |
| 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
|
2100.4 | Limit still there temporarily | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Mon Jan 29 1990 12:35 | 7 |
| 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
|
2100.5 | I'd settle for SLOW instead of NO...:-) | SX4GTO::KIMBALL | You're soaking in it... | Mon Feb 05 1990 19:56 | 11 |
| 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
|
2100.6 | It's harder than it seems
| DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Wed Feb 07 1990 10:07 | 15 |
| 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
|
2100.7 | | SITBUL::KLEINSORGE | BFM | Wed Feb 07 1990 12:13 | 14 |
|
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.
|
2100.8 | Customers expect it to work first | TOOLEY::B_WACKER | | Thu Feb 08 1990 19:53 | 48 |
| 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
|
2100.9 | | XUI::VANNOY | Jake VanNoy | Fri Feb 09 1990 09:33 | 6 |
| 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.
|
2100.10 | Careful how many customers you freeze | TOOLEY::B_WACKER | | Fri Feb 09 1990 11:15 | 17 |
| >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?
|
2100.11 | | PSW::WINALSKI | Careful with that VAX, Eugene | Fri Feb 09 1990 17:50 | 12 |
| 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
|
2100.12 | Pixmap size is a lot more important than relative humidity! | TOOLEY::B_WACKER | | Fri Feb 09 1990 19:08 | 47 |
| >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
|
2100.13 | | PSW::WINALSKI | Careful with that VAX, Eugene | Sat Feb 10 1990 18:11 | 30 |
| 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
|
2100.14 | Then solve the problem another way | TOOLEY::B_WACKER | | Mon Feb 12 1990 11:23 | 28 |
| >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!
|
2100.15 | | STAR::KLEINSORGE | BFM | Mon Feb 12 1990 11:54 | 17 |
| 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.
|
2100.16 | | CVG::PETTENGILL | mulp | Mon Feb 12 1990 19:17 | 47 |
| >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
|
2100.17 | FWIW, IMHO | VINO::WITHROW | Mass. recall petitions available here! | Mon Feb 12 1990 20:12 | 35 |
| 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!
|
2100.18 | How many thousand GPX's prematurely extinct? | TOOLEY::B_WACKER | | Tue Feb 13 1990 10:22 | 18 |
| 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.
|
2100.19 | | STAR::KLEINSORGE | Fred Kleinsorge, VMS Development | Tue Feb 13 1990 10:26 | 54 |
| 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.
|
2100.20 | X isn't better, it's just successful, because it took the easy way out | CVG::PETTENGILL | mulp | Wed Feb 14 1990 01:50 | 40 |
| 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.
|
2100.21 | | STAR::KLEINSORGE | Fred Kleinsorge, VMS Development | Wed Feb 14 1990 09:53 | 23 |
| 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.
|