[FF4/Chrome11] Grote sprite wordt niet geladen

[Wiethoofd]

Ik heb een sprite met 2677 afbeeldingen er in om zo dit aantal requests niet te hoeven hebben. De totale sprite is 16px breed en 53540px hoog. Op een andere manier deze sprite maken is niet handig omdat je dan op moet gaan splitsen (in de breedte uitwijken is door het gebruik van de sprite niet praktisch).

Nu wordt de sprite in FF3.6.17, IE8, IE9, Chrome 6, Chrome 9, Opera 11.11 en Safari 5 gewoon getoond, maar in Firefox 4, 5 beta en Chrome 11 wordt de hele sprite niet getoond, laat staan geladen. De sprite als losse afbeelding bekijken werkt ook niet, de headers worden wel opgehaald, dat het een png is met de juiste resolutie, maar meer niet.

Getest in een verse install van FF4.0.1, een FF5b en Chrome 11. Is dit een bug in Firefox 4+ en Webkit of...

Firefox 4 geeft in de foutconsole aan: Error message: Image corrupt or truncated: <link naar plaatje>
Doe ik echter de EXIF info check op regex.info op het plaatje, dan wordt deze wel gewoon opgehaald...

[Voor 12% gewijzigd door Wiethoofd op 21-05-2011 19:59]

[MueR]

Dat ga je niet op kunnen lossen. Zelfs images van 30k pixels hoogte hebben dat probleem al, daar had Tweakers laatst ook last van. Kan er zo even geen bugreport bij halen op Bugzilla, maar het is een bekend browser probleem.

[Wiethoofd]

Maar hoezo werkt het in 'oudere' browsers wel goed dan?

Moet er wel bij zeggen dat de sprite met imagepng gegenereerd is, en daarna via Page Speed in Firebug lossless gecomprimeerd wordt.

---

Bugzilla melding gevonden (?): https://bugzilla.mozilla.org/show_bug.cgi?id=567751

[Voor 18% gewijzigd door Wiethoofd op 22-05-2011 17:43]

[BasieP]

Wiethoofd schreef op zaterdag 21 mei 2011 @ 20:16:
en daarna via Page Speed in Firebug lossless gecomprimeerd wordt.

gewoon uit interesse:
hoe doe je dat? (clientside compressie toepassen in firebug?)
en wat heeft het voor zin?

[Wiethoofd]

Nee, Page Speed is addon voor Firefox Firebug die je website kan analyseren, eventuele optimalisaties voorstelt en een lossless compressed afbeelding voor kan schotelen die je weer op kunt slaan en uploaden om zo voor iedereen de geoptimaliseerde afbeelding beschikbaar te hebben.

---

Verder nog even mobiel getest:
- Android browser op Nexus S => toont de sprite
- Firefox 4.0.1 (mobile) => geen sprite, ook losse afbeelding bekijken werk niet, geeft wel een 'broken image' in het juiste formaat weer...

[OkkE]

Misschien is het in dit geval een idee om de sprite toch op te delen?

Ik ga er vanuit dat de sprite zo hoog is omdat er een aantal gradients/lines/etc. in zitten, waardoor er een hoop niet naast elkaar gezet kan? Misschien een idee om alle icoontjes en plaatjes waar dat wel mee kan in de ene sprite zetten en de rest in een andere?

[BasieP]

Wiethoofd schreef op maandag 23 mei 2011 @ 16:54:
Nee, Page Speed is addon voor Firefox Firebug die je website kan analyseren, eventuele optimalisaties voorstelt en een lossless compressed afbeelding voor kan schotelen die je weer op kunt slaan en uploaden om zo voor iedereen de geoptimaliseerde afbeelding beschikbaar te hebben.

---

Verder nog even mobiel getest:
- Android browser op Nexus S => toont de sprite
- Firefox 4.0.1 (mobile) => geen sprite, ook losse afbeelding bekijken werk niet, geeft wel een 'broken image' in het juiste formaat weer...

het pagespeed verhaal is dus niet relevant.

Dat het ding uit een DB komt in princiepe ook niet, aangenomen dat dit allemaal correct gebeurd (broken images is daar niet bepaald een bevestiging van)
zegt http://redbot.org/ ook dat je plaatje klopt?

ow en exif staat volgens mij in header van afbeelding, dus dat die wel aanwezig zou zijn is niet zo raar.
Wat ik wel vreemd vind is dat jij een png hebt met exif info

[Voor 9% gewijzigd door BasieP op 23-05-2011 17:17]

[Wiethoofd]

Ik wist even niet de benaming van die info Maar alles wat opgehaald wordt klopt:

