Conference bulova::decw_jan-89_to_nov-90

2319.0. "Prob on VAXstation (decwindows) Decstation OK." by MILKWY::CONTINI () Wed Feb 21 1990 09:29

    We are trying to port a PC application to the DECstation and VAXstation
    and have run into a road block on the VAXstation.   Does anyone out
    there have a solution to this problem.
    
    First some history on this. 
    
    XACT was designed with the PC target in mind. To provide sufficient
    performance in the very limited PC environment, XACT was designed with
    the basic assumption that it had available a virtually infinite drawing
    "canvas" on which to work.  It then "draws" all of the  device and
    manipulates that large image in interacting with the user.  To that
    end, it makes system calls for memory and drawing functions for that
    large drawing area.  If it cannot get enough memory for that drawing
    area, it cannot continue:  it dies.

    VAXstation implementation:  VAXstations contain either a GPX or SPX
    graphics co-processor to speed up screen operations.  This co-processor
    has a fixed "frame buffer" size, related to the type of screen, etc. 
    The Xwindows  implementation for this machine has a correspondingly
    "fixed" drawing  area, roughly equivalent to the "frame buffer"
    associated with the graphics co-processor.  All of this works well,
    under most circumstances.

    Problem:  XACT ported to the VAXstation makes system calls assuming
    this  large "canvas" or drawing area is available.  On the VAXstation,
    it cannot get sufficient memory to begin its drawing operations.  IT
    DIES. On the DECstation (MIPS based/Ultrix) the Xwindows graphics is
    implementation entirely in software and does not have any notion of a
    limit in its drawing area.  This allows XACT to perform its functions
    correctly.  In a word, IT WORKS.

    Alternatives:  We discussed three possible alternatives.

    1.  Complete re-write of XACT such that it does not require all of the
    device to be "drawn" at any one time, or it is drawn in a different
    way, not  requiring large drawing areas.

    	PROBLEM:  Complete re-write is a VERY long term project, estimate
    to be several man-years of effort.

    2.  Create a "partial part" view according to what size drawing area is
    available.  User could operate in that limited space, but attempting to
    move out of that area would require a complete screen re-draw.  While
    this would technically be feasible, our thinking is that it would be
    virtually un-usable,  primarily for performance and visual continuity
    reasons.

    3.  Somehow "fake" Xwindows into allowing XACT to "draw" the whole part 
    without really drawing it into the hardware limited frame buffer.

    	PROBLEM:  Techniques for doing this are not understood, nor is it
    necessarily technically feasible.  This may be a "pipe		 
    dream" and would probably be very difficult to create  a
    good performance interface between XACT and the 		 
    hardware/Xwindows code.  This is a minimum of 6 months		 
    additional work, and is felt to be a very high technical		 
    risk.

    HELP !!!!!!

    Maurizio Contini

See 2100.*.  I think you just have to exclude all the vaxes.

    Thank you for the reference Bruce.  I reviewed note 2100.* but could
    not find a solution/workaround.  
    
    Not to use vaxes is not an option we have since this software will be
    dsitributed within the company, and it is my understanding that we have
    a high number of vaxes installed.
    
    mc

   In X, you have to be able to correctly assume that your request for server
resources (in this case, a very big pixmap) will fail.  In fact, you should
really assume it will in your code, and just be very very happy if it
succeeds.  (Just like save-unders/backing store, or display post-script...)

   If your application requires that amount of server resources, it isn't
a correct X application.  You're just lucky it does work on the other platforms.
It doesn't have to, and any number of things could happen to cause the
resources not to be available on the servers for the DECstations.

   Looks like you've got some serious redesign ahead of you, sorry!

					-mjg

Well, yes, you have to be prepared for resource allocation problems in
order to handle them gracefully.  That's just good software engineering.

Don't let that be confused with providing a competitive environment,
however.  If our customers see that their applications work on other X
servers, and not on VAXes, they're not going to say: "Gee, I guess I
better fix my program so it runs on a VAX."

They're going to say:  "I guess we buy someone else's workstations."

re -2:  So it is the application's responsibility, but none of the 
Xophiles have yet proposed a reasonable way to do it in X.  That makes 
it an X problem that leaves Vaxes out in the cold!

Still_waiting_for_just_how_to_do_the_magic

RE: .5

>That makes 
>it an X problem that leaves Vaxes out in the cold!

In this case, yes.

--PSW