Patent Application
20060103654
Before the advent of personal computers, large, expensive, mainframe computers dominated the landscape of digital computing. Each mainframe computer typically served multiple users that interfaced with the mainframe computer through terminals that had a display device, such as a cathode-ray tube (CRT) screen, and an input device, such as a keyboard. Such terminals are nowadays commonly referred to as 20 “dumb terminals” because they performed only basic display and input functions and had at most some rudimental digital processing capability that was not sufficient for independently running software applications.
The display provided by the “ldumb” terminals was character-based, i.e., the display comprised alphanumeric letters. During operation, the user input entered through the keyboard is transmitted to the mainframe computer, and the output in the form of letters and numbers was sent to the terminal and displayed on its screen for viewing by the user.
In the beginning of the age of personal computers, personal computers were small machines with limited computing power and resources. They typically operated as individual units in the sense that each computer had its own operating system, ran its own software applications, received user input from its own input devices, and sent the user interface to its own CRT for display. In the early days, the PC interface was, like the dumb terminals for mainframes, based on alphanumeric characters. Graphic user interface, however, soon replaced the character-based display and became the norm for software applications designed to run on personal computers and networks based on personal computers.
Over time, the computing power of personal computers in terms of both hardware capabilities and software sophistication has increased tremendously. Many personal computers nowadays possess computing power and resources rivaling some small mainframe computers in the past. At the same time, networking of personal computers has become prevalent at workplaces. Due to these developments, there arises the possibility to run a software application on a server computer, which may be a network server, with the user running the application sitting at a remote client computer connected to the server computer through a network. In the capacity of a remote terminal, the client computer functions like a dumb terminal of the old days in that it forwards the user input to the server computer for processing and displays the user interface received from the server computer on its screen for viewing by the user in a proposed scheme for remote terminal service, the client computer functions entirely in a slave mode in that the server computer tells the client computer exactly what to put on the user interface screen.
There are, however, many differences between a client computer functioning as a remote terminal and a dumb terminal of the past. One of the major differences is that the user interface has become much more sophisticated. A user interface screen on current personal computers is graphics-oriented and includes various graphic components such as text strings, icons, windows, etc. To enable the remote terminal to display the interface screen, the terminal server has to pass data regarding each graphic component, such as their bitmaps and coordinates, to the client computer. Because the remote terminal is connected to the server computer through a network, the data transmission can be quite time consuming, and the efficient use of the network bandwidth has to be considered in designing the remote terminal service system. If the amount of graphics data that have to be sent to the remote terminal is large, the network data transmission can become a bottleneck and negatively impacts the display performance of the remote terminal.
The efficient use of network bandwidth in a remote terminal session is especially import for displaying characters. An interface screen may contain many text strings each having multiple characters. Generally, each character has a Unicode designation, and the graphics engine of the client computer can use the Unicode designation and the font information of a character to render it for display. Thus, the server computer may instruct the client computer to display a text string by sending only the Unicode designations and font of the characters in the string to the client computer. This approach, however, does not work in many cases. In the remote terminal server-client scheme, the server and the client may be on different operating system platforms, and the client may not even have the set of fonts that the server has. As a result, the same characters may be rendered differently by the different graphics engines, and the remote terminal may display characters in a form different from what is intended by the server. One solution to avoid this problem is to send glyphs for the characters to be displayed to the terminal client. Each glyph contains the bitmap representation of a character of a given font and size. Sending the glyphs across the network, however, can be quite expensive. A single glyph may be over 256 bytes long. When the user interface screen to be displayed at the remote terminal contains many characters, sending the glyphs to the terminal client may take up a significant portion of network bandwidth.
In view of the foregoing, the present invention provides a method and system of caching graphic representation data of glyphs to be displayed by a remote terminal that significantly reduces the amount of glyph data that have to be transmitted through the network to the remote terminal. In accordance with the invention, the glyph data caching is performed on the level of “fragments,” each fragment containing a plurality of glyphs. A fragment may represent, for example, icon text, menu text, a text string in a document, etc., to be drawn on the remote terminal. In a typical remote terminal session, many fragments are drawn on the remote terminal multiple times due to screen refresh or other reasons, and caching those fragments avoids the need to resend all the glyph data for the fragments across the network to the remote terminal.
To provide fragment caching, the terminal client stores a fragment cache for storing data representing fragments. The client also stores glyph caches for caching the bitmap representations of individual glyphs. The fragment cache and the glyph caches are maintained by a terminal server module of the server computer. Each entry in the fragment cache represents a fragment and contains data indicating where the glyph data for the glyphs in the fragment are stored in the glyph caches. When the remote terminal server receives a request to display a fragment on the remote terminal, it checks whether the fragment has been cached. If so, the terminal server sends the terminal client a fragment index that identifies the fragment cache entry for the fragment. The client then uses the data in that fragment cache entry to retrieve the data for the glyphs of the fragment from the glyph caches and render them on the display screen.
Additional features and advantages of the invention will be made apparent from the following detailed description of illustrative embodiments, which proceeds with reference to the accompanying figures.
While the appended claims set forth the features of the present invention with particularity, the invention, together with its-objects and advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which:
Turning to the drawings, wherein like reference numerals refer to like elements, the invention is illustrated as being implemented in a suitable computing environment. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a personal computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multi-processor systems, microprocessor based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
With reference to
The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical disk drive interface 34, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the personal computer 20. Although the exemplary environment described herein employs a hard disk 60, a removable magnetic disk 29, and a removable optical disk 31, it will be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories, read only memories, and the like may also be used in the exemplary operating environment.
A number of program modules may be stored on the hard disk 60, magnetic disk 29, optical disk 31, ROM 24 or RAM 25, including an operating system 35, one or more applications programs 36, other program modules 37, and program data 38. A user may enter commands and information into the personal computer 20 through input devices such as a keyboard 40 and a pointing device 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 21 through a serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the monitor, personal computers typically include other peripheral output devices, not shown, such as speakers and printers.
The personal computer 20 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 49. The remote computer 49 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the personal computer 20, although only a memory storage device 50 has been illustrated in
When used in a LAN networking environment, the personal computer 20 is connected to the local network 51 through a network interface or adapter 53. When used in a WAN networking environment, the person computer 20 typically includes a modem 54 or other means for establishing communications over the WAN 52. The modem 54, which may be internal or external, is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules depicted relative to the personal computer 20, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
In the description that follows, the invention will be described with reference to acts and symbolic representations of operations that are performed by one or more computers, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processing unit of the computer of electrical signals representing data in a structured form. This manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the computer in a manner well understood by those skilled in the art. The data structures where data is maintained are physical locations of the memory that have particular properties defined by the format of the data. However; while the invention is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operation described hereinafter may also be implemented in hardware.
Referring now to
The client computer 72 functions as a “remote terminal” in the sense that the user actually works with the operating system and/or software applications residing on the server computer 70, and the client computer provides the input and output functionality for the server computer at a location remote from the server computer. The server computer 70 tells the client computer 72 what to display on the screen 78, and the input entered by the user through the client computer is transmitted to the server computer for processing thereby. This arrangement enables the user to use the operating system and application features and resources of the server computer 70 while placing minimal requirements on the capabilities and resources of the client computer 72.
In the embodiment illustrated in
As described above, to ensure that the characters shown on the display screen 78 of the client computer have the shapes and forms intended by the server computer, the display driver 90 has to provide glyph data for each character to be displayed to the client computer. A glyph 94, as shown in
The present invention provides an efficient way to send glyph-related data to the client computer 72 for displaying characters on the display screen 78. Specifically, the amount of glyph data that have to be sent to the client computer is significantly reduced by the use of caching for individual glyphs and fragments in accordance with the invention. A “fragment” as used herein means a plurality of glyphs representing the characters in a text string. The present invention takes advantage of the fact that many drawing requests for displaying characters are directed to fragments rather than individual characters. During a terminal service session, some text strings, which may be desktop icon text, menu text, etc., are to be drawn on the display screen more than once due to screen refresh or other reasons. The glyph data for the text string does not have to be sent again to the terminal client 88 if they are already cached in the memory of the client computer.
By way of example,
As another example of the display fragments,
It will be appreciated, however, there are also many instances where the graphics engine will request the terminal server 86 to draw a single character at a time. For example, 10 when the user types in new text using the keyboard of the client computer, each keystroke is sent to the server computer. The word processing application then responds through the graphics engine with a drawing request to draw the character corresponding to the keystroke on the display screen.
Turning now to
To identify the various glyphs for the purpose of caching individual glyphs, each glyph is assigned a glyph key that uniquely identifies the glyph. In a preferred embodiment, each glyph contains a glyph index that is 32-bit long. The glyph index is assigned by the graphics engine 84, and its value is unique during the lifetime of the running system. Each glyph also includes a global font ID that is also 32-bit long and identifies the font of the glyph. As shown in
To provide glyph caching, the client computer 72 stores one or more glyph caches 130. Although the glyph caches 130 are stored in the local memory of the client computer 72, they are maintained by the server computer 70, i.e., the server computer tells the client computer where to store data for individual glyphs in the glyph caches. In a preferred embodiment, the client computer 72 has ten (10) glyph caches 130 stored thereon. Each glyph cache has a cache ID 132 numbered 0 through 9, and 256 entries (which are called “cells”) each storing the bitmap data for one glyph. The glyphs in each glyph cache are identified by their respective cell indices 134. Each cell index is an 8-bit value to cover the range of 0 to 255.
The glyph caches 130 preferably have different cell lengths for storing glyphs of different sizes. This enables efficient use of the memory space of the client computer. For example, a glyph cache with a cell size of 4 bytes can be used to store a small glyph, while a cache with a cell size of 256 bytes can be used to store a much larger glyph. The glyph-cache sizes preferably are configurable, such as by using a registry of the client computer, to optimize the use of the memory space. The size of the largest glyph of a font determines which glyph cache will be used to store the glyphs of that font. Thus, all glyphs of the same font are stored in the same glyph cache, but one glyph cache can hold glyphs of multiple fonts.
In accordance with an aspect of the invention, the terminal server 86 maintains the glyph caches 130 stored by the terminal client. To keep track of which glyphs are in the glyph caches, the terminal server stores a glyph look-up table 138. Each entry in the glyph look-up 138 table corresponds to one cached glyph and stores the glyph key 96 of the glyph and the cell ID 132 and cell index 134 of the glyph cache cell in which the glyph data are stored.
On the other hand, if the server cannot find the glyph index in the look-up table, the glyph has not been cached. In this case, it assigns a cache ID and cache-cell index value to the glyph (step 154), and stores the glyph key, cache ID, and cell index in an entry of the look-up table (step 156). The server then sends the glyph bitmap and its cache ID and cell index across the network to the terminal client (step 158). The client stores the received glyph bitmap in the glyph cache and cell specified by the terminal server (step 160). The client then displays the character on the display screen (step 152). Because it is the terminal server that determines where to store each glyph in the glyph caches, it can keep track of which glyphs are cached and where to find them later.
Returning now to
Like the glyph caches 130, the fragment cache 120 is also maintained by the terminal server 86. In order to keep track of the cached fragments, each fragment is assigned a fragment key that uniquely identifies it. The terminal sever 86 stores a fragment look-up table 176 that contains the fragment keys 178 and fragment indices 172 of the fragments that are cached by the client in the fragment cache 120.
The fragment key may be generated, for example, by applying a cryptographic checksum function to the fragment glyph array, and the resultant hash value is used as the fragment key. In a preferred embodiment, a very efficient cryptographic checksum technique is used to generate a 64-bit fragment key. Instead of performing a mod(M) operation as required by conventional cryptographic techniques, this cryptographic checksum technique generates the checksum by performing a relatively simple series of elementary register operations including mod 2n multiplications, order manipulations, and additions. This efficient cryptographic checksum technique is described in detail in copending U.S. patent application Ser. Nos. ______ and ______, entitled “A SIMPLE TECHNIQUE FOR IMPLEMENTING A CRYPTOGRAPHIC PRIMITIVE USING ELEMENTARY REGISTER OPERATIONS” and “A TECHNIQUE FOR PRODUCING A PARAMETER, SUCH AS A CHECKSUM, THROUGH A PRIMITIVE THAT USES ELEMENTARY REGISTER OPERATIONS,” respectively, and both by Ramarathnam Venkatesan and Mariusz H. Jakubowski, which are hereby incorporated by reference.
Turning now to
On the other hand, if the fragment is not yet in the fragment cache, the terminal server sends to the terminal client the fragment glyph array and a fragment index identifying where the array is to be stored in the fragment cache (step 204). The terminal client stores the fragment glyph array in the entry of fragment cache corresponding to the fragment index (step 206). The terminal client then retrieves the glyph data for the fragment from the glyph caches (step 200) and displays the glyphs (step 202).
The format of a fragment glyph array may depend on various parameters.
ft a preferred embodiment, the fragment caching is applied to text strings that have 3 to 256 characters of a same font. Other ranges may also be used. The lower limit is imposed because a short string, such as one with only two characters, can be handled efficiently with the glyph-caching scheme without the need to utilize the fragment caching mechanism. The upper limit is imposed to prevent the size of the fragment cache entries from becoming too large. A text string with a length exceeding the upper limit can be broken into two or more shorter fragments which can fit in the entries of the fragment cache. In view of the foregoing, it can be seen that the present invention provides an effective way to improve the performance of a remote terminal in displaying character strings by caching glyph data on the basis of text fragments. This fragment-caching scheme significantly reduces the amount of glyph data that have to be transmitted across the network to the terminal client for display on the remote terminal. The fragment caching is built upon a glyph-caching scheme for individual glyphs, and the fragment glyph arrays in the fragment cache store the glyph-cache cell indices rather than the glyph bitmaps of the glyphs in the cached fragments. This arrangement minimizes the sizes of the fragment arrays in the fragment cache, resulting in efficient use of the memory of the client computer functioning as the remote terminal.
In view of the many possible embodiments to which the principles of this invention may be applied, it should be recognized that the embodiment described herein with respect to the drawing figures is meant to be illustrative only and should not be taken as limiting the scope of invention. For example, those of skill in the art will recognize that the elements of the illustrated embodiment shown in software may be implemented in hardware and vice versa or that the illustrated embodiment can be modified in arrangement and detail without departing from the spirit of the invention. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof
This is a continuation of and claims priority to U.S. patent application Ser. No. 10/675,480 filed on Sep. 30, 2003 entitled “SYSTEM AND METHOD OF CACHING GLYPHS FOR DISPLAY BY A REMOTE TERMINAL System and Method For Caching Glyphs For Display By A Remote Terminal” by inventors Joy Chik, John E. Parsons, and Brian M. Tallman.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10675480 | Sep 2003 | US |
| Child | 11275624 | Jan 2006 | US |