redbot.org: http://redbot.org/?uri=ht...am%2Ffamfamfam_sprite.png
regex.info: http://regex.info/exif.cg...am%2Ffamfamfam_sprite.png

De file komt niet uit een db, gewoon pic in een map

[R4gnax]

Wiethoofd schreef op zaterdag 21 mei 2011 @ 20:16:
Maar hoezo werkt het in 'oudere' browsers wel goed dan?

Moet er wel bij zeggen dat de sprite met imagepng gegenereerd is, en daarna via Page Speed in Firebug lossless gecomprimeerd wordt.

---

Bugzilla melding gevonden (?): https://bugzilla.mozilla.org/show_bug.cgi?id=567751

Daaruit maak ik op dat het wel eens met hardware accelerated compositing te maken kan hebben. (Zeker aangezien hetzelfde optreedt wanneer Chrome hardware acceleratie gebruikt.)

Videokaarten hebben nog steeds vrij lage maximale texture dimensies. Als je kolosale sprites gaat gebruiken en je browser hier niet goed rekening mee houdt door zulke afbeeldingen intern efficient op te delen in segmenten, dan ga je tegen problemen aan lopen.

Omgekeerd vraag ik vraag me ook af of de overhead voor het tekenwerk niet te groot zou worden wanneer er wel op zo een manier met segmentatie van extreem grote afbeeldingen rekening gehouden moet worden. Het lijkt me dan ook veel slimmer om gewoon je sprite op te delen. Ja, je hebt dan wat meer http requests, maar als je goede caching gebruikt heeft een gebruiker daar maar één keer last van. Je kunt zelfs een appcache manifest gebruiken en daar al je sprites in gooien. Browsers die het ondersteunen kunnen dan alle sprites aggresief pre-cachen op een splash, portal of home pagina.

[Bosmonster]

Het gaat om 2677 afbeeldingen, waaruit ik opmaak dat het om iconen gaat. Dan vraag ik me sowieso af of daar niet iets efficienters voor te vinden is dan ze domweg onder elkaar te plaatsen.

Zo kun je kleurvariaties misschien met CSS oplossen, en in het geval van iconen ook gewoon iconen naast elkaar plaatsen in de sprite.

[Voor 26% gewijzigd door Bosmonster op 24-05-2011 11:23]

[crisp]

684KB om een paar requests uit te sparen; da's zeker niet echt efficient imo... (of gebruik je echt alle 2677 icons op 1 pagina?)

wat R4gnax zegt klopt trouwens; uit eigen ervaring weet ik dat het werken met kleinere sprites voor een browser veel efficienter is. In de tijd dat ik DHTML Lemmings heb gemaakt had ik in eerste instantie ook alles in 1 sprite zitten, maar dat bleek (vooral bij de animatie) toch veel zwaarder te zijn voor de browser dan losse sprites per actie.

Nog een voordeel van losse sprites is dat je kan groeperen op bijvoorbeeld kleur waardoor je kleinere bestanden kan maken (indexed colors bijvoorbeeld - nu zit je vast aan een 32-bit PNG met alpha-channel).

Last but not least; ik denk ook dat texture-limieten van je video hardware hier roet in het eten gooit. Kortom: opdelen die zooi.

[Voor 3% gewijzigd door crisp op 24-05-2011 11:24]

[Wiethoofd]

Het is een overzicht van alle 2677 iconen, ik zou kunnen kijken om de sprite per letter op te delen, maar dan zit je nog rond de 100 afbeeldingen per sprite..

De hardware is absoluut niet de limiterende factor, getest op een eerste generatie iPod Touch, Nexus S en verschillende computerhardware (ati/nvidia) en dus crossbrowser. Firefox 4 (en mobile) is de enige die de sprite niet toont op alle platformen/hardwarecombinaties.

[WeeJeWel]

En als je hem breder, en dus minder hoog maakt?

[Wiethoofd]

Dan moet de boel omgezet worden omdat alles nu getoond wordt in een padding-left: 20px, breder maken resulteert dan in 2 icoontjes in de <a> als ik de linkerrij wil bekijken.

[BtM909]

Wiethoofd schreef op dinsdag 24 mei 2011 @ 11:50:
Het is een overzicht van alle 2677 iconen, ik zou kunnen kijken om de sprite per letter op te delen, maar dan zit je nog rond de 100 afbeeldingen per sprite..

Je hebt het over iconen ala avatars die je wilt laten zien? Kan je even kort toelichten hoe je dit wilt toepassen en hoe dat op zo'n pagina eruit ziet

