Keywords

1 Introduction

It was reported in [16] that 61.3% of all HTTP requests to servers are images. In fact, for each image we need a HTTP request. This action includes interaction between the web server and the user. Web server is characterized by a long delay due to the messages transporting the request through the network stack, the request treatment at the server and the location of the resources in the server cache. So to reduce web interactions, web designers resort to CSS-sprite technique, whose main idea is to regroup small images, called tiles, in pictures called, sprites.

Figure 1(a) shows a sprite and Fig. 1(b) shows a part of Cascading Style Sheet (CSS) [27] file. The size of each of the three tiles in Fig. 1(a) is 17 Kilobytes (KB). If tiles are used separately, we need to load each tile apart, which means that we are going to load 51 KB. However, if we use the sprite Fig. 1(a), we need only to load 21 KB. And this is not all, for in order to load each tile, we need a HTTP request instead of loading the sprite only once and saving it on the cache. We can imagine the amount of reduction in the case of thousands of tiles.

To our knowledge, CSS was introduced by [1] then popularized by [23]. CSS-sprite generators pack all tiles in one or multiple sprites. Yet, they are still forcing the packing of tiles without rotation.

Fig. 1.
figure 1

Example of use of CSS-sprite

Full size image

Css-sprite problem is a practical problem with multiple facets involving combinatorial optimization problems, image compression and network performance. These facets will be presented in further sections. In the next section, we will present our approach which allows tiles rotation while constructing sprites. In Sect. 3, we will present in details geometric packing as well as chosen heuristics. In Sect. 4, we will describe briefly image processing. Section 5 is dedicated to outline communication performance. The last section is devoted to the evaluation of our solution.

2 Problem Formulation

Formally, CSS-sprite packing problem is defined as follows: given a set of tiles \(\varGamma _{n}= \{t_{1},\ldots , t_{n}\}\) in standard formats (such as JPEG, PNG and GIF). We intend to combine them into a sprite or a set of sprites S to minimize network transfer time. CSS-sprite packing is a NP-Hard problem [20]. The major problem is the large number of tiles and the presence of distorted tiles. Css-sprite packing is considered as an optimization problem of the class 2D packing problems because tiles and sprites are rectangles. Contemporary CSS-sprite generators pack tiles in one or many sprites but do not consider two important aspects:

  1. 1.

    Tiles rotation.

  2. 2.

    The presence of distorted tiles.

In fact, though it is technically possible to rotate images using CSS, tiles rotation has not been used in CSS-sprite packing so far [20], which may cause wasted space illustrated in Fig. 2. Wasted space drains memory and excessive memory usage affects browser performance. One possible approach to overcame wasted space in sprites is to model CSS-sprite problem as a two-dimensional probabilistic non-oriented bin packing problem. Following the notation [18], this problem is denoted by 2PBPP|R. 2PBPP|R is a branch of Probabilistic Combinatorial Optimization Problems (PCOP).

The idea of PCOPs comes from Jaillet [14, 15]. Among several motivations PCOPs were introduced to formulate and analyze models which are more appropriate for real world problems. PBPP was first studied in [5].

2PBPP|R is essentially a 2BPP|R where one is asked to pack a varying number of rectangular items: where we assume that a list \(L_{n}\) of n rectangular items is given, and that some items disappear from \(L_{n}\). The subset of present items is packed without overlapping and with the possibility of rotation by \(90^\circ \) into the minimum number of identical bins. Table 1 represents the similarities between 2PBPP|R and CSS-sprite problem.

Fig. 2.
figure 2

Example of wasted space

Full size image
Table 1. Analogy between 2PPBP|R and CSS-sprite technique
Full size table

Solving CSS-sprite problem, is a tantamount to solving an instance of 2PPBP|R. The possible optimization methods to solve bin-packing problems are exact methods, heuristics, meta-heuristics. Even though, it is guaranteed that exact methods can find an optimal solution, the difficulty of obtaining an optimal solution increases drastically if the problem size increases, due to the fact that is an NP-hard problem.

