Advertisement

A Hybrid Remote Rendering Approach for Graphic Applications on Cloud Computing

  • Chin-Feng LaiEmail author
  • Han-Chieh Chao
  • Zong-Ruei Tsai
  • Ying-Hsun Lai
  • Mohammad Mehedi Hassan
Conference paper
  • 1.4k Downloads
Part of the Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering book series (LNICST, volume 142)

Abstract

Due to the fast development of mobile devices, the requirement of graphics processing has grown rapidly in recent years. Graphic processing unit provides the computing of 3D effect in mobile devices, such as user interface and 3D application. Comparing with personal computer, the computing power of mobile devices is much lower. The concept of remote rendering is connecting the graphic processing unit in the server to improve the local rendering ability. However, when network bandwidth is unstable or even unreachable, the user experience would extremely drop. In the recent research, there are a couples mount of topics in association with decreasing network packet transmission. In the unstable network environment, the correlation research is still lacking. This paper proposes a hybrid remote rendering approach for craphic applications on cloud computing. It takes local rendering ability and network bandwidth as input arguments and dynamically sets the frames drawing sequence on client and rendering server. In this study, the experiment chooses 3 applications and runs in 2 different network environments. In the 10 % higher than the lowest requirement bandwidth, this framework could improve 44.99 % frames in each second. In lowest bandwidth requirement, it could improve 44.57 % frames and 30.86 % in 10 % lower than lowest requirement. In the unstable bandwidth, there are around 33.74 % increasing in frame rate.

Keywords

Hybrid remote rendering Graphic applications Cloud computing 

1 Introduction

With continuous development of science and technology, cloud computing technology has been used to extensively improve the quality of network services. However, there remain applications of complex operations in the graphic applications. When the user runs this drawing program, the image processor cannot instantly complete calculation, resulting in picture delay, thus, user experience is reduced. In the application of cloud service, data transfer often occupies the network bandwidth. If part of the client-side mathematical capability is combined with the server calculation, the complex parts are calculated by the server, meaning the use of network bandwidth can be reduced, allowing the user to use network transmission smoothly when using cloud services. Common cloud services mostly accelerate CPU operations, and with the performance improvement of the Graphic Processing Unit in recent years, cloud services for GPU acceleration have appeared, and the research subjects regarding remote rendering have gradually received greater attention. It was originally implemented by open source [1]; while the hybrid rendering architecture, etc., were proposed in recent years [2, 3, 4, 5]. However, there is no study regarding a remote rendering system on network speed and quality. In view of this, this study intends to use the graphics computing capacity of the current PC to enhance the graphic capability of mobile devices. As more network bandwidth will be consumed during remote rendering, this study considers the image processing capacity of mobile devices, current graphic capability of devices, and current network transmission rates and quality as the decision parameters of the hybrid rendering system of this study. Finally, the image processors of the client-side and server simultaneously execute calculation. Based on this parameter calculation, the user can use a remote server for drawing even when the network transmission is unstable.

2 Related Works

2.1 General Remote Rendering

The remote rendering system, as proposed by Simon Stegmaier [6], is constructed mainly on an X Server, with GLX protocols, and through dynamic linking, and developers can use this system in application without modifying the application source code. In most common remote rendering architectures, in order to reduce packet transmission quantity, the computing time of the rendering server must be prolonged. For better user experience, the interactive feedback of the user application is increased, and packet transmission quantity shall be upgraded. Marc Levoy proposed a solution [7] by dividing the complex rendering operation into two parts. One is a simple geometrically physical architecture, and the other is the final texture mapping, light effect, and fog effect. Figure 1 shows the remote rendering system, as proposed by Marc Levoy.
Fig. 1.

General remote rendering system.

2.2 Hybrid Remote Rendering

Audrius Jurgelionis proposed the mode-optional remote rendering system based on the Game_Large architecture [8]. When the user-side hardware or network connection quality is low, graphics rendering is handed over to the server by video streaming, and the result is compressed into video streaming for the user. When the mathematical capability of user’s hardware is high and the network connection is stable, 3D Streaming is used to hand the 3D information to the user for drawing calculation. The client-side shall have better processing core and faster network connection. Figure 2 shows the hybrid remote rendering system proposed by Audrius Jurgelionis.
Fig. 2.

Hybrid remote rendering system.

