This invention relates to a method and system for controlling rendering of graphical data for remote display.

Some graphical applications (or their underlying network protocols) make use of a client-server architecture whereby graphical data, comprising a series of frames each representing an image, are rendered (i.e. generated) on a server computer but transported over a network for display on a remote client computer. One example of the server-client model occurs in the display of two-dimensional (2D) images derived from a three-dimension (3D) model, such as a 3D visualisation of seismic and other geophysical data. Such 3D visualisations generate huge datasets which are difficult to distribute in an efficient manner, particularly over data networks. To address this difficulty, 2D images are rendered from the 3D visualisation at the server for distribution to one or more remote clients where the 2D images can be viewed.

There are a number of flow-control methods aimed at matching data rates in one, upstream part of a network to the capacity to handle the data at another, downstream part of the network. These known flow-control methods follow one of two strategies for dealing with excessively high data rates, i.e. buffering or discarding of data. Each of these methods brings significant disadvantages when the data is composed of a sequence of frames of graphical data representing a moving image (e.g. a representation of the rotation of an object). The discarding of data will result in loss of frames and lead to non-linear frame delivery manifesting itself in jumps in the moving image. Buffering at either end of a network link can remove or reduce the need to discard data but, particularly with high latency networks, buffering can still result in non-linear frame delivery manifesting in stuttering (i.e. significant changes in the rate of display of images) or jumps in a moving image. It is therefore desirable to provide a method and system for controlling the rendering of graphical data for delivery over a network such that stuttering or jumping of a resultant image is reduced or eliminated.

A method and system for controlling the rendering of graphical data for remote display e.g. at a remote client, is disclosed. According to a first aspect, a method of controlling rendering of graphical data for remote display comprises: at a source computer: rendering graphical data and transmitting the rendered graphical data to a remote computer. At the remote computer: receiving the transmitted rendered graphical data, presenting the graphical data for display and monitoring the rate of presenting at the remote computer of graphical data for display. Receiving at the source computer information on the rate of presenting for display at the remote computer of the transmitted graphical data; and controlling the rate at which graphical data are rendered at the source computer in response to the monitored rate of presenting for display at the remote computer.

The rate at which images are presented for display at the remote computer will be limited according to at least one of (i) the rate at which the images are transferred to the remote computer and (ii) the rate at which the remote computer processes received images for display. According to the above method, images are rendered at the server at a rate that is controlled using the rate at which images are presented for display, as monitored, at the client. Rather than seeking to control the flow of data between server and client, the rate of rendering of graphical data at the server is controlled. The resulting system removes or reduces the requirement for buffering or dropping frames so that a sequence of frames can be provided to the display smoothly, avoiding jumps and significant changes in the rate of display of the images leading to stuttering. According to a second aspect, a method of controlling rendering of graphical data for remote display comprises, , rendering graphical data at a source computer and transmitting the rendered graphical data to a remote computer for display. Receiving information on the rate of presenting for display at the remote computer the transmitted graphical data and controlling the rate at which graphical data are rendered at the source computer in response to the received information on the rate of presenting for display at the remote computer.

According to a further aspect, a system for rendering graphical data for presenting for display at a remote computer comprises: a graphics application for rendering graphical data; an output interface for transmitting the rendered graphical data to the remote computer; an input interface for receiving information on the rate of presenting for display at the remote computer of the transmitted graphical data; and a control application for limiting the rate at which graphical data are rendered by the system in response to the received information on the rate of presenting data at the remote computer. Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings in which:

Figure 1 is a block diagram of a system according to the invention;

Figure 2 is a block diagram showing, in further detail, functional components of the system shown in Figure 1.

Figure 1 shows a computer apparatus 1 such as a workstation or server for rendering and sending via network 6 a sequence of frames of graphical data representing images for display at remote client 7 according to a first embodiment of the invention. As will be described in detail, below, server 1 is arranged to render images at a rate that is controlled using the rate at which images are presented for display at client 7. Server 1 comprises a general purpose computer with a processor (not shown) arranged to execute program code, which comprises graphics application program 2 and application-end control software 5, stored in local memory (typically semiconductor memory, not shown) to perform rendering and despatch of images to client 7. Client 7 comprises a general purpose computer with a processor (not shown) arranged to execute program code, which comprises client-end control software 8, stored in local memory (typically semiconductor memory, not shown) to perform receipt and processing for display at display 9 (for example a high-resolution CRT or plasma display) of images received via network 6, for example the Internet or a private data network. Network 6 is typically based on TCP/IP but could, alternatively, be based on another suitable protocol such as UDP when provided with suitable support for flow control and retransmission. The Internet, in particular, exemplifies a type of low-bandwidth, high-latency network which can result in delayed and lost data that adversely affect the transport of images to an extent that is largely unpredictably.

