Som Plus-medlem får du: Tillgång till våra Plus-artiklar | Egen blogg och Portfolio | Fri uppladdning av dina bilder | Rabatt på kameraförsäkring och fotoresor | 20% rabatt på Leofoto-stativ och tillbehör | Köp till Sveriges mest lästa fototidning Fotosidan Magasin till extra bra pris.

Plusmedlemskap kostar 349 kr per år

Annons

Nya Fotosidan.se långsam?

Produkter
(logga in för att koppla)
clindh skrev:
Måste jag köra en burk med ATI-videokort?

Nej. Jag har nvidia grafik och sidscroll är supersegt. Varje litet snäpp på scrollhjulet orsakar 100% processorbelastning på min AMD 64. Webbläsaren jag använder är Seamonkey (jag låter den dock presentera sig som Firefox eftersom min bank sysslar med namnmagi).

Jag misstänker att problemet ligger i css-koden, kan t ex. vara någon centrering av innehåll som orsakar beräkningskonflikter i kombination med marginaler eller padding. Med en lokal kopia av en problemsida, komplett med all kod, bilder osv, där man kan härja fritt i koden. torde problemet kunna sorteras ut rätt snabbt (dock omöjligt om man inte upplever problemet).
 
Förstasidan funkar bra nu, men forumen är fortfarande sega. Sorry, fel. För 10 sekunder sedan funkade förstasidan bra, men när jag nu öppnade fotosidan.se i en ny tabb så var förstasidan seg på nytt igen. Är det något innehåll som förändras random serverside? Jag kan tänka mig att det kan vara nåt i reklamen som inte är samma från gång till gång.
 
Jag är fullständigt oteknisk på denna nivån så ha lite överseende, om jag är helt ute och cyklar i mitt resonemang. Jag försöker inte ifrågasätta någons teknikkunskaper eller diskutera teknik utan bara försöka förstå logiken i resonemanget.

Är logiken alltså att den setup du har är en korrekt uppsättning utan några fel, och all uppkommen seghet därför direkt kan relateras till FS kod, oavsett om vår framsida har validerad CSS och HTML (eftersom du inte stöter på några andra platser på webben där din setup får probem) och att en Googleslagning på Problem XaaNoOffscreenPixmaps ger 12.000 träffar? Och medan 99% (eller vad det nu var) av alla andra besökare som inte upplever segheten då har fel i sin setup som gör att de inte upplever segheten?
 
Jag har aldrig fattat vad denna tråden är till för? Jag har aldrig upplevt fotosidan som långsam..
 
elmfeldt skrev:
Är logiken alltså att den setup du har är en korrekt uppsättning utan några fel, och all uppkommen seghet därför direkt kan relateras till FS kod, oavsett om vår framsida har validerad CSS och HTML (eftersom du inte stöter på några andra platser på webben där din setup får probem) och att en Googleslagning på Problem XaaNoOffscreenPixmaps ger 12.000 träffar?

Det där med buggar aldrig så enkelt, nu validerar koden enligt Christer, så då kan ni utesluta det. Det är ett stort och mycket grundläggande steg. Men validerande kod innebär inte att det fortfarande kan finnas konflikter och rena motsägelser, saker som en klientkonfiguration hanterar fint medan en annan inte fixar det. Jämför validerande kod med rättstavning. Att allt är rättstavat innebär inte att det inte kan finnas syftningsfel och liknande som gör att läsaren tolkar budskapet fel.

Det kan vara fel i min (och uppenbarligen även andras) webbläsare, hårdvara, eller någon kombination av både och. Innan man ens kan svara på detta så måste man sortera ut problemet på ett reproducerbart sätt. Ingen kan fixa problemet, oavstt var det ligger, om inte problemet kan reproduceras. Det är också besvärligt när det gått så lång tid och många ändringar blivit gjorda, såvida ni inte har versionshantering och kan backa i den tills man hittar exakt när problemet introducerades.

För övrigt så har jag upplevet problemet med ett antal olika konfigurationer på både min laptop och min stationära maskin, med firefox på den ena och Seamonky på den andra, dessutom olika versioner av X-grafikserver.