3 Geometric Packing

Css-sprite packing was firstly solved manually [23] then multiple solutions were proposed. Moreover, a great number of sprite generators have been proposed. A recent survey of existing solutions were proposed by [20]. But we are only interested in those which exploit 2D packing heuristics. Table 2 groups this category of solutions identified by short name and web address. In fact, in CSS-sprite packing problem, decisions of choosing the position of tiles need to be made without full knowledge of the rest of the input. We have an incrementally appearing input, where the input needs to be processed in the order in which it comes. The input is only completely known at the end of the problem.

So, to solve this situation we consider some fast online algorithms. Such algorithms receive the tiles one at a time and need to decide where to place tiles in the bin without knowing the full problem. We choose from literature the following algorithms:

Table 2. Sprite generators using 2D packing algorithms
Full size table
  1. 1.

    Bottom Left (BL): The heuristic was proposed by Baker et al. [4]. The current item is then packed in the lowest position of open bin, left justified; if no bin can allocate it, a new one is initialized. Chazelle [6] proposed an efficient implementation of this algorithm in \(\mathcal {O}(n^{2})\) time and \(\mathcal {O}(n)\) space.

  2. 2.

    Best Area Fit (BAF): Orient and place each rectangle to the position where the y-coordinate of the top side of the rectangle is the smallest and if there are several such valid positions, pick the one that is smallest in area to place the next item into. The item is placed in the bottom left corner of the chosen area. Based on tests performed by [2], it would suggest an average of \(\mathcal {O}(n^{3})\) time and \(\mathcal {O}(n)\) space.

  3. 3.

    Item Maxim Area (IMA): This heuristic was proposed by [9] as an extension of the Best-Fit heuristic for 2D packing problems. At each step of item packing, a choice of the couple (item to be packed, receiving area) is made.

    This choice is based on the criteria which takes into account the characteristics of the item and those of the candidate area. Given an item \(a_{i}(w_{i},h_{i})\) in a given orientation and an area ma that can contain it, let \(dx_{i}\) and \(dy_{i}\) (respectively \(w_{ma}\) and \(h_{ma}\)) be the projections of the edges of \(a_{i}\) (respectively ma) on the x- and y-axis. Given four real numbers: \(q_{1}\), \(q_{2}\), \(q_{3}\) and \(q_{4}\) such that \(0\le q_{k}\le 1;k=1,\dots ,4\) and \(\sum \limits _{k=1,\dots ,4}q_{k}=1\), the criteria can be written as follows:

    $$\begin{aligned} O(a_{i},ma)=q_{1}\frac{w_{i}h_{i}}{w_{ma}h_{ma}}+q_{2}\frac{dx_{i}}{w_{ma}}+q_{3}\frac{dy_{i}}{h_{ma}}+q_{4}\frac{w_{i}^{2}+h_{i}^{2}}{w_{ma}^{2}+h_{ma}^{2}} \end{aligned}$$

    The couple (item to be packed, maximal area that will accommodate it) is the one that maximizes the criteria cited above. The choice of IMA was based on the elaborated experiments [9], which conclude that IMA dominates several heuristics from literature however theoretically the complexity of this heuristic is \(\mathcal {O}(n^{5})\).

4 Image Processing

Processing images is a primordial step in CSS-sprite packing whose purpose is to reduce tiles sizes, and so implicitly decrease transfer time and sprites size. It involves tiles transformation and tiles compression.

  1. 1.

    Tiles Transformation: Tiles are images in standard image formats as JPEG, PNG and GIF. All GIFs tiles were converted to PNG, which reduces image size [24]. JPEG tiles were transformed to PNG if PNG format is smaller than JPEG image.

  2. 2.

    Tiles compression: Presenting image compression techniques and standards is beyond the scope of this paper. But we recommend readers to take a look at several survey papers [22, 25] to understand the concept of image compression techniques and standards. In fact, no method can be considered good for all images, nor are all methods equally good for a particular type of image. Compression methods perform in different manner in accordance with different kinds of images.

    Recently, Google Incorporation proposed a compression tool named Zopfli [3]. Zopfli algorithm is based on Huffman coding. It was proved that Zopfli yields the best compression ratio [12].

    As we mentioned before, images often represent the majority of bytes uploaded to a web page. Therefore, image optimization is essential for saving bytes and the most important performance improvement. For better results, sprites were post-compressed for the minimum size. This means that sprites obtained after packing tiles are further compressed for the minimum size.