Server 1 comprises graphics application program 2 for controlling the rendering of images. The images are rendered, for example, from data held in storage device 4 (e.g. hard disk drive or semiconductor memory) representing a 3D model. Rendering of the images is implemented by graphics card/drivers 3 in collaboration with graphics application program 2 under the control of application-end control software 5. Application-end control software 5 delivers the rendered images (with or without compression of some sort) to client 7 over network 6. Application-end control software 5 also monitors the rate at which frames are rendered by the combination of components 2, 3 and 4. The frame rendering rate is monitored over a monitoring period of, say, two seconds and the average value (i.e. the number of frames rendered over the monitoring period divided by the number of seconds in the monitoring period) recorded at server 1 in local memory (not shown). The averaged value advantageously reduces the effect of short-term deviations. The internal structure of server 1 and client 7 is described in more detail, below, with reference to Figure 2.

The display rate (i.e the rate at which frames are presented for display on client display 9) is monitored by client-end control software 8 over a monitoring period of, say, two seconds and the average value (i.e. the number of frames displayed over the monitoring period divided by the number of seconds in the monitoring period) recorded by client-end control software 8. The averaged value advantageously reduces the effect of short-term deviations. The display rate will be influenced by one or more of (a) the rate at which frames are rendered by server 1 ; (b) the rate at which frames are transported over network 6; and (c) the rate at which frames are processed for display by client 7. It will be appreciated that rate (b) will in general not exceed rate (a), and rate (c) will not in general exceed rate (b) - although there may be short-term deviations. At any one time, however, one of these rates will be determinant of the maximum rate at which the client is able to present images for display. The averaged display rate will tend to a value that does not exceed the lowest of the three influential rates (a), (b) and (c) listed above, although, depending on conditions, the averaged display rate may intermittently exceed one or more of the influential rates. Client-end control software 8 sends to server 1 via network 6 details of monitored client activity including the rate at which frames are presented for display on client display 9. The monitored display rate is communicated by client-end control software 8 on a regular basis (preferably, as soon as the values are available, e.g. every two seconds) over network 6. The communication will preferably not impact the delivery of graphical data from server 1 and could, for example, be arranged over a separate channel to the graphics delivery and in a separate thread. Application-end control software 5 receives the monitored display rate information at server 1 and modifies the frame rendering rate limit accordingly. Although, for a particular set of influential rate values, the display rate will generally be maintained constant, occasional frames may be dropped (e.g. due to transport effects such as buffering) when the system is operating at, or close to, its maximum performance capability (as determined by server frame rendering, network transport or client processing capabilities). Rather than exactly matching the frame rendering rate limit to the monitored display rate, the limit is preferably set to a lower value that ensures the system operates slightly below its maximum performance thereby reducing the risk of dropped frames. A preferred level is in the range three to five percent below the maximum. According to a preferred embodiment, limiting the frame rendering rate is achieved by inserting an appropriate delay in the frame rendering process in order to slow the rendering rate to the desired value. Limitation of the frame rendering rate is preferably implemented in accordance with the following rules:

• When a first set of monitored values is received from the client, i.e. following start-up or a change of image size, no frame rendering limit is imposed initially. This is to allow the system's maximum display capability to be monitored. Upon reception of subsequent, monitored values a frame rendering limit is imposed, as appropriate. This results in a, typically, two- second period during which the rendering of frames is not limited as described above. This could, in theory, result in stuttering and jumping in the displayed image, however, this short initial period is generally not of sufficient duration for non-linearities in the system to generate noticeable stuttering or jumping effects in the displayed image.