Ett tips kan vara om ni lägger ut ett zip-arkiv på en komplett sida av denna tråd, med bilder css och allt. Då har ni åtminstone chansen att någon som upplever problemet ids leta reda på det åt er (eftersom ni inte kan uppleva det). Men upphovsrätt kanske förbjuder er att göra detta?
 
Du citerar lite märkligt och ditt svar ger inte mer ljus på din logik där all skugga verkar falla på FS och alla andra som inte har ditt problem. Du utesluter meningen "Och medan 99% (eller vad det nu var) av alla andra besökare som inte upplever segheten då har fel i sin setup (eftersom det finns räknefel hos oss) som gör att de inte upplever segheten?. Eller hur är logiken med det?

Och att framsidan är ok så länge du kör i en flik, men så fort du öppnar i en ny flik så bör slutsatsen vara att FS har problem serverside, och ingen tanke skänks till huruvida din klient hanterar flikar?

Och var är logiken i att vi skall zippa och versionhantera om vi inte kan repoducera problemet, och isåfall skall lita på att din klient är 100% samma setup sen du stötte på problemet? Dessutom en setup som i stunden funkar bra men i en ny flik får problem?
 
elmfeldt skrev:
Jag är fullständigt oteknisk på denna nivån så ha lite överseende, om jag är helt ute och cyklar i mitt resonemang. Jag försöker inte ifrågasätta någons teknikkunskaper eller diskutera teknik utan bara försöka förstå logiken i resonemanget.

Är logiken alltså att den setup du har är en korrekt uppsättning utan några fel, och all uppkommen seghet därför direkt kan relateras till FS kod, oavsett om vår framsida har validerad CSS och HTML (eftersom du inte stöter på några andra platser på webben där din setup får probem) och att en Googleslagning på Problem XaaNoOffscreenPixmaps ger 12.000 träffar? Och medan 99% (eller vad det nu var) av alla andra besökare som inte upplever segheten då har fel i sin setup som gör att de inte upplever segheten?

Det hjälper inte att du försöker skylla problem på användarna, vi är flera personer som upplever en tröghet på just fotosidan.se och INGEN, jag repeterar, INGEN annan sida utan ENBART, jag repeterar igen, ENBART fotosidan.se. Jag har ALDRIG, jag repeterar, ALDRIG upplevt någon som helst seghet på sidor (såvida det inte har berott på att de har varit tungrodda i största allmänhet, vilket fotosidan.se inte är).

Även om du är oteknisk är du säkerligen läskunnig och dessutom troligtvis mer begåvad än medelsvensson med tanke på att du är en av dem som ligger bakom hela fotosidan.se men ändå missar du en mycket viktig poäng som Magnus Stålnacke påpekar; att koden blir validerad betyder lika lite i vissa sammanhang som att Word inte hittar några stavfel. Skulle du skriva in manuset till "Fagott" (http://www.youtube.com/watch?v=55fue8khEf8) skulle Word inte klaga på några stavfel, ändå är det totalt obegripligt trots att visa bitar är på rätt plats.

Om ni lägger ut koden till allmän beskådan kan de som upplever problem och är kunniga inom xhtml och css själva kunna identifiera felet (hört talas om öppen källkod?)

Kan också påpeka att XAANoOffscreenPixmaps kan få vissa ATI-kort (vad jag vet om, problemet gäller säkerligen fler kort) att krascha istället för att underlätta surfandet på fotosidan.se, uppenbarligen inte den mest smidiga lösningen...
 
Ja nu försöker jag som sagt inte diskutera teknik eftersom jag inte har något att komma med där, utan bara logiken.

Så logiken i det är att FS är rättstavad, men mumbo-jumbo, vilket du inte fattar men 99% (eller vad det nu var) fattar, så är det de 99% som har fel och också borde läsa mumbo-jumbo?
 
Danlo skrev:
Jag har aldrig fattat vad denna tråden är till för? Jag har aldrig upplevt fotosidan som långsam..

En vanlig kombination av webbläsare och OS (*) ger problemet vi diskuterar. Om du inte ser problemet är allt bara bra för din del, och du kan sluta läsa om du vill.

Per.

*) Linux och Firefox i varierande smaker.
 
