Egy Firefox teljesítménybug és workaroundja
eszpee cikke a Torokgeek rovatból, 2008. augusztus 4. hétfő, 17:14 | 24 hozzászólás
A napokban újraterveztem a fotóblogom, és ennek kapcsán egy olyan problémába futottam, ami bár tényleg elég specifikus, talán másnak is okozott már fejfájást. Arról van szó, hogy az archívum oldalon többek között kirakom az összes eddigi város linkjét, ahol fotóztam, valahogy így:
Ez elég könnyen meg is van, egyetlen egy gond van vele: a legfrissebb 3.0.1-es Firefox alatt a linkek hoverje (a fölévitt kurzor hatására történő háttérváltozás) valami elképzelhetetlenül lassú, nézzétek. Ráadásul Windows, OSX és Linux alatt is, csak hogy legalább egységes legyen a dolog. Induláskor hagytam a fenébe, de most nekiugrottam, és sikerült is ha nem is megmagyarázni, legalább elhárítani a problémát.
De lássuk először, hogy mi van a háttérben. Az oldalnak ez az oszlopa egy egyszerű számozatlan lista, tehát <li> elemek egymásutánja, amiket egy display: inline css utasítással szépen egymás mellé igazítok. Ez megy is rendesen Operában, IE alatt sincs semmi gond, csak a Firefox lassul be tőle rettenetesen.
Első megoldási ötlet, hogy hátha ez az egy sorba alakított rengeteg listaelem okoz gondot, hagyjuk a menüzések elegáns megoldását, legyen egy sima bekezdés az egész, szóközökkel elválasztva. Íme. Mint az látható, semmi változás, FF alatt ugyanúgy csigalassú az egész, IE és Opera alatt ugyanúgy szép gyors.
Fejvakarás. Talán az okozza a gondot, hogy egy darab bekezdésben van rengeteg link, lehet, hogy ha széttördelném, mondjuk tucatnyi város után jönne egy sima fapados <br />, akkor jó is lenne? Kis matatás után igen, sokkal gyorsabb Firefox alatt az egérrel mászkálás, cserébe a véletlenszerűen elszórt sortöréseknek hála sajnos elég rondák is vagyunk:
Ekkor jön a homlokracsapós pillanat: hogy lehet az, hogy a szomszédos középső hasábban nagyjából ugyanennyi link szépen működik az inline-os lista módszerrel?! Két dolog lehet, vagy a különböző float pozícióból következik ez (amit nem nagyon tartok valószínűleg), vagy az egyes elemek változó mérete miatt gyorsabb a hover. Bár a Movable Type nem támogatja a kategóriákon belüli postok száma alapján történő csoportosítást (míg a szomszédos címkefelhőt szépen hozza), azért egy kis template-hackelgetéssel hamar megvan a végleges megoldás, ami szép is, gyors is, és megy is minden böngészőben.
Érdekes mindenesetre. Ha valakinek van bármilyen ötlete, mi okozhatja ezt, már csak kiváncsiságból is meghallgatnám. Addig is az általános útravaló: ha nagyon hosszú inline szövegben sok link jön egymás után, teszteld az oldalad Firefoxban, és ha nagyon lassúnak találod, vagy váltogasd az egyes elemek méreteit, vagy ha ez nem megoldható, helyezz el pár sortörést a szövegben.
Ennyit mára a HTML és a CSS világából.
Update: Naugye, hogy megérte megírni: teamtom kommentjéből úgy tűnik, hogy meglepő módon a small-caps font a felelős a lassúságért! Remélem sikerül hamar javítani, addig is kerüljétek a kicsi nagybetűket.
Update 2: közelítünk, úgy tűnik bármilyen szövegstílus-váltás előhozza a lassulást!
Update 3: azt hiszem, feladom a téma szakavatott kommentálását, mindenesetre kövessétek a hozzászólásokat, van jópár megoldási lehetőség. Köszi az olvasóknak!
Megosztások Facebookon
Hozzászólások
Eddigi hozzászólások (24)
, 2008. augusztus 4. hétfő, 17:34 (#)
Szép megoldás! :) Az open source fejlesztés apró sorjáinak értő kiküszöbölése után pedig most egy hasonlóan meggyőző megoldást várunk az elmaradt fotók pótlására. A helyük már klafa!
, 2008. augusztus 4. hétfő, 17:35 (#)
Ejj, mennyire nem fogják érteni a hozzászólásodat nemsokára! Meglásd! :)
, 2008. augusztus 4. hétfő, 17:55 (#)
Érdekes. A feladatkezelőm szerint amikor a kurzort mozgatom viszonylag gyorsan a linkek fölött itt: http://bp.underground.hu/browse-list.html nos ekkor a középső oszlopban ~25% CPU-ra megy fel ~5%-ról, a jobb oldali oszlopban 30% fölé megy. (Erős gép, nem statisztikai hibahatáron belüli érték.) Valami gond van, ez tény.
Most írok a bugzillába, úgyh a browse-list.html-t légyszi ne lődd le.
, 2008. augusztus 4. hétfő, 18:20 (#)
Oh, csak nem teszek egy szalmaszálat a közösségi kazalba! Köszi, marad az összes hivatkozott link! :)
, 2008. augusztus 4. hétfő, 22:38 (#)
Látni már láttam én is ezt a hibát, de azt hittem, hogy nálam van a hiba. De ezek szerint nem.
, 2008. augusztus 4. hétfő, 22:45 (#)
Firefox 3.0 alatt is csinálja
mondok egy érdekeset/durvát:
bp.css 208.sor
#archive-tag, #archive-category, #archive-date {
font-variant:small-caps;
}
kikapcsoltam Firebuggal ezt a részdefiníciót, és a döglődés megszűnt
biztos, hogy durva bug, érdemes jelezni
, 2008. augusztus 5. kedd, 00:11 (#)
(6), ja, akkor nincs gond, csak a firefox jelezte eszpeének, hogy sok a csel.
, 2008. augusztus 5. kedd, 08:49 (#)
Érdekes, az asztali gépemen (Core Duo) tapasztalom a jelenséget, a notebookon (Core2 Duo) már nem. Upgrade your hardware, guys (;
, 2008. augusztus 5. kedd, 09:51 (#)
hehe.
web hat pont nulla.
, 2008. augusztus 5. kedd, 10:08 (#)
(7 - ervin) én úgy értettem, hogy
- ha nem esszenciális része a small-caps a designnak, akkor megvan a gyors megoldás
- másrészt pedig jól behatárolható a hibajelenség, így talán a(z durva, és mivel nem gyakori különösebben gyakori a small-caps, ezért alattomos) bugot javítani is könnyebb lesz a mozillás srácoknak
, 2008. augusztus 5. kedd, 10:44 (#)
igen, én mindenképpen köszönöm a jelzést, nekem eszembe se jutott a smallcaps-re gyanakodni. update-elem a postot, viszont a probléma nálam már nem áll ugye. köszi mégegyszer!
, 2008. augusztus 5. kedd, 11:05 (#)
Nem értek egyet a small-caps hibáztatásával. Egy saját oldalamon, melyet nem áll módomban közreadni, ugyan ez a hiba előjött, small caps nélkül. Ha beállítottam egy képek is háttérnek, elképesztő méreteket öltött a lassulás.
, 2008. augusztus 5. kedd, 11:05 (#)
erenon, és mivel sikerült megoldani?
, 2008. augusztus 5. kedd, 11:12 (#)
Egyelőre semmivel. A képet hagytam, mert csupán egy apró design elem volt, és a FF3 már sokkal enyhébb mértékben mutatja a tünetet. Mindenesetre idáig én is azt hittem, hogy egyedül vagyok a problémával... remélem a bugreport segítő kezekbe jut.
, 2008. augusztus 5. kedd, 11:36 (#)
Még Firefox 3.1 alfa 2 alatt is rosszalkodik, érdekes egy bug lesz ez, megyek én is vizslatom bugzillát :)
, 2008. augusztus 5. kedd, 12:22 (#)
Nem kifejezetten a small-caps érték a bűnös, ez így félrevezető; bármely, a szöveg stílusát módosító tulajdonság megadása esetén hasonló lesz az eredmény. Pl. a
#archive-tag, #archive-category, #archive-date { text-transform: capitalize }
vagy más ruleok ugyanezt eredményezik.
, 2008. augusztus 5. kedd, 12:29 (#)
Köszi yaanno, frissítettem a postot!
, 2008. augusztus 5. kedd, 12:44 (#)
Még mindig nem érzem pontosnak, ugyanis én tapasztalom a problémát mindenféle text-transform nélkül. Ha lesz egy kis időm, feldobok egy herélt példányt, ami nekem mutatja a problémát.
, 2008. augusztus 5. kedd, 12:44 (#)
Nemcsak Firefox probléma, az egész gecko família szenved ettől - gondoltam. De nem, Epiphany ugyanezt produkálja, de a Galeon nem (lehet, hogy egy korábbi gecko változatot használ?). (Linux)
, 2008. augusztus 5. kedd, 12:57 (#)
#erenon csak egy példa volt; de tessék, itt egy egyszerűsített változat:
http://yaanno.googlepages.com/eszpee.html
, 2008. augusztus 5. kedd, 13:29 (#)
erenon, yaanno, igazatok van, nem a small-caps a bűnös, viszont jó kis indikátor
f*sza kis bug ez :)
érdekes, yaanno file-jába a kérdéses def-ba beírva a letter-spacing: 1px; -et, az is megszünteti (áthidalja, megpatkolja) a bugot
sőt, bármely 0-tól különböző letter-spacing érték megfelel, csak pont a 0 nem!
, 2008. augusztus 5. kedd, 13:32 (#)
Nos, annyit sikerült kiderítenem, hogy *bármely* inline elemre font-variant v. text-transform tulajdonságot állítva, a *hover* esemény overheadet okoz (a megfelelő feltételek mellett, ld. példák).
Egyébként FF3 alatt az elemnek display: inline-block értéket beállítva a probléma eltűnik.
Nem világos, hogy hoverkor mit számolgat az engine, ennyire nem ismerem a Mozilla lelkivilágát, de mintha az elemek stílusa mellett pozíciókat is kalkulálna, csak tippelek.
, 2008. augusztus 5. kedd, 19:43 (#)
probaltam a li elementnel az inline helyett inline-table -t es ott jol mukodik :)
csak ki tudja mennyire tamogatja a tobbi bongeszo
, 2008. augusztus 6. szerda, 14:25 (#)
https://bugzilla.mozilla.org/show_bug.cgi?id=449046
Itt van a Bugzilla report, eztet érdemes figyelemmel kisérni, hátha előjön vki egy javítással.
Menü
-
Listák
» Filmek
» Könyvek
» Éttermek - térképpel!
» Receptek
» Mobil videók -
Feedek
A Kispad-feednek most
olvasója van. Szeretnél közéjük tartozni? Ezen az oldalon mindent elmagyarázunk.
Impresszum
Az oldal tetejére | Szerzők, tudnivalók, feedek | sesblog és Kispad © 2003-2010 ervin, eszpee, stsmork