The red part in Fig. 2 is the home edition of the Game_Large system, and for data transmission with the client-side, the indigenous Game_Large system nucleus and display interface are used. The left part of Fig. 2 shows the web server, which is an Apache server combined with PHP and sqLITE modules, and the application menu is displayed on the webpage. The right part of Fig. 2 shows the Database Transaction Layer, which is used for data transmission with the database system and accessing the application files. The lower part shows server rendering, when the user is connected to the server, this subsystem selects 3D Streaming or video streaming according to the Quality of Service (QoS). This system uses the aforesaid three major subsystems as program operating cores, the user is connected to the web server, and the database installation program data are accessed, via this interface, in order to run applications.

3 Approach Architecture

This paper proposes a hybrid remote rendering approach for graphic applications on cloud computing. When the local side rendering capability is insufficient, the 3D application menu fluency can be enhanced by cloud computing power in order to enhance the user’s experience. The Cloud rendering server is connected via the network, and whether or not to use the server for rendering is judged according to current network connection speed and quality. When the network connection speed and quality are good, the rendering server is used for rendering operations. When the network connection speed and quality are poor, the GPU of the current mobile device is used for drawing calculations. The hybrid remote rendering platform is implemented in the aforesaid manner. Figure 3 shows the proposed approach architecture. The local side receives the function call from the upper application. First, the Bandwidth Measurement Module collects current network connection speed and quality, and submits the result to the Rendering Selection Module for rendering decision. If the decision result is a local drawing, the drawing instruction is directly processed systematically by GPU calculation. If the decision result is submitted to the Rendering Server for drawing calculation, the teledrawing function transfers the instruction, via the network, to the server. When the rendering server completes the drawing, the image is coded and fed back to the local side. The local side can obtain the drawing result from the Frame Decoder. Finally, the drawing Buffer Manager decides when the picture should be displayed on the Display, and the local side hybrid rendering process is completed.
Fig. 3.

Proposed approach architecture.

At the rendering server side, when the mobile device transfers the drawing instruction to the server, the Rendering Context Receiver receives the drawing program environment settings and drawing instructions. Afterwards, the drawing instruction is drawn by the 3D graphics library, and calculated by the hardware. Finally, the drawing result is coded and transferred to the local side. In many common server architectures, the Virtual Machine only virtualizes the CPU; therefore, the 3D drawing is less supported in the virtual machine environment, and at the rendering server side, the Low Level Virtual Machine (LLVM) is used to translate the drawing instruction into the CPU machine code, and 3D rendering is implemented by CPU. If the current picture is rendered by the server, in order to reduce the consumption of network bandwidth, the picture is coded before it is transferred via the network. The client-side must decode the picture before it is used. The server rendering sequence diagram is shown, as follows:

3.1 Bandwidth Measurement Module

The bandwidth measurement module measures the current network bandwidth, network stability, and current application drawing complexity. In terms of network bandwidth, the upload and download bandwidths of client-side and server-side, as well as the current maximum bandwidth consumption, are measured. In terms of network stability, the rate of change in the previous network bandwidth is observed, current network stability is obtained from the rate of change, and the bandwidth for the next time interval is determined. Application drawing complexity is related to current application drawing instructions. The more complicated the application, the more drawing instructions shall be transferred, the more drawing instructions there are, and the larger the consumption of network bandwidth. The detailed theories and implementation modes of the aforesaid three items are described, as follows:

Measurement of Network Bandwidth: As mentioned above, regarding the measurement of network bandwidth, the client-side measures the upload and download bandwidths. The measured maximum upload bandwidth is expressed as Eq. 1, and the download bandwidth is expressed as Eq. 2.
$$\begin{aligned} {B}_{up} = Bandwidth (upload) \end{aligned}$$
(1)
$$\begin{aligned} {B}_{down} = Bandwidth (download) \end{aligned}$$
(2)
Network Stability Measurement: The measurement of network stability, in addition to current bandwidth measured by the aforesaid two equations, is expressed as Eq. 3.
$$\begin{aligned} Upload Changing Rate = (CR_{up})\frac{\sum _{2}^{N}\left| \frac{B_{up(n-1)}-B_{up(n)}}{B_{up(n-1)}} \right| }{N-1} \end{aligned}$$
(3)
The download bandwidth stability is expressed as Eq. 4.
$$\begin{aligned} \begin{aligned} Download Changing Rate = \\ (CR_{down})\frac{\sum _{2}^{N}\left| \frac{B_{down(n-1)}-B_{down(n)}}{B_{down(n-1)}} \right| }{N-1} \end{aligned} \end{aligned}$$
(4)
Current Application Drawing Complexity: In this study, the application drawing instruction complexity is defined as the number of packets of an instruction to be transferred for the application to draw one single picture. Generally speaking, when the drawing instruction is complex, as there are more required scenes or objects, higher mathematical capability is required. If it is implemented by remote rendering, more upload network bandwidth shall be occupied. The application drawing instruction complexity is defined as Eq. 5.
$$\begin{aligned} K_{up} = \frac{Upload Bytes}{Frame Count} \end{aligned}$$
(5)
The upload bandwidth is used mainly for transferring drawing instruction, while the download bandwidth is used for transferring coded pictures. The coded picture is related to current picture compression ratio, defined as Eq. 6.
$$\begin{aligned} K_{down} = \frac{Download Bytes}{Frame Count} \end{aligned}$$
(6)
The drawing complexity is usually related to the picture of a current scene, and when the picture contains a large number of objects, the complexity is high. It is unnecessary to measure the complexity when the complexities are similar to each other. This study proposes using drawing instruction triggering to measure drawing complexity. When the calculation and measurement of the aforesaid three items are complete, the network packet transfer time for remote rendering can be calculated. The required time for packet transfer is in the unit of one single picture, the upload time can be defined as Eq. 7, and the download time can be defined as Eq. 8.
$$\begin{aligned} {T}_{upload}= \frac{{K}_{up}}{((1-CR) \times 50\,\% + 50\,\%) \times {B}_{up} } \end{aligned}$$
(7)
$$\begin{aligned} {T}_{download}= \frac{{K}_{down}}{((1-CR) \times 50\,\% + 50\,\%) \times {B}_{down} } \end{aligned}$$
(8)

3.2 Rendering Decision Module

The rendering decision module decides the rendering position of each picture during the next period of time, and the bandwidth measurement module obtains the current network transmission rate and quality as the basis of deciding one item. When the rendering position in the next time interval is decided, the drawing instruction is transferred to the corresponding library by dynamic library linking. The hybrid rendering system, as designed in this study, uses a remote server to accelerate local rendering, and considers the local drawing computing power and current network connection speed and quality. In terms of the network connection information, the required information is obtained by the bandwidth measurement module. An equation is defined for local graphic capability in this study, Rendering Factor, expressed as Eq. 9.
$$\begin{aligned} Rendering Factor (RF) = \frac{CT_{client}}{CT_{server}} \end{aligned}$$
(9)
The \(CT_{client}\) represents the computing time of the client, which represents the client hardware computing power. The larger the value, the longer the computing time, and the mathematical capability is lower. The smaller the value, the shorter the computing time, and the mathematical capability is higher. It is generally known as local side computing performance, and is related to applications and hardware computing power. When the application complexity is low, the hardware computing power is relatively high; and when the application is complex, the hardware computing power is relatively weak. The \(CT_{server}\) represents the computing time of the server, which represents the time for server rendering, and this rendering process is as shown in Fig. 4. Therefore, it is related to the client hardware computing power, server computing power, and network speed and quality.
Fig. 4.

Rendering process.

The client hardware performance is different from the aforesaid \(CT_{client}\). The \(CT_{client}\) is mainly related to CPU and GPU operations. In comparison to \(CT_{client}\), the \(CT_{server}\) is only related to CPU computing power. The server computing power is related to the rendering operation of the server, i.e. the speed of processing OpenGL ES instruction. The network connection speeds are the upload and download times, which are obtained by the bandwidth measurement module. The network connection quality is also obtained by the bandwidth measurement module. As stated above, the \(CT_{server}\) can be expressed as Eq. 10.
$$\begin{aligned} CT_{server} = f(P_{c},P_{s},B,K,T_{enc},T_{dec}) \end{aligned}$$
(10)
In Eq. 2, \(CT_{server}\) represents the time for server rendering, as related to six factors. Table 1 lists the meanings of the six factors.
Table 1.

Six factors of the \(CT_{server}\)

Factor name

Meanings

\(P_c\)

The required 3D model computing time when the graphics application is executed at the Client, e.g. vector vertex, rotation angle, matrix operation, etc

\(P_s\)

The server responds to the drawing function call, and the time is spent on rendering. This item is mainly related to the server GPU

\(B\)

Measured by the bandwidth measurement module, current network bandwidth, and stability

\(K\)

Measured by bandwidth measurement module and complexity proportion of current application

\(T_{enc}\)

Picture coding time at Server

\(T_{dec}\)

Picture decoding time at Client