elmfeldt skrev:
Ja nu försöker jag som sagt inte diskutera teknik eftersom jag inte har något att komma med där, utan bara logiken.

Så logiken i det är att FS är rättstavad, men mumbo-jumbo, vilket du inte fattar men 99% (eller vad det nu var) fattar, så är det de 99% som har fel och också borde läsa mumbo-jumbo?

Ungefär så, förutom att "du" borde bytas ut mot "din dator".

Ni skulle kunna lösa problemet genom att tillkännage att FS inte stödjer Firefox under Linux, så vore saken ur världen. Så länge ni inte gjort så (eller löst problemet tekniskt) kommer gnället att fortgå, gissar jag.

Per.
 
elmfeldt skrev:
Så logiken i det är att FS är rättstavad, men mumbo-jumbo, vilket du inte fattar men 99% (eller vad det nu var) fattar, så är det de 99% som har fel och också borde läsa mumbo-jumbo?

Det är inte jag som försöker läsa fulkoden ni har åstadkommit utan min webbläsare som är komplierad för Linux som försöker läsa den men som inte förstår den.

Det känns som att FS försöker idiotförklara de som upplever problemet för att slippa rätta till det.

perstromgren skrev:
Ni skulle kunna lösa problemet genom att tillkännage att FS inte stödjer Firefox under Linux, så vore saken ur världen.

Med tanke på FS attityd känns det som att den lösningen är mest aktuell...
 
Det var en analogi för att förenkla formuleringen av logikproblemet.

Jag försöker inte idiotförklara någon utan sätta lite perspektiv på felrapporteringen och logiken i den. Den känns väldigt ensidig och inte heller särskilt homogen eller tydlig pekande i ngn riktning. Inget snack om att vi inte stödjer er setup idag, men att vi skulle vara den enda sajten där liknande fel har rapporteras och att man med 100% säkerhet kan säga att det bara är hos oss felet ligger känns magstarkt. Likaså förstår jag inte att det inte finns ngn tillstymmelse till självkritik från ni som rapporterar. Ni är ju en minoritet som har ett problem, som andra inte har. Säger det inget om er setup!?

Att vi inte skulle bry om ert problem är ju inte heller sant. Det finns ju flera inlägg från oss där vi försöker isolera problemet. Tyvärr har vi inte lyckats hitta lösningen.
 
elmfeldt skrev:
Ni är ju en minoritet som har ett problem, som andra inte har. Säger det inget om er setup!?

Det har vi ju redan konstaterat! Folk som använder Firefox och Linux (speciellt drabbat är Ubuntu-användarna) är det som råkar ut för detta problemet och ingen av oss har råkat ut för något liknande på någon annan sajt. Därmed har vi kunnat isolera problemet till något på FS som inte Firefox komplierat för Ubuntu (vilket är den i särklass vanligaste Desktop-distributionen) klarar av att hantera.
 
Om jag skulle söka efter liknande felrapporter för att försöka hitta en lösning, vad skulle du använda för sökfråga / sökord i Google?
 
elmfeldt skrev:
Du citerar lite märkligt och ditt svar ger inte mer ljus på din logik där all skugga verkar falla på FS och alla andra som inte har ditt problem. Du utesluter meningen "Och medan 99% (eller vad det nu var) av alla andra besökare som inte upplever segheten då har fel i sin setup (eftersom det finns räknefel hos oss) som gör att de inte upplever segheten?. Eller hur är logiken med det?

Jag uteslöt det där om 99% eftersom det knappast leder någon vart, men om du vill så kan vi gå ned på den nivån... 99% av alla sajter scrollar hur fint som helst, men inte fotosidan, detta dessutom under 6 månaders tid trots att admin vet om det. Förstår du nu vilken pajkastning det leder till? Knappast konstruktivt.