De hardware is absoluut niet de limiterende factor, getest op een eerste generatie iPod Touch, Nexus S en verschillende computerhardware (ati/nvidia) en dus crossbrowser. Firefox 4 (en mobile) is de enige die de sprite niet toont op alle platformen/hardwarecombinaties.

Denk niet dat 't gaat om hardware an sich, maar meer hoe Firefox met die hardware(acceleratie) omgaat.

---

Het is iig een bekend probleem bij Mozilla en hoop dat 't ook wordt opgelost (liep er tegenaan bij een andere toepassing dan sprites).

[RobIII]

BtM909 schreef op dinsdag 24 mei 2011 @ 11:59:
[...]

Je hebt het over iconen ala avatars die je wilt laten zien? Kan je even kort toelichten hoe je dit wilt toepassen en hoe dat op zo'n pagina eruit ziet

Nee; hij heeft 't over http://www.famfamfam.com/...lk/previews/index_abc.png maar dan alle icons onder elkaar in 1 lange sliert en zonder tekst

[Voor 9% gewijzigd door RobIII op 24-05-2011 12:01]

[Wiethoofd]

@RobIII, maar dan een stukje uitgebreider.

---

Cascading Stylesheet:

li a {
 background: url('famfamfam_sprite.png') left 0 no-repeat;
 padding: 2px 0 2px 22px;
}

Met de als html waar per icoon de background-position-y met -20px gewijzigd wordt.

HTML:

<li><a href="icons/accept.png" title="accept.png" target="_blank" style="background-position: 2px 1px;">accept</a></li>

[crisp]

Wiethoofd schreef op dinsdag 24 mei 2011 @ 11:50:
[...]
Firefox 4 (en mobile) is de enige die de sprite niet toont op alle platformen/hardwarecombinaties.

Hij geeft bij mij ook problemen in IE9; met inzoomen zie ik hem wel verschijnen, maar een tikje verder inzoomen verdwijnt het plaatje weer.

[Bosmonster]

@Wiethoofd: dat is sowieso niet echt een handige manier om iconen als sprites toe te passen... Als je tekst op 2 regels valt bijvoorbeeld (of je vergroot je tekst), dan krijg je ook herhaling. Je levert flink in op flexibiliteit.

Beter is je iconen in een span met display: inline-block te mikken voor de tekst. Dan ben je ook vrij in hoe je je sprite indeelt. En als je wilt kun je die alsnog wel met een position absolute en padding, absoluut links plaatsen. natuurlijk.

Dan kun je die spans ook nog eventueel voorzien van een tekst-versie van het icoon voor accessibility.

[Voor 27% gewijzigd door Bosmonster op 24-05-2011 12:18]

[Wiethoofd]

De tekst over 2 regels is afgevangen met een white-space: nowrap en een overflow-x: hidden op de li. Daarnaast: 'There are 5378 DOM elements on the page', een extra span om een compactere sprite weer te geven levert dan ruim 8k DOM elementen op...

[R4gnax]

crisp schreef op dinsdag 24 mei 2011 @ 12:05:
[...]

Hij geeft bij mij ook problemen in IE9; met inzoomen zie ik hem wel verschijnen, maar een tikje verder inzoomen verdwijnt het plaatje weer.

Lap, daar heb je het al: precies wat er ook in Chrome met hardware acceleratie gebeurt bij extreem grote afbeeldingen. De common factor bij alle 3 (IE9, Chrome en FF4) is hardware acceleratie, dus het kan haast niets anders zijn dan een probleem met beschikbaar videogeheugen of texture dimensies.

Wiethoofd schreef op dinsdag 24 mei 2011 @ 12:20:
De tekst over 2 regels is afgevangen met een white-space: nowrap en een overflow-x: hidden op de li. Daarnaast: 'There are 5378 DOM elements on the page', een extra span om een compactere sprite weer te geven levert dan ruim 8k DOM elementen op...

Om dat even te relativeren: de DOM Level 3 Events Specification bevat ca. 20000 DOM elementen en dat is voor geen enkele hedendaagse browser een probleem.

[Voor 34% gewijzigd door R4gnax op 24-05-2011 12:41]

[MueR]

Er wordt hier door iedereen gezegd dat het een inefficiente manier van werken is, waarbij er ook nog wat browser problemen zijn. Toch blijf je koppig volhouden dat het perse zo moet. Weet jij iets wat de professionele webdevvers hier niet weten?

Ik vraag me trouwens nog steeds af waarom je al die icons op 1 pagina moet hebben? Je kan toch gewoon die preview van famfamfam zelf laten zien? Desnoods kap je die kolommen af?

[Wiethoofd]