• When no frame rendering rate limit is in force and the first, unlimited monitored output value (corresponding to the system's maximum display capability) has been received, set the frame rendering rate limit at 3% less than the received client display rate (clientfps)

• When a frame rendering rate limit is in force, the difference (diff) between the current frame rendering rate limit (tunedfps) and the received client display rate (clientfps) is calculated, where diff = tunedfps - clientfps;

i. If the 'diff' is within the a tolerance range (for example if abs(diff) < clientfps/1000), then increase the frame rendering rate limit by 2% ii. If the 'diff is larger than the tolerance range, and is negative, increase the frame rendering rate limit by 4%

iii. If the 'diff' is larger than the tolerance range and positive, decrease the frame rendering rate limit by 5% The percentages quoted above are given by way of example only and fine tuning of these values may be required in certain circumstances. As can be seen from the above, the currently imposed frame rendering rate limit is, preferably, continually checked against the monitored client display rate value to allow for changes in the ability of the client to display frames (e.g. due to changes in the performance of the network or of the client).

As can be seen from rule (i), where the display rate (clientfps) and the rendering rate limit (tunedfps) are closely matched, the frame rendering rate limit gradually increases. As can be seen from rule (ii), where the display rate (clientfps) is significantly above the rendering rate limit (tunedfps), the frame rendering rate limit is increased more rapidly. As can be seen from rule (iii), where the display rate (clientfps) is significantly below the rendering rate limit (tunedfps), the rendering rate limit is reduced.

This is an iterative process arranged to track variations over time in the maximum performance level and can result in the frame rendering limit value oscillating around the actual maximum performance level value. For example, say the server starts up with an initial frame rendering rate of 20 frames per second (fps) and the client can only present received frame for display at 10fps. The display rate is reported to the server which, after an initial two seconds, sets a frame rendering rate limit 3% less than 10 fps, i.e. 9.7 fps. The client can present received frame for display at 9.7 fps, and returns a display rate value of 9.7 fps to the server. The server receives the 9.7 fps value from the client and (implementing rule (i)) increase the frame rendering rate by 2% to 9.9 fps. We now describe a sequence of subsequent steps determined by the rules set out, above, which result in a series of variations in the frame rendering rate limit ending with a return (e.g. loop) back to a value of 9.9 fps.

The client can possibly cope with presenting received frames for display at 9.9 fps and returns a display rate value of 9.9 fps. In response, the server again increases the frame rendering rate to 10.1 fps. The client cannot present frames for display at 0.1 fps and continues to return a display rate value of 9.9 fps. The server now detects that the display rate is less than the rendering rate limit and (implementing rule (iii)) reduces the rendering rate limit by 5% to 9.95 fps. The client now returns a display rate value of 9.95 fps to the server and, in response, the server increases (implementing rule (i)) the frame rendering rate to 9.97 fps. The client returns a display rate value of 9.97 and (again implementing rule (i)) the server increases the frame rendering rate to 9.9. The system has thus returned to the same value (9.9 fps) for the frame rendering rate which existed at the start of the loop. As indicated, above, the system oscillates about (i.e. above and below) the maximum performance level - mostly keeping slightly below.

It is therefore apparent that, for any value of display rate, the system will modify the rendering rate limit and monitor the result of the modification. If the resulting rendering rate is too high, the system will reduce the limit until a slight undershoot occurs, whereupon the system will increase the limit until a slight overshoot occurs and so on. The above set of rules and the resultant controlled "oscillation" of the rendering rate about the maximum performance level advantageously provide fast tracking of changes in the maximum performance level whilst avoiding unacceptable degradation in the displayed images. Preferably, client 7 communicates the monitored display rate value together with information on image height and width so that server 1 is able to detect changes in the image size. Alternatively, the server could track the size of images being rendered and synchronise a change in image size at the server with the appropriate monitoring period on the client. If the size of the image being delivered to the client changes, the current monitored values become invalid and any frame rendering rate limit is removed in order to allow the maximum system capability to be correctly monitored with the new image size for a short period before a new limit is imposed.

Referring to Figure 2, functional components of the server 1 and client 7 are shown in greater detail. In server 1 , components of the application-end control software 5 include an image capture component 37, an optional codec 39, a graphics quality control system 31 (hereafter referred to simply as the QCS) and input and output interfaces 33, 35. Image processing at server 1 optionally employs compression to control the amount of data that needs to be transmitted over network 6. The codec may be implemented in hardware or software and represents any device or program capable of suitably encoding digital data. JPEG2000 is a suitable codec algorithm for encoding captured images but, in principle, other compression codecs, such as standard JPEG, may be employed. At client 7, client-end control software 8 transmits and receives data to/from network 6 via respective output and input interfaces 43, 45. Transmitted data may include user settings and/or user control signals 47, the latter resulting from, for example, mouse or keyboard inputs associated with a user manipulating the 3D model being represented on display 9. Data received by client-end control software 8 comprises image data transmitted from application-end control software 5 representing updated images of the model for display on a display 9 using a suitable graphics card/driver 49.

When the user interacts with the 3D model, for example to rotate the model to a different viewing angle using mouse or keyboard, the resultant control signals are transmitted from client-end control software 8 to both the graphics application 2 (i.e. to identify how the model is to be translated and which new images need to be acquired from storage) and to the QCS 31. In response, graphics application 2 acquires the new data from storage 4, outputs the visualisation using graphics card 3 after which each image is optionally captured and compressed by the codec 39. According to a further aspect, only the resizing of a window is detected with other user interactions being determined by comparing the previous frame to the current frame. Each image is transmitted by QCS 31 to client-end control software 8.

The above embodiments are to be understood as illustrative examples to aid understanding of the invention. Further embodiments of the invention are envisaged and will be evident to the skilled reader. It is to be understood that any feature described in relation to any one embodiment may be used in combination with one or more features of another of the embodiments, or any combination of the embodiments. Furthermore, equivalents and modifications not described above will be evident to the skilled reader and may also be employed without departing from the scope of the invention, which is defined in the accompanying claims. Control software 8 which monitors the rate at which frames are presented for display on client display 9 may be located elsewhere than on client 7. Client display 9 may be located integral with or as a separate unit to client 7. As will be understood by those skilled in the art, the invention may be implemented in computer program product software, any or all of which may be contained on various storage media so that the program can be loaded onto one or more computers or could be downloaded over a computer network using a suitable transmission medium. The computer program product software used to implement the invention may be embodied on any suitable carrier, readable by a suitable computer input device (not shown), such computer program product comprising optically, magnetically or otherwise readable marks.