Man kan också lätt vända på det och göra en sida för FS besökarunderlag som använder de standardiserade css-reglerna "max-width" och "min-width" och kanske semi-trasparenta png-bilder, och då peka på att 99% av besökarna har trasiga webbläsare. Man skulle då bevisligen tom. ha rätt i påståendet, men hur konstruktivt är det?

Och att framsidan är ok så länge du kör i en flik, men så fort du öppnar i en ny flik så bör slutsatsen vara att FS har problem serverside

Nej, där missförstod du mig. Det har inget med flikarna att göra, utan att samma sida inte alltid orsakar samma problem vid olika besök, och detta för att sidan ändrats mellan besöken. I detta fall tror jag att det var olika reklambilder vid de två olika besöken. Tyvärr hade jag inte kvar den fungerande versionen och kunde jämföra med den tröga, så jag gissar bara. Jag var ju fsaktiskt på väg att rapportera att förstasidan funkade fint, men bestämde mig att kolla en gång till, men då var problemet tillbaks.

Och var är logiken i att vi skall zippa och versionhantera om vi inte kan repoducera problemet

Efterson ni inte kan reproducera problemet, så har ni inte möjlighet att göra något åt det. Koden måste komma i händerna på någon som både upplever problemet och kan prova sig fram med förändringar i koden för att därigenom hitta vad som orsakar det. Först när detta är gjort så kan man börja spåna i hurvida det är en bugg i webbläsaren eller om den ligger sidans html, css eller skriptkod. Det kan också vara en kombination av alla tre.

Versionshantering är för övrigt något väldigt praktiskt vid all utveckling. Detta i synnerhet om man är många som simultant arbetar på samma kod. Det är dock inte så vanligt att det används för hemsidor, och det beror nog mest på att hemsidesnickare av tradition inte använder det eftersom webbsidor är så otroligt simpelt jämfört med riktiga program. Att testa någon förändring i en webbläsare handlar ju bara om att klicka "reload", med program så måste användare runt om i världen med sina olika konfigurationer ladda hem koden, kompilera den, installera det kompilerade programmet och sedan testa. Då är det väldigt praktiskt att varje liten förändring har sin egen revision, för om något problem dyker upp så kan testaren backa revision för revison tills problemet försvinner, och då har man hittat var det introducerades och kan jobba därifrån. Dessa fördelar kan man lika gärna nyttja för kod till hemsidor. Men som sagt, väldigt få gör det. Det är nästan bara de som samtidigt har programprojekt hostade på sourceforge eller savannah som nyttjar det för sina projekts hemsidor, men då är de ju också van vid det från programutvecklingen.

Nåja ett liten grej på en sida som normalt inte orsakar problem, kan i kombination med andra helt korrekta saker orsaka bekymmer. Ja det behöver inte ens vara en bugg, ni kan ha prickat in en "feature" som de vanligaste webbläsar konfigurationerna helt enkelt inte kan, och därmed inte får problem av. Jag skrev lite om detta i mitt allra första inlägg inlägg i denna tråd (första sidan).

Om jag skulle söka efter liknande felrapporter för att försöka hitta en lösning, vad skulle du använda för sökfråga / sökord i Google?

Logiskt fel. Du kan givetvis inte formulera en fråga när du inte vet vad du skall fråga efter. Du vet ju inte vad felet består i. Endast den som med vett o vilja kan trigga fram felet har möjlighet att lokalisera det. Först då kan en fråga formuleras, och först då kan någon eventuellt ge ett svar.

Det finns bara ett ställe att leta efter problemet, och det är i fotosidans html, css och skriptkod. När problemet är hittat, då kan det finnas anledning att ta till google. Men när man hittat problemet, och kan beskriva det så detaljerat att näste man kan reproducera det (såsom en buggrapport bör se ut), då har man oftast också hittat lösningen och behöver inte googla.