The six factor times in Eq. 2 are summed up, and defined as Eq. 11.
$$\begin{aligned} CT_{server} = P_{c}+P_{s}+T_{enc}+T_{down}+T_{dec} \end{aligned}$$
(11)
The above two items of \(CT_{client}\) and \(CT_{server}\) are calculated as Eq. 1, in order to obtain the local side and Server computing performance proportion. When the server performance is higher, most rendering can be completed by server rendering; however, a few pictures are still drawn by the local side. On the contrary, if the local side performance is higher, most picture rendering is implemented by the local side. The Rendering Factor (RF) is calculated by Eq. 9, and this factor is calculated by Eq. 12 to obtain the local side and Server rendering picture configurations in the next time interval.
$$\begin{aligned} \left( \frac{1}{CT_{client}}-F_{sub}\right) + (F_{sub}\times RF) = 30 \end{aligned}$$
(12)
In Eq. 12, \(F_{sub}\) represents how many frames shall be subtracted from the frames per second of the local drawing at the client. This study intends to use the hybrid operation model in order to increase the picture refresh rate per second to 30 frames. The value of \(F_{sub}\) is the time of rendering the pictures that shall be reduced by the local side, and this time is rendered by remote server to increase the picture refresh rate. Equations 9 and 12 are changed into simultaneous equations, expressed as Eq. 13.
$$\begin{aligned} \left\{ \begin{matrix} Rendering\; Factor(RF) = \frac{CT_{client}}{CT_{server}} \\ \left( \frac{1}{CT_{client}}-F_{sub}\right) + (F_{sub}\times RF) = 30 \end{matrix}\right. \end{aligned}$$
(13)
The \(F_{sub}\) is obtained from simultaneous equations, expressed as Eq. 14.
$$\begin{aligned} F_{sub} = \frac{30-1/CT_{client}}{RF-1} \end{aligned}$$
(14)
Table 2 shows the meanings of \(F_{sub}\) in this work.
Table 2.

Meanings of \(F_{sub}\) in various conditions

Condition

Meanings

\(F_{sub} < 0\)

When \(F_{sub}\) is smaller than 0, it means RF is smaller than 1, and local side rendering performance is greater than remote performance

\(0 < F_{sub} \le 1/CT_{client}\)

When Fsub meets this condition, it means the hybrid rendering system of this study can be used for picture rendering configuration

\(F_{sub} > 1/CT_{client}\)

When Fsub meets this condition, it means that only remote rendering is allowed, and the current network environment is inapplicable to hybrid rendering

\(FPS_{client}\) is the number of pictures to be rendered by the local side in the next time interval, expressed as Eq. 15.
$$\begin{aligned} FPS_{client} = \frac{1}{CT_{client}} - F_{sub} \end{aligned}$$
(15)
FPSserver is the number of pictures to be rendered by the server in the next time interval, expressed as Eq. 16.
$$\begin{aligned} FPS_{server} = F_{sub} \times RF \end{aligned}$$
(16)
After Eq. 9 calculation, the number of pictures rendered by the client is calculated by Eq. 15, and the number of pictures rendered by the server is calculated by Eq. 16. When the rendering picture configuration in next time interval is completed, the rendering sequence shall be completed.

According to the aforesaid assumptions, the server drawing rate must be higher than the client drawing rate. Therefore, in the picture rendering time sequence, the client pictures are equally allocated in the server rendered picture, as shown in Fig. 5, thus, the time delay is distributed evenly in the rendering time sequence. If the rendering time sequence is allocated nonuniformly, there will be unsteadiness when the user views pictures. In a uniformly distributed rendering time sequence, there is still unsteadiness; however, this phenomenon can be eliminated by the buffer management mechanism in the next section.

3.3 Rendering Decision Module

Figure 6 shows the flow of this system. The operation flow of this system is described below, as per initialization, bandwidth measurement, calculating RF, rendering process, and picture display.
Fig. 5.

Picture rendering time sequence.

Fig. 6.

System flow.

This study uses three application working programs as the test programs. The three application working programs are tested, where each application is tested in both stable and unstable network environments of variable bandwidths. In the experimental network environment, adjustment is based on the upload bandwidth, and the upload and download speeds are limited by speed limiting software. The network transmission rates are different when the applications are tested in the same manner, as drawing instructions are often related to applications. When the drawing program is complex, the number of drawing instructions to be transmitted increases. In terms of download bandwidth, as the rendered picture is transferred, it is related to the image compression ratio and resolution.

4 Analysis of Approach Implementation Results

In this section, the results of three application programs on stable/unstable network condition are analyzed.

4.1 Stable Bandwidth

In terms of application I, the following figure shows the tested network bandwidth and picture refresh rate of application I. In the case of stable bandwidth, and in terms of picture configuration, the server renders 20 frames, the local side renders 10 frames, and the overall picture refresh rate is 30 frames. For current bandwidth, the download bandwidth consumption is smaller than the upload bandwidth consumption. As the system calculates download and upload times, the upload bandwidth greatly influences the picture refresh in decision making (Fig. 7).
Fig. 7.

Application I on stable bandwidth.

Application working program II is also tested in highly stable bandwidth, and this working program is correlated with texture mapping. The client computing power is lower in rendering, thus, at the same network speed, as Client rendering time is very different from the server rendering time, the RF is large. In terms of the allocation proportion of pictures, more pictures will be rendered by the server. The following figure shows the tested network bandwidth and picture refresh rate of application II. In the case of stable bandwidth, in terms of picture configuration, the server renders 27 frames, the local side renders 3 frames, and the overall picture refresh rate is 30 frames. For current bandwidth, the download bandwidth consumption is smaller than the upload bandwidth consumption. As the system calculates the download and upload times, the upload bandwidths greatly influence the picture refresh in decision making (Fig. 8).
Fig. 8.

Application II on stable bandwidth.

Application working program III is tested in highly stable bandwidth, and this program is the 3D graphics application for 3D blocks flying to the user. The application calculates the rotation angle and color setting of each block, and transfers the information to the GPU or rendering server for drawing. The following figure shows the tested network bandwidth and picture refresh rate of application III. In the case of stable bandwidth, and in terms of picture configuration, the server renders 26 frames, the local side renders 4 frames, and the overall picture refresh rate is 30 frames. For current bandwidth, the download bandwidth consumption is smaller than the upload bandwidth consumption. As the system calculates the download and upload times, the upload bandwidths greatly influence the picture refresh in decision making (Fig. 9).
Fig. 9.

Application III on stable bandwidth.

4.2 Unstable Bandwidth

This experiment analyzes the scenario of unstable bandwidth, the network change script of a wireless network connection, and speed limiting software changes the network transmission rate every second. The three application working programs are tested in this network environment and the results are analyzed. Application I is an OpenGL ES example program, and the following text analyzes the drawing performance of application I using the hybrid rendering architecture, as designed in this study, in unstable bandwidth. The following figure shows the tested network bandwidth and picture refresh rate of application I. The above figure shows application I tested in unstable network bandwidth. The picture refresh rate at the fourth and the fifth time point is 30, which is hybrid rendering, where the server renders 20 frames, while the local side renders 10 frames. The remote rendering mode is at the 6th to the 19th time point, and all pictures are rendered by the server. The hybrid rendering mode is at the 21st and 23rd time point, where there is an error between the decided bandwidth and actual bandwidth, thus, the current rendering configuration is wrong, and server rendering fails to be completed on time. However, in the hybrid rendering architecture, the basic picture refresh rate is maintained by the local side, thus, reducing the changes in the picture refresh rate (Fig. 10).
Fig. 10.

Application I on unstable bandwidth.

Application II is an OpenGL ES program related to texture mapping. The following text analyzes the drawing performance of application II using the hybrid rendering architecture, as designed in this study, in unstable bandwidth. The following figure shows the tested network bandwidth and picture refresh rate of application II. The above figure shows that application II is tested in unstable network bandwidth. The picture refresh rate at the fourth and the fifth time point is 30, which is hybrid rendering, the server renders 27 frames, and the local side renders 3 frames. The remote rendering mode is at the 6th to the 19th time point, and pictures are rendered by the server. The hybrid rendering mode is at the 21st and the 23rd time point, where there is an error between the decided bandwidth and actual bandwidth, thus, the current rendering configuration is wrong, and server rendering fails to be completed on time. However, in the hybrid rendering architecture, the basic picture refresh rate is maintained by the local side, thus, reducing the changes in the picture refresh rate (Fig. 11).
Fig. 11.

Application II on unstable bandwidth.

Application III is the application of squares flying to the user. In an unstable network environment, the picture rendering decision varies with the network environment. The following figure shows the tested network bandwidth and picture refresh rate of application III. The above figure shows application III tested in an unstable network bandwidth. The picture refresh rate at the fourth and the fifth time point is 30, which is hybrid rendering, and the server renders 25 frames, while the local side renders 5 frames. The remote rendering mode is at the 6th to the 19th time point, and the pictures are rendered by the server. The hybrid rendering mode is at the 20th and the 24th time point, where there is an error between the decided bandwidth and actual bandwidth, thus, the current rendering configuration is wrong, and server rendering fails to be completed on time. However, in the hybrid rendering architecture, the basic picture refresh rate is maintained by the local side, thus, reducing the changes in the picture refresh rate (Fig. 12).
Fig. 12.

Application III on unstable bandwidth.

5 Conclusion

Most previous studies selected only one rendering mode. This paper designs a hybrid rendering system, which is combined with the rendering server and local side computing power, and reduces the dependence of the remote rendering system on network speed. In good bandwidth, each application can increase the picture refresh rate to 30 frames through the server computing power. In poor bandwidth, working program I can increase the picture refresh rate by 30.86 % in the architecture designed in this study. In unstable bandwidth, as the bandwidth is variable, the bandwidth estimation is wrong, and the overall picture refresh is increased by 33.74. In future research, if the packet size and quantity of drawing instructions transferred by applications can be reduced, the rendering efficiency of the rendering system can be increased. As this study uses real-time drawing instruction processing, the user control response delay can be reduced; however, the load of the upload bandwidth is increased.

Notes

Acknowledgment

The authors would like to thank the National Science Council of the Republic of China, Taiwan for supporting this research under Contract NSC 101-2628-E-194-003-MY3, 101-2221-E-197-008-MY3 and 102-2219-E-194-002.

References

  1. 1.
    Mark, W., McMillan, L., Bishop, G.: Post-rendering 3D warping. In: Proceedings of the 1997 Symposium on Interactive 3D Graphics, pp. 7–16, April 1997Google Scholar
  2. 2.
    Engel, K., Ertl, T., Hastreiter, P., Tomandl, B., Eberhardt, K.: Combining local and remote visualization techniques for interactive volume rendering in medical applications. In: Proceedings of the Conference on Visualization, pp. 449–452, October 2000Google Scholar
  3. 3.
    Jurgelionis, A., Fechteler, P., Eisert, P., Bellotti, F., David, H., Laulajainen, J.P., Carmichael, R., Poulopoulos, V., Laikari, A., Per, P., De Gloria, A., Bouras, C.: Platform for distributed 3D gaming. Int. J. Comput. Games Technol. 2009, 1–15 (2009)CrossRefGoogle Scholar
  4. 4.
    Zhu, M., Mondet, S., Morin, G., Ooi, W.T., Cheng, W.: Towards peer-assisted rendering in networked virtual environments. In: Proceedings of the 19th ACM International Conference on Multimedia, pp. 183–192, November 2011Google Scholar
  5. 5.
    De Winter, D., Simoens, P., Deboosere, L., De Turck, F., Moreau, J., Dhoedt, B., Demeester, P.: A hybrid thin-client protocol for multimedia streaming and interactive gaming applications. In: Proceedings of the 2006 International Workshop on Network and Operating Systems Support for Digital Audio and Video, pp. 86–92, May 2006Google Scholar
  6. 6.
    Stegmaier, S., Magallon, M., Ertl, T.: A generic solution for hardware-accelerated remote visualization. In: Proceedings of the Symposium on Data Visualisation, pp. 87–94, May 2002Google Scholar
  7. 7.
    Levoy, M.: Polygon-assisted JPEG and MPEG compression of synthetic images. In: Proceedings of the 22nd Annual Conference on Computer Graphics and Interactive Techniques, pp. 21–28, September 1995Google Scholar
  8. 8.
    Nave, I., David, H., Shani, A., La ikari, A., Eisert, P., Fechteler, P.: Games@ large graphics streaming architecture. In: IEEE International Symposium on Consumer Electronics, pp. 1–4, April 2008Google Scholar

Copyright information

© Institute for Computer Sciences, Social Informatics and Telecommunications Engineering 2015

Authors and Affiliations

  • Chin-Feng Lai
    • 1
    Email author
  • Han-Chieh Chao
    • 2
  • Zong-Ruei Tsai
    • 1
  • Ying-Hsun Lai
    • 3
  • Mohammad Mehedi Hassan
    • 4
  1. 1.Department of Computer Science and Information EngineeringNational Chung Cheng UniversityChiayiTaiwan
  2. 2.Department of Computer Science and Information EngineeringNational ILan UniversityYilanTaiwan
  3. 3.Smart Network System InstituteInstitute for Information IndustryTaipeiTaiwan
  4. 4.College of Computer and Information SciencesKing Saud UniversityRiyadhSaudi Arabia

Personalised recommendations