Service Manuals, User Guides, Schematic Diagrams or docs for : xerox sdd memos_1977 19771107_Scrolling_And_Panning

<< Back | Home

Most service manuals and schematics are PDF files, so You will need Adobre Acrobat Reader to view : Acrobat Download Some of the files are DjVu format. Readers and resources available here : DjVu Resources
For the compressed files, most common are zip and rar. Please, extract files with Your favorite compression software ( WinZip, WinRAR ... ) before viewing. If a document has multiple parts, You should download all, before extracting.
Good luck. Repair on Your own risk. Make sure You know what You are doing.




Image preview - the first page of the document
19771107_Scrolling_And_Panning


>> Download 19771107_Scrolling_And_Panning documenatation <<

Text preview - extract from the document
              Inter-Office Memorandum

    To        Tim Townsend                              Date            7 November 1977


    From      Bob Metcalfe, Charles Simonyi             Location        Palo Alto


    Subject   Scrolling and Panning                     Organization    SDD/~R5~ SDD ARCHIVES
                                                                         I have read and understood
XEROX                                                                   Pages          To
                                                                                      -----
                                                                       Reviewer
                                                                               -----' ----  Date
                                                                       # of Pages  Ref .,11S(')D- ~" 7
    This memo responds to your request for a characterization of the performance implications
    of horizontal scrolling, now called panning. In this memo we use the term scrolling to mean
    vertical movement and panning to mean horizontal movement, both of a page image on a
    display. The purpose of scrolling and panning is, of course, to enable viewing of a page
    which is too large for the display, perhaps because a larger, more legible font has been
    employed for user comfort.

    In your request you mentioned what we now call an EDP page consisting of 60 lines of 132
    fixed pitch characters in a single font. Our response treats the more general Diamond page
    case first and then examines possible performance improvements for the EDP case.

    There are three page representations relevant to this discussion: (1) piece tables, (2) line
    descriptions, and (3) bit maps. Page edits are performed on piece tables. Piece tables are
    converted to line descriptions enroute to various other representations, one of which is the
    bit map maintained for the display.

    Given a new piece table or one upon which an edit has just been performed, we estimate
    that 1 second of DO processing will be required to compute the bit map viewed by a user on
    his display, just as specified in the requirements. It should be noted that a lower delay will
    be perceived because the bit map is displayed as it is updated.

    Because scrolling and panning imply no modification of the piece table and often keep
    much of the same bit map in view, recomputing the bit map can frequently and to great
    advantage be avoided using the so-called BITBLT operation to move the bit map unaltered.
    We estimate that the display can be updated in .1 seconds when a scroll or pan operation
    keeps the display's view inside the existing bit map. Because memory is expensive, however,
    the amount of bit map maintained is only as large as that viewed. Therefore, a scroll or pan
    operation commonly results in a view which requires that new bit map be computed. In the
    worst case an entirely new bit map is required. In the common case only a small portion of
    the existing bit map is scrolled or panned out of view and only a comparably small segment
    of new bit map need be computed. Here is where the difference between scrolling and
    panning is felt.

    Owing to the left-to-right and top-to-bottom nature of pages and owing to our efficient
    representation of pages which exploits this nature, the bit map recomputations of
    incremental scrolling are small relative to complete bit map recomputation. We estimate
    that scrolling updates require between .1 seconds and 1 second, depending of course on the
    fraction of the viewed page which remains in view after scrolling. Panning, however, does
    not benefit as does scrolling from the nature of pages and our representation of them.
    Using current Diamond algorithms, as the view of a page moves to the right or left, past the
    maintained bit map, total recomputation of the bit map is required.

    Four alternatives have been considered for improving panning response. The first is to save
    the state of bit map computations at their boundaries so that they can be extended left and
Scrolling and Panning                                                                         2


right incrementally.    We now judge this alternative to be impractical.

A second alternative is to compute and maintain a large bit map even for a small display so
that panning would require no bit map recomputation, only BITBLT. Scrolling cannot be
handled this way because documents grow indefinitely long; a reasonable upper bound on
width, however, is feasible. This is an attractive alternative except for the observation that a
larger display is likely to be inexpensive relative to the bit map memory required.

A third alternative is to maintain, rather than a complete bit map, a complete line
description of pages to be viewed on a small display. A line description requires only 30%
of the computation required for a piece table to generate bit map and occupies between 25%
and 50% of the space of its equivalent bit map. By maintaining page line descriptions,
panning updates could be reduced to .3 seconds from 1 second at half the memory cost of a
full page bit map. This alternative looks attractive, but requires further study.

A fourth alternative is to adopt a page representation specific to the EDP page. By
removing font and spacing generality, complete bit map recomputations could, we estimate,
be reduced straightforwardly to .2 seconds. Some penalty would of course be paid in
developing this special representation, in coding various conversions, and in document load
and store conversion delays.

Yet another alternative is to do nothing and have panning take 1 second to complete. This
speed may prove to be acceptable. especially because a lower delay may be perceived.

It is our conclusion that panning is feasible and can be made to perform acceptably.     We
recommend further study, of course, but suggest at this time that wider displays be employed
or, if not, that the line description approach in the third alternative be pursued.



c:   David Liddle
     Wendell Shultz
     Jerry Szelong



◦ Jabse Service Manual Search 2024 ◦ Jabse PravopisonTap.bg ◦ Other service manual resources online : FixyaeServiceinfo