Men när css-koden tillåtits att svälla såsom den gjort på FS, då är det ett jättejobb för en utomstående att försöka sätta sig in i koden. Ja det är faktiskt betydligt lättare att koda ihop en helt ny sida med liknande utseende än att sätta sig in någon annans kod, i synnerhet då om den är dåligt/magert kommenterad, vilket också ofta är fallet med hemsideskod till skillnad från programkod som ibland kan innehålla mer förklarande kommentarer än faktisk kod.

Till Christer: Hur är sidans centrering utförd?
 
steelneck skrev:
Till Christer: Hur är sidans centrering utförd?
Klassiska varianten: "margin-left:auto; margin-right:auto;"

Jag har uppdaterat den alternativa test-CSS:en att inte centrera. Märks det någon skillnad?
http://www.fotosidan.se/?__style=std-test
http://www.fotosidan.se/

Vad gäller skillnader på vad som kommer på förstasidan; mest troligt är ju annonserna. Den ser också lite annorlunda ut beroende på om man är inloggad eller inte.

Jag skall ta och installera Linux på en gammal burk jag hittat. Kanske kan jag replikera felet då - det skulle onekligen underlätta. Det gick ju inte att replikera via vmware tyvärr, det hade varit enklast.
 
clindh skrev:
Klassiska varianten: "margin-left:auto; margin-right:auto;"

Jag har uppdaterat den alternativa test-CSS:en att inte centrera. Märks det någon skillnad?
http://www.fotosidan.se/?__style=std-test

Yes! Skillnad som dag o natt.

Nu är vi alltså problemet på spåren. Får jag föreslå någon form av conditional comment så länge:

<!--[if IE ]>
<style>
---centrering för IE---
</style>
<![endif]-->

Tyvärr har jag inte tid att fördjupa mig nu, måste strax hasta iväg hemifrån. Eventuellt att jag kan kika närmare i natt på en annan centreringslösning. Det kan räcka med att inte ha både left och rght tillsammans med auto. Kan vara där problemet ligger eftersom man på unixplattformen kan beräkna om sidorna "on the fly" även efter det att att bodyn är renderad.
 
steelneck skrev:
Yes! Skillnad som dag o natt.
Så bra!

Jag vill inte stänga av centreringen för alla Firefox; det funkar ju fint på Mac och Windows. Och FS är ju knappast enda sajten med denna centreringsteknik - så grundproblemet är nog inte centreringen utan den kombinerad med något annat, som triggar problemet. Det är ju tydligen inte alla sidor på FS som har slöscrollsproblemet; tex bildsidor funkar fint enligt Ulf.

Så jag vill helst hitta "roten till det onda", inte gömma det - men jag kan ju göra en temporär conditional för FF/Linux så ni kan köra bättre.

För att bekräfta att bakgrundsbilderna inte har med saken att göra har jag slagit på dessa igen i test-CSS:en, så testa gärna igen med länkarna ovan.
 
Njae, jag hann kika på vad du gjorde för ändringar, och det var ju lite mer än bara centreringen du ändrade. Så jag klippte in alla dina ändringar i ett "test-style" fönster och surfade in i denna tråd. Började där att plocka bort dem en efter en tills problemet dök upp igen. Den enda förändring som behövs för att denna tråd skall gå att scrolla fint är:

body#forum .stage {
background: none;
}

Varför det blir så tokigt har jag inte klurat ut ännu, det är mest troligt på grund av någon kombination med något annat som triggar beteendet, för bakgrundsbilder brukar annars inte orsaka några problem.

BTW:
"test-style" fönster är en bookmarklet, dvs. ett javascript som är sparat som ett bokmärke. I detta fall ger det mig ett popup fönster där jag kan skriva in precis vilka css-regler jag vill och de blir applicerade på sajten jag besöker omeddelbart.
 

Bilagor

  • dump.jpg
    dump.jpg
    19.4 KB · Visningar: 150
Ok, så bakgrundsbilderna är inblandade iallafall... Det var det enda test-css:en slog av innan jag lade in "avcentreringen" - men tex Ulf rapporterade att det inte vart någon skillnad med dem av eller på. Kanske vi har flera olika problem på halsen.
 
ANNONS
Spara upp till 12000 kr på Nikon-prylar