ugrás a tartalomhoz

CSS Spriting Tips

Török Gábor · 2009. Már. 30. (H), 14.19
Ötletek CSS sprite készítéshez
 ■
1

Automatizált eszközzel készítsük

Török Gábor · 2009. Már. 30. (H), 14.27
A szerző azon állításával nem értek egyet, hogy egyből sprite-ot készítsünk, mert ezt kevésbé tartom hatékonynak több szempontból is:
  • természetesen egy jó sitebuilder egyből látja, hogy mit és hol kell felvágni, de amíg ennek képességét nem szerezzük meg, addig folyamatosan plusz munkát generálunk magunknak a rossz sprite-ok javítgatásával;
  • bármikor előfordulhat, hogy módosul a design, és szükséges a sprite némely elemének cseréje – ebben az esetben többlet munkát adunk magunknak versus build/deploy során egy eszközzel automatizáltan készítjük el a sprite-okat;
  • az utólagos sprite készítés az eddigi gyakorlatokra transzparensen ráépül; a megszokott módon készítjük a stíluslapot, amely majd forgatókönyvként szolgál a sprite készítő eszköz számára.
12

Megvalósítás?

Hodicska Gergely · 2009. Ápr. 4. (Szo), 23.23
Szerintem is teljesen megéri a befektett munkát egy ilyen kis eszköz elkészítése. Nálunk is előjött már, hogy jó lenne, csak aztán határidő áldozata lett. Csináltál már ilyet? Tapasztalatok, mire érdemes figyelni?
13

Meglévő eszközt használok

Török Gábor · 2009. Ápr. 5. (V), 10.27
Ld. Automatizált CSS sprite készítés SmartSprites-szal
2

Optimalizálás

Poetro · 2009. Már. 30. (H), 15.21
Többen felvetették kommentben, hogy nem igazán jók a sprite-ok, mert egy 1000×2000px-es sprite ~8Mb-ot foglal memóriából. Ez persze teljesen így van, ezzel nem nagyon lehet vitatkozni, de ugye ha valamit optimalizálunk, akkor valamilyen céllal optimalizálunk. Optimalizálhat az ember ugye sebességre, memória igényre, de a kettő általában nem találkozik, azaz ha valami gyors akkor általában több a memóriaigénye, és ha valaminek kicsi a memóriaigénye, akkor pedig általában lasssú (vagy lassabb).

A képek esetén is pontosan ugyanez a helyzet, ha az ember megspórol mondjuk 40 HTTP kérést egy sprite-tal, ezzel mondjuk 1-5 másodpercel rövidíti le az oldal letöltődését, az lehet hogy megéri. Ugyanakkor, ha olyan eszközre optimalizálja a weboldalt, aminek kicsi a memóriakapacitása, mondjuk mobiltelefon, akkor pedig a sprite-ok helyett valószínűleg a szétvágott képek megérik, mert így legalább befér a telefon memóriájába.
3

naiv kérdés

gex · 2009. Már. 30. (H), 15.43
ha az 1000x2000 pixeles kép helyett mondjuk 200(!) darab 100x100-as képet használok, akkor az mennyivel lesz jobb memória-használat szempontjából? tényleg nem értek ehhez a részhez, ezért kérdezem.

szerk: na beleolvastam a kommentekbe
I should also mention — images will generally take up width * height * 4 memory. So that 1000×2000 image on AMO, with most of it completely unused, takes up ~8MB of memory!
azaz - ha ez igaz - semmivel sem lesz kevesebb memória-igénye. viszont kérdés, hogy ebbe az 1000x2000-es képbe nagyjából az összes kis képet megpróbálták-e beleerőltetni, és ha igen akkor mennyi értelme van egy weboldal összes grafikai elemét egyetlen képbe sűríteni. szerintem ez már a ló túloldala (mint a css preloaderek). én általában a hoverre változó (ugye eleve erre megoldás a sprite) és az egy oldalhoz (ésszel) vagy elemhez (menü, szövegdobozok) tartozó elemeknél próbálok a http kérésekkel spórolni.
4

Adminisztratív memória?

zila · 2009. Már. 30. (H), 15.59
Nem tudom, hogyan tárolják a böngészők ezeket az objektumokat a memóriában, de biztosan van egy nyilvántartás, hogy melyik objektum hol van a memóriában, mi az azonosítója, a típusa, mérete, stb. Szóval szerintem 100 db 1 byte-os kép sokkal több memóriát fogyaszt mint 1 db 100 byte-os, hiszen 100 objektumhoz 100 leíró tartozik, míg ugye 1-hez csak 1... Vagy nagyon benézem ezt?
6

én is így gondoltam.

gex · 2009. Már. 30. (H), 16.15
én is így gondoltam.
5

"Zaj"

Poetro · 2009. Már. 30. (H), 16.07
Ugye itt jórészt olyan képek voltak, ahol rengeteg rajta a "zaj", azaz olyan adat, mit nem használunk fel, ezek voltak a fehér / átlátszó hátterek a képek között, amiket semmire nem használ az oldal, azaz a kép kb 50%-a "zaj", felesleges információ. Ha ezeket a képeket egyesével vágná ki az ember, akkor ugye a "zaj" jórésze (80-90%) eltűnik, és máris jóval kevesebb a memória igény.
7

zaj

gex · 2009. Már. 30. (H), 16.18
ha nagyon sok a zaj, akkor felesleges a sprite. a sprite-ra nem önmagáért van szükségünk. ha nem lehet megoldani hogy bizonyos szint alatt maradjon akkor kár erőltetni. szerintem.
8

Több sprite is segít

Török Gábor · 2009. Már. 30. (H), 17.30
Illetve nem feltétlenül csak egy sprite a szerencsés, sőt. Két sprite-tal már nagyon jó zajmentes képeket lehet készíteni. A poszt szerzője kicsit átesett már a ló túloldalára, ahogy te is írod.
9

A sok fehér területtel is

Fraki · 2009. Már. 30. (H), 19.17
A sok fehér területtel is ugyanannyi a letöltési idő, mint fehér terület nélkül, tehát ezt a részét ugyanúgy megspórolják.

A memóriaigénye lesz nagy, egyrészt mert a memóriában a kép tömörítetlenül tárolódik (tehát itt már számít a fehér terület), másrészt mert ez a tömörítetlen kép X alkalommal kirenderelődik (különböző eltolásokkal meg takarásokkal, de az más kérdés) a canvasra. Az a screencast videó ott elég meggyőző.
10

Szerintem itt a lényeg

Ustak · 2009. Már. 30. (H), 20.33
ez a rész, ezért lázad a comment:

completely unused


tehát olyan képrészek vannak benne, amiket nem használunk. És egyébként igazad van.
11

Nem csak optimalizálás

yaanno · 2009. Már. 31. (K), 11.53
Egy másik szempont lehet, hogy pl. a hoverre változó hátterek, egyéb "mozgó alkatrészek" sprite alapú tervezése során mentesülünk pl. a javascriptes előtöltéstől, illetve a zavaró villanásoktól.