R4gnax schreef op dinsdag 24 mei 2011 @ 12:24:
Lap, daar heb je het al: precies wat er ook in Chrome met hardware acceleratie gebeurt bij extreem grote afbeeldingen. De common factor bij alle 3 (IE9, Chrome en FF4) is hardware acceleratie, dus het kan haast niets anders zijn dan een probleem met beschikbaar videogeheugen of texture dimensies.

Dan zou het uitschakelen van hardware acceleration in FF4 mij dus gewoon m'n afbeelding voor moeten schotelen, dit gebeurt echter niet.

---

MueR schreef op dinsdag 24 mei 2011 @ 12:49:
Er wordt hier door iedereen gezegd dat het een inefficiente manier van werken is, waarbij er ook nog wat browser problemen zijn. Toch blijf je koppig volhouden dat het perse zo moet. Weet jij iets wat de professionele webdevvers hier niet weten?

Ik zeg niet dat het de beste manier is, maar in de huidige opzet werkt het dus niet crossbrowser omdat hardwareacceleratie roet in het eten gooit.

Ik vraag me trouwens nog steeds af waarom je al die icons op 1 pagina moet hebben? Je kan toch gewoon die preview van famfamfam zelf laten zien? Desnoods kap je die kolommen af?

Het is een overzicht van 4 famfamfam iconsets gecombineerd, die ben ik nog nergens anders tegengekomen, niet als overzicht, laat staan complete download.

Het overzicht van famfamfam.nl is inefficiënt omdat alle plaatjes als losse afbeelding opgehaald moeten worden, vandaar dat ik met een sprite alles wou tonen, alles is te doorzoeken en klikbaar zonder dat je alle afbeeldingen moet gaan laden.

[Bosmonster]

Als het 4 sets zijn, maak er dan 4 sprites van. Klaar.

Hoewel, dan zijn ze nog steeds belachelijk hoog. Nou ja, antwoorden genoeg gegeven iig. Opsplitsen die hap, of naast elkaar zet met een andere CSS.

[Voor 58% gewijzigd door Bosmonster op 24-05-2011 13:06]

[Wiethoofd]

Uiteindelijk de pagina omgegooid en de <span> toegevoegd en de sprite aangepast naar voorlopig elke letter een eigen kolom. Dit resulteert in een afbeelding met een maximum hoogte van 8060px welke wel getoond wordt door Firefox 4 en alle andere browsers.

De sprite z'n filesize is wel meteen 2x zo groot, dus daar moet nog even een nieuwe versie voor uitgedokterd worden; wat waarschijnlijk een 1000x1000 en een beetje sprite wordt (52x52 icons)

[RobIII]

Wiethoofd schreef op vrijdag 10 juni 2011 @ 01:39:
Uiteindelijk de pagina omgegooid en de <span> toegevoegd en de sprite aangepast naar voorlopig elke letter een eigen kolom. Dit resulteert in een afbeelding met een maximum hoogte van 8060px welke wel getoond wordt door Firefox 4 en alle andere browsers.

De sprite z'n filesize is wel meteen 2x zo groot, dus daar moet nog even een nieuwe versie voor uitgedokterd worden; wat waarschijnlijk een 1000x1000 en een beetje sprite wordt (52x52 icons)

offtopic:
http://meukje.nl/famfamfam/ -> Als je dan toch aan 't bitneuken bent: compress.png hoeft natuurlijk niet geladen te worden als diezelfde image ook in de sprite zit Ook de 'class="icon"' op élke span is natuurlijk "duur", waarom zet je die CSS niet gewoon op de span zelf? Datzelfde geldt ook voor 't (deprecated overigens) target attribuut; dat kun je met een klein stukkie JS of een base-target oplossen. En zo kun je nog wel wat kb's besparen
Oh, en als ik toch bezig ben: je title tag bevat een html entity die niet klopt

[Voor 26% gewijzigd door RobIII op 10-06-2011 02:27]

[Wiethoofd]

RobIII schreef op vrijdag 10 juni 2011 @ 02:02:

offtopic:
http://meukje.nl/famfamfam/ -> Als je dan toch aan 't bitneuken bent: compress.png hoeft natuurlijk niet geladen te worden als diezelfde image ook in de sprite zit Ook de 'class="icon"' op élke span is natuurlijk "duur", waarom zet je die CSS niet gewoon op de span zelf? En zo kun je nog wel wat kb's besparen

offtopic:
Stom, had ik eerst wel, maar omdat m'n sprite na omzetting nog niet helemaal werkte tijdelijk gewijzigd suggestie mbt de class en base target ook meegenomen

[alex3305]

Even een kleine toevoeging. De sprite wordt wel correct geladen in Google Chrome 12. Hierin is het dus klaarblijkelijk opgelost.