5 Communication Performance

Obviously, we consider that measuring the quality of sprites is equivalent to determining the network transfer time. However, certain factors make it hardly possible. In fact, transfer time is unpredictable and non-deterministic. So, it remains impossible to use detailed methods of packet level simulation to calculate sprites transfer time since those methods are quite time consumers [20]. Thus, [26] proposed to use flow models to evaluate the quality of sprites.

We exploited the flow model proposed by [20] which was validated in real settings. Table 3 presents the parameters of our model:

Table 3. Model parameters
Full size table

The transfer time of a set of sprites over c concurrent channels is modeled by the following formula [20]:

$$\begin{aligned} T(S,c)=max\left\{ \frac{1}{c}\sum _{i=1}^{m}(L+\frac{f_{i}}{B(c)/c}), \underset{\{i=1..m\}}{max}\{L+\frac{f_{i}}{B(c)/c})\}\right\} \end{aligned}$$
(1)

Since the web site performance is not only affected by the server but also by the user side such as browser and computer performance, so performance parameters should be measured on their real populations.

6 Computational Results

In this section, we compare our approach to solve CSS-sprite packing problem, named SpriteRotate, with alternative sprite generators. The main contribution of our approach is to rotate tiles by \(90^{\circ }\) while constructing sprites.

SpriteRotate has been implemented in Java using Eclipse Jee Neon IDE. All tests were performed on typical PC with i5-5200U CPU (2.2 GHz), 12 GB of RAM and Windows 8.

Based on experiments through real visitors [20], transfer time model parameters have been set to \(L= 352\) ms, \(c =3\) and \(B(c)= 631\) Kilobit (Kb)/s. For image compression, Zoplfli compression level has been set to the strongest level 9.

Generated sprites by SpriteRotate include the position of tile in the sprite, which sprite contains a considered tile and whether the output is one sprite or multiple sprites. Besides, we specify if the tile in the sprite is rotated or not to facilitate the extraction of tiles from CSS file. SpriteRotate offers two output formats: PNG and JPEG.

Thereafter, we applied the following procedure. In the first experiments, we considered only a set of sprite generators which construct one sprite. Since SpriteRotate builds a number of sprites, we modified SpriteRotate code to generate a single sprite. In fact, group A of solutions in Table 2 were excluded from the evaluation because of: failure to work properly or dead applications. Only solutions from group B were chosen for comparison.

In the second series of tests, SpriteRotate has been compared to Spritepack [20], which is a recent solution which generates multiple sprites. The comparison focused on the sizes of the sprites and the objective function: transfer time.

In order to evaluate SpriteRotate, we considered 10 tiles sets from test sets collected in [20]. The tiles are skins and other reusable GUI elements of popular open source web applications. But unfortunately most of them are too simple, consisting of few tiles with identical shape and tiles format. Nevertheless, this tiles test sets allow evaluating our approach in realistic settings. The instances in Table 4 are chosen to represent a spectrum of possible situations: from Joomla Busines14a tile set of size smaller than 20 KB (29 tiles) to Vbulletin Darkness with 1010 tiles and over 11.2 Megabytes (MB) total size.

Table 4. Test instances
Full size table

