|
|
|
|
|
|
by cabirum
4124 days ago
|
|
|
Sprite sheets contain images browser might need. Essentially it's a preloading technique, so you won't be slowed by waiting for something to load, even if it takes half a sec. Also, most if not all browsers use GPU to render web pages. And spriting actually comes from gamedev/GPU world [1], where many textures are baked/combined into a big one because it's efficient from performance/memory layout POV. A final thought, what about server IO becoming a bottleneck when it needs to read hundreds of small files from disk for each request? [1] http://www.blackpawn.com/texts/lightmaps/ |
|
|
Browsers generally use the GPU for compositing web pages, but the CPU still generally does most of the rendering, and that frequently includes at least some of the image rendering. That's not actually relevant, though. The problem is bleeding; see here [1] for an example of someone encountering it in a gamedev context.
So how do you solve bleeding? If you read the answer to that Stack Overflow question, you'll see that it involves correctly setting up the data in the texture to avoid the issue. The problem is that browsers cannot assume that you've done that. The workaround depends on which graphics backend (OpenGL, D2D, etc.) is in use, but it can sometimes involve making a temporary copy of the region of the texture you're going to draw, which is obviously expensive.
As for server IO being slowed down by reading hundreds of small files from disk, I'd expect a properly configured server to be serving those files from memory, either explicitly or implicitly through the OS's filesystem cache.
[1] http://stackoverflow.com/questions/7894802/opengl-texture-at...