The results of the first evaluations are collected in Tables 5 and 6, which show the sprite size \(f_{i}\) and resulted transfer time T(S, c) of SpriteRotate compared to alternative generators. Each column represents results for each generator. Column labeled “Min” and “Max” represents respectively the minimum and the maximum gain rate obtained by SpriteRotate relatively to alternative generators. Row “Average” is the average size of the sprite through all test instances. An empty cell means that generators has not been able to generate a sprite. It is clear that SpriteRotate outperformed the alternative generators in sprite size and transfer time. Codepen generator considered as the second generator, multiplied on average sprite size by a factor 4 compared to SpriteRotate’s (17 in worst case). Similarly, transfer time was multiplied on average by a factor of 5 compared to the SpriteRotate’s objective function (and 28 in the worst case). In absolute terms, SpriteRotate decreases sprite size from 16 KB to 279 KB. As consequence, a very considerable gain was obtained. SpriteRotate succeed to reduce transfer time from 370 ms up to 71 s.

In the case of Vbulletin Darkness instance (1010 tiles), TexturePacker and SpriteRotate were only able to give result. In fact, SpriteRotate lowers sprite size by 800 KB and transfer time by 30 s.

Through computational results, SpriteRotate was able to generate sprites to all tiles instances with up to 1010 tiles. SpriteRotate produced a transfer time of seconds compared to few tens for considered generators. This is a very substantial improvement for the objective function (1). Overall, although our solution was not designed to generate one sprite with the smallest file size, it still outperforms competitors.

Table 5. Comparison of SpriteRotate to alternative generators on size of sprite \(f_{i}\)(Kb)
Full size table
Table 6. Comparison of SpriteRotate to alternative generators on objective function T(S, c)(s)
Full size table

In the second round of comparison, SpriteRotate has been evaluated to Spritepack. The comparison also focused on sprites size and transfer time. Due to lack of results related to Spritepack, the comparison was only performed on 5 tiles sets. The results are collected in Table 7.

Table 7. Comparison of SpriteRotate to Spritepack on size of sprites (F(Kb)) and objective function (T(S, c)(s))
Full size table

For small tiles instances with up to 32 tiles, SpriteRotate was able to reduce sprites size by a factor of 1.2 to 4. In absolute terms, the reduction was from 1.5 KB to 18 KB. As a consequence, transfer time T(S, c) was reduced from 60 ms to 720 ms.

For moderate instance Oscommerce Pets (162 tiles), the improvement of transfer time, by 1.82 s, was driven by reduce in sprites size by 47 KB.

To conclude this experimental comparison, the proposed approach, SpriteRotate, focused on solving CSS-sprite packing using a transformation to a probabilistic non oriented bin-packing problem. The main contribution was allowing tiles rotation. SpriteRotate was compared to 9 alternative generators on tiles instances, of popular open source web applications, with up to 1010 tiles. Our experimental study has demonstrated that SpriteRotate outperformed the alternative generators.

Though SpriteRotate is not necessarily constructing optimum sprites because we are dealing with NP-Hard problem. Thus, we can conclude that tiles rotation have a great influence on reducing sprites size and the objective function: transfer time.

This section will conclude with some general remarks about SpriteRotate. The solution was able to provide sprites for all test sets in practically acceptable time. SpriteRotate processing time is split between image processing, geometric packing and postprocessing. The three stages consumed in average 70%, 20%, 10% of total processing time, respectively. Thus, image compression is the most time-consuming step.

Concerning image compression, we detected that for tiles with sizes lower than 1 Kb, there was not a modification in tiles sizes. As matter of fact, image compression was efficient for tiles with sizes larger than 3 Kb.

SpriteRotate is considered as a research tool and not an industrial one. In fact, image compression techniques and packing algorithms are evolving so other heuristics and image compression standards can be tried as well as integrating further input formats.

7 Conclusion

In this paper, we have approached the CSS-sprite packing problem into two-dimensional non-oriented probabilistic bin packing problem (2PBPP|R). We followed the relation between CSS-sprite packing and 2PBPP|R and proposed our approach which allowed for the first time to rotate tiles while generating sprites. Furthermore, in order to manage efficiently the big number of tiles, it was necessary to exploit 2PBPP heuristics. Our experiments on real-world sets validated our approach, which performs better than alternative approaches.