Tweakers.net en Firefox = Langzame mousepointer en menu's

[Verwijderd]

Ik wil een vorig topic van iemand anders nog even aanhalen aangezien ik hier zelf ook problemen me heb en graag zou weten hoe dit is op te lossen.
Tweakers.net en Firefox...

Het probleem is een langzame mousepointer en menu's die langzaam werken / openklappen.
Zelf heb ik dit probleem dus wel op mijn eigen computer en niet op de computer beneden. Ze zijn beide geconfigt met Windows XP Pro. Het verschil is dat mijn pc een Duron processor heeft en de andere een Celeron. Ik heb geen idee of het hier aan kan liggen. Nu wil ik graag beleefd vragen welke mensen wel / niet dit probleem hebben en met wat voor een configuratie.

[coubertin119]

Heb je fadende/transparante menu's aanstaan? Die durven wel 'ns traag zijn.

[Verwijderd]

Ja, na nadere inspectie zie ik dat het transparante wel aan staat. Ik moet er eigenlijk nog even bij vermelden dat de pagina in Internet Explorer niet traag is.

[ Voor 25% gewijzigd door Verwijderd op 27-09-2004 17:56 ]

[Steve]

Dat kan je hierzo instellen: http://www.tweakers.net/my.tnet/?action=layout

Menu-effect even op 'Niet transparant' instellen om te kijken of het dan opgelost is.

[Verwijderd]

Hee, bedankt! Het is niet zo snel als met Internet Explorer, maar in ieder geval veel sneller als dat het was. Misschien is het een idee om deze preference standaard te maken i.v.m. andere mensen die dit probleem mogelijk ook hebben.

[Steve]

Volgens mij staat het daar standaard ook op .

[Verwijderd]

Volgens mij niet, want ik kan me niet herinneren dat ik er ooit iets gewijzigd heb.

[Br@m]

Dit probleem heb ik ook al zo lang. En ik ben er nog steeds niet achter hoe het komt.
Één ding weet ik 100% zeker, als er bij mijn klokje het icoontje van SUN Java staat dan is het probleem als sneeuw voor de zon verdwenen.
Ik heb het ook al eens in het topic " [Firefox] Wat vinden we ervan?" gezet, als ik eerst naar girotel online ga, en daarna gelijk naar de frontpage bv. Dan werkt het wel correct. Maar er is nog niemand die dit probleem kan oplossen. Ben alleen blij dat er meer zijn die dit probleem hebben.

Wat voor systeem heb jij toevallig?

[Steve]

Dat icoontje betekent wellicht dat de Java-plugin actief is en dat je aldus Java-applets kunt weergeven. Maar volgens mij worden er nergens Java-applets gebruikt op de FP?

[Verwijderd]

Moederbord: MSI Turbo rev 3
Processor: AMD Duron 1200
Geheugen: 2 x 128 MB SDRAM
Videokaart: Geforce 2 MX 32 MB
Geluidskaart: Creative Audigy
TV Kaart: Pinnacle PCTV
Netwerkkaart: Realtek
Brander: Lite on 24x

De rest lijkt me niet echt van wezenlijk belang.

[Br@m]

Verwijderd schreef op 27 september 2004 @ 18:22:
Moederbord: MSI Turbo rev 3
Processor: AMD Duron 1200

Heb hier ook een AMD, een Athlon 64 met een MSI bord. Maar kan me niet voorstellen dat het aan die AMD zit.

[Verwijderd]

Heb jij ook al geprobeert om die transparante menu's uit te zetten? Bij mij werkt het nog niet optimaal, maar wel een stuk beter.

[Br@m]

Verwijderd schreef op 27 september 2004 @ 18:26:
Heb jij ook al geprobeert om die transparante menu's uit te zetten? Bij mij werkt het nog niet optimaal, maar wel een stuk beter.

Ik heb al zoveel geprobeerd. het is idd wel een stukje beter, maar niet zoals het hoort helaas.
Ben zelf een keertje terug gegaan naar Firebird. Maar nog steeds hetzelfde.

[4AMD]

"Transparant & fading" staat volgens mij standaard aan, ook wanneer je niet ingelogd bent.

Verder lijken bovenstaande beschrijvingen veel op dit probleem (devtrack.tweakers.net), wat ik vroeger had. Bij mij loste het probleem zich vanzelf op toen ik mijn grafische kaart door een GeForce 6800 GT verving, dus wellicht heeft het met de gebruikte grafische kaart (of drivers daarvan) te maken.

[Verwijderd]

Duron pc met problemen: Geforce 2 MX 32 MB
Celeron pc zonder problemen: Geforce 2 MX 32 MB

[Br@m]

Verwijderd schreef op 27 september 2004 @ 19:43:
Duron pc met problemen: Geforce 2 MX 32 MB
Celeron pc zonder problemen: Geforce 2 MX 32 MB

Ik ga mijn laptop eens opstarten met een Centrino processor.

[4AMD]

Verwijderd schreef op 27 september 2004 @ 19:43:
Duron pc met problemen: Geforce 2 MX 32 MB
Celeron pc zonder problemen: Geforce 2 MX 32 MB

Interessant. Gebruik je ook exact dezelfde drivers voor die grafische kaart?

Bij mij in iedergeval was de grafische kaart hardwarematig 100% zeker de oorzaak van het probleem.

[SyS_ErroR]

Ik heb het probleem hier thuis ook, op elke pc.
(Varierend van een Win2k Prof + sp4, 1600+, 512Mb DDR, en een TNT 2 tot een 2800+ GF FX5900 XT, 1GB DDR, WinXP SP1)

Dat uitzetten van die trancparency had trouwens geen effect bij mij...

[wallum]

ook hier een trage frontpage in firefox 1.0: XP2000+, Asus A7N8X-X, 640 Mb, 9600 XT met cat4.7, SB51 en win98se.
traag scrollen zolang de menu's bovenin in beeld zijn.

in IE6 draait de frontpage prima (de menu's zijn dan trouwens niet transparant voor zover ik zie, in FF is het vrij duidelijk te zien).

het vreemde is: zolang IE6 met de frontpage openstaat, is de traagheid in firefox weg!? sluit IE6 af en de traagheid is terug
wild guess: de FP-menu's zijn java-applets of een andere plugin en onder IE6 krijgen die hogere prioriteit in windows

gelukkig lost 'niet transparant' het probleem grotendeels op.

[Harm]

De menu's zijn geen java-applets. Het zijn gewoon stukjes Javascript en dat is iets totaal anders dan Java-applets. Hoe dan ook, maak een bug op Devtrack zodat de devvers ook van deze problemen op de hoogte zijn .

[Br@m]

Ik heb het probleem gevonden! Het zit wel degelijk in de videodrivers. Ik heb net de Nvidiadrivers gedeinstalleerd, en het werkt nu perfect met de standaard vgadrivers van XP. Dus moet ik dan toch op zoek naar een andere videokaart voor de frontpage
Of heeft iemand een ander idee voor mij?

[edit]
Ik heb nou net de nieuwe 66.81 drivers geinstalleerd en weer hetzelfde probleem..

[edit 2]
Ik zit nu achter de laptop, maar daar heb ik precies hetzelfde probleem. En daar zit een ATI 9000 kaartje in.
Dus ik weet het nu niet meer hoor..

[ Voor 33% gewijzigd door Br@m op 03-10-2004 18:59 ]

[Verwijderd]

Het vreemde is dat bij mij de drivers van nVidia juist weer stukken beter werken dan die standaard bij Windows zitten.

[Verwijderd]

Je hebt gelijk, bij mij verdwijnen de problemen ook zodra het java-koffiekopje in de systray komt te staan. Dan werken de menu's en het scrollen van de browser een stuk sneller.

De problemen doen zich voor zodra de javascript-menu's in beeld komen, dus zodra ze uit het beeld scrollen, dan gaat het scrollen plotseling veel sneller.

De menus zelf doen er soms wel 2 seconden over om uit te klappen

Het resizen van de DL-manager van Firefox gaat ook vrij traag.

Het grappige is dat mijn 'langzame' computer deze problemen niet heeft en mijn 'snelle computer' heeft deze problemen wel met Firefox.

Langzame computer (waar Firefox goed en snel werkt):
Asus P2B (Intel 440 BX)
PIII - 850 (Asus S370-DL socket converter) 100 MHz FSB
384 MB SDRAM (3 * 128MB)
40 GB HDD
Prolink Geforce 2 MX 32 MB

Snelle computer (Firefox reageert zeer traag op de frontpage van t.net)
Aopen AX4B Pro (Intel 845G)
PIV 1,8 GHz 400 MHz FSB
XFX Riva TNT2 Mach64 32 MB
256 MB DDR Ram PC2300 (1 * 256 MB)
40 GB HDD

Op alletwee de computers staan de laatste Nvidia drivers en Firefox 1.0 PR en Windows XP pro. Het veranderen van performance/appearance options in Windows XP maakt geen verschil.

In IE 6.0 werkt alles wel snel op beide computers. De problemen verdwijnen dus voor een groot gedeelte, wanneer het Java-icoontje in de systray staat! En dit terwijl de menu's op t.net frontpage niets met Java te maken hebben! Wie weet hoe dit kan, is waarschijnlijk ook dicht bij de oplossing.

[ Voor 24% gewijzigd door Verwijderd op 04-10-2004 16:01 ]

[Br@m]

Bij mij is het probleem opgelost...

Ik heb vanmorgen een nieuw mainbord + Intel CPU en een PCI-E Videokaart van MSI met een ATI erin gezet en het probleem is opgelost..

Ik kan niet zeggen waar het probleem nu precies lag, maar ik heb een nieuw systeempje en het probleem is weg

[Hielko]

Blijkbaar dus de videokaart drivers he. Als je overgestapt bent van nVidia naar ATi lijkt me dat een logische verklaring.

[darkrain]

Dit probleem heb ik ook gehad en na het installeren van de nieuwste Nvidia drivers was het opgelost.
Dus de conlcusie mag denk ik zeker zijn dat het aan videokaartdrivers ligt.

[Verwijderd]

Hielko schreef op 09 oktober 2004 @ 12:47:
Blijkbaar dus de videokaart drivers he. Als je overgestapt bent van nVidia naar ATi lijkt me dat een logische verklaring.

Lijkt me sterk.

Ik heb het hier ook (transparante menu's aan, maar volgens mij is dat standaard, want ik heb het ook nooit veranderd), in FF 0.8, in IE niet, en in deze bak heeft altijd een ATI kaart gezeten.

Ik gebruik trouwens de laatste Catalyst.

edit:
Misschien heeft het er ook mee te maken dat ik geen IE cookie hebt, en daar dus geen transparante menu's heb.

[ Voor 27% gewijzigd door Verwijderd op 11-10-2004 20:23 ]

[leon1e]

Op mijn laptop op het werk bugged het ook regelmatig als ik fading en transparant aan heb staan. Deze optie's staat standaard aan als je niet bent ingelogd. In IE daarintegen is hij wel sneller, maar met fading & transparant uit nog een stuk sneller.

Is het geen optie om dit standaard uit te zetten, het lijkt nu namelijk zo of heel t.net traag is terwijl dit eigenlijk komt door een paar menutjes.

[crisp]

fading en transparantie zijn niet de grootste bottleneck, er wordt echter bij het openen van een menu een vrij groot onzichtbaar vlak geactiveerd om de mouseout te triggeren, en dit levert op sommige systemen inderdaad vertragingen op.
Ik heb dit al aangekaart en heb ook een alternatieve oplossing hiervoor (de methode die we hier op GoT gaan gebruiken). Echter is dat niet iets wat je zo 1-2-3 even overzet naar de frontpage. Op GoT hebben we bijvoorbeeld geen fading en transparantie ingebouwd, en ik denk dat Femme dat op de FP toch wel graag wil houden

[leon1e]

crisp schreef op 14 oktober 2004 @ 23:05:
fading en transparantie zijn niet de grootste bottleneck, er wordt echter bij het openen van een menu een vrij groot onzichtbaar vlak geactiveerd om de mouseout te triggeren, en dit levert op sommige systemen inderdaad vertragingen op.
Ik heb dit al aangekaart en heb ook een alternatieve oplossing hiervoor (de methode die we hier op GoT gaan gebruiken). Echter is dat niet iets wat je zo 1-2-3 even overzet naar de frontpage. Op GoT hebben we bijvoorbeeld geen fading en transparantie ingebouwd, en ik denk dat Femme dat op de FP toch wel graag wil houden

Op beta got werkt het inderdaad zonder problemen . Als ik Fading / Transparant uitzet scheelt het toch al zeker 60%, de laatste 40% die blijft hangen omdat het nu eenmaal in de code zit daar kunnen de meeste mensen wel mee leven verwacht ik.

Maar het voorstel om deze optie's standaard te disablen, hoe denken jullie daarover. Ik heb in veel gevallen echt geen zin/tijd om in te loggen, om even snel door de frontpage te surfen zonder al te veel load.

[Verwijderd]

Ja maar hoe kan het dan dat het WEL goed werkt als het Java-icoontje in de tray staat?

En hoe kan het dan dat mijn langzame computer hier geen vertraging oploopt (ook bij bijvoorbeeld de grote mouseout trigger)?

Al deze posts hierboven zijn eigenlijk overbodig bij het beantwoorden van de vraag.

[Hielko]

Probably de videokaart drivers, iets anders kan het imo namelijk niet zijn. Het feit dat het wel werkt met java wijst daar ook op. Hoe dat programma werkt weet ik niet, maar dat 't vreemd doet me videokaart divers is me ondertussen wel duidelijk. Bij mij werkt bijv. de GUI van java programma's niet meer zodra ik FSAA en AF aanzet in de drivers (ATi kaart).

[crisp]

Het is sowieso een renderissue, en dus kan het inderdaad zo zijn dat het met andere hardware en ander drivers al dan niet merkbaar is. Feit is wel dat het dusdanig op te lossen is dat het dus ook met 'mindere' hardware of 'mindere' drivers geen issue hoeft te zijn door gewoon andere code te gebruiken.

[ Voor 4% gewijzigd door crisp op 19-10-2004 00:10 ]

[Verwijderd]

Zelfde probleem heb ik dus ook, Acer 1353LC laptop met 512MB en WIN XP PRO (2)
Bovendien heb ik de laatste tijd vrij vaak dat het linkermenu niet geladen wordt en dat het nieuws nu helemaal links komt te staan zonder opmaak etc. De ene keer werkt het wel goed, de andere keer niet?

Ik heb nu de cache van firefox maar verhoogt van 300kb naar 3000kb omdat het ook lijkt alsof hij de css-file niet goed laadt.

[Verwijderd]

Mensen, ik heb mogelijk een andere oplossing voor dit probleem gevonden: Moox Powerrrrrr. (Onnodige Danoontje humor )

Maar even serieus Moox Power werkt wel goed bij mij.
Er is namelijk één of andere vent die optimized Firefox builds maakt voor elke processor. Er is Firefox M1 (langzame cpu, P2 etc) Firefox M2 (middelmatige cpu, P3 etc) en Firefox M3 (snelle cpu, P4 etc).
Zelf gebruik ik nu M2 voor mijn Duron pc en M3 voor mijn Pentium M laptop. En ik moet zeggen, tweakers werkt niet alleen sneller, alles werkt sneller.

Van te voren moet ik nog even zeggen dat veel extensions helaas niet meer zullen werken.

Moox power kan je hier downloaden:
http://www.moox.ws/tech/mozilla/

Pak wel de branch build en niet de trunk, anders heb je meer kans op bugs.

[Verwijderd]

Het lijkt alsof dit topic verdwenen is...

[BasieP]

ik zit hier op een xp 2600 met een GF3, en heb ook die render probs..

ik heb het topic beetje doorgelezen, maar vind het beetje zwak geargumenteerd.

crisp zegt dat het niet aan je vid kaart ligt maar aan het grote 'disable menu' vlak om het menu heen, en later zegt ie weer dat andere drivers/hardware het wel op kunnen lossen.

nu heb ik al tig driver geprobeerd, maar ik blijf het probleem houden.
trouwens vind ik het erg zwak dat in deze wereld waar transparante menu's al JAREN bestaan, en zelfs op mijn TNT2/800mhz Athlon nog soepel lopen, iemand zegt dat het aan de hardware/drivers ligt

bovendien draait het onder IE wel goed/snel met precies dezelfde drivers/hardware

[Harm]

Verwijderd schreef op 25 oktober 2004 @ 22:50:
Het lijkt alsof dit topic verdwenen is...

Dat is geen reden om het te schoppen hoor... Het probleem is bekend zoals crisp zegt, heeft Femme aangegeven het niet op te gaan lossen op de korte termijn. Dit topic schoppen is dus nergens voor nodig.

[crisp]

Ik heb die hele code al een keer nageplozen; ook op mijn bak (xp2000 win2k en een GF2 vidkaart met niet al te recente drivers) is het standaard menu traag in FF. Nadat ik wat kleine tweaks in de code had aangebracht (het grote disable vlak weggehaald en de menu's op een andere manier laten hiden) was het zeker een faktor 20 sneller (met fading en transparantie aan - er was op dat moment geen merkbaar verschil meer met bijvoorbeeld IE). Het is dus enerzijds wel degelijk een programatische issue, maar een issue die niet in alle setups blijkbaar speelt.
Op sommige systemen lijkt FireFox het qua rendersnelheid gewoon beter te doen, en de enige verklaring die ik daarvoor kan geven is dat blijkbaar hardware en drivers ook een rol kunnen spelen.

Het is dus echter wel zo dat het met aangepaste code gewoon snel(ler) kan werken ongeacht je systeem en/of drivers en die oplossing moeten me m.i. dan ook gewoon nastreven.
Ik heb Femme al een tijd terug de details doorgegeven, en dit zal echt wel een keer opgepakt gaan worden...

edit: wat Harm dus ook zegt

[ Voor 4% gewijzigd door crisp op 25-10-2004 23:06 ]

[BasieP]

crisp schreef op 25 oktober 2004 @ 23:05:
Ik heb die hele code al een keer nageplozen; ook op mijn bak (xp2000 win2k en een GF2 vidkaart met niet al te recente drivers) is het standaard menu traag in FF. Nadat ik wat kleine tweaks in de code had aangebracht (het grote disable vlak weggehaald en de menu's op een andere manier laten hiden) was het zeker een faktor 20 sneller (met fading en transparantie aan - er was op dat moment geen merkbaar verschil meer met bijvoorbeeld IE). Het is dus enerzijds wel degelijk een programatische issue, maar een issue die niet in alle setups blijkbaar speelt.
Op sommige systemen lijkt FireFox het qua rendersnelheid gewoon beter te doen, en de enige verklaring die ik daarvoor kan geven is dat blijkbaar hardware en drivers ook een rol kunnen spelen.

Het is dus echter wel zo dat het met aangepaste code gewoon snel(ler) kan werken ongeacht je systeem en/of drivers en die oplossing moeten me m.i. dan ook gewoon nastreven.
Ik heb Femme al een tijd terug de details doorgegeven, en dit zal echt wel een keer opgepakt gaan worden...

edit: wat Harm dus ook zegt

kijk das goed nieuws, die test was zeker bij jouw thuis?

ach ik zie vanzelf wel als code aangepast is op fp
tnx

[crisp]

BasieP schreef op 25 oktober 2004 @ 23:17:
[...]


kijk das goed nieuws, die test was zeker bij jouw thuis?

ach ik zie vanzelf wel als code aangepast is op fp
tnx

jep, was hier bij mij thuis. Nu is het natuurlijk makkelijk om met wat statische bestanden dat soort dingen uit te proberen; om het uiteindelijk op de site aan te passen is weer andere koek aangezien dat allemaal dynamisch gegenereerd wordt. Het is dus niet eenvoudig om het even op te lossen, en andere zaken hebben gewoon een hogere prioriteit...

[Verwijderd]

Als de Tweakers.net site een beetje goed in elkaar zit, dan is het juist veel sneller op te lossen dan met bijv. harde html code.

[Harm]

Als het gemakkelijk op te lossen zou zijn, dan had Femme dat allang gedaan lijkt me. Klaarblijkelijk is dat niet zo en dus blijft het liggen. Verder, zie crisp .

[Renegade]

Verwijderd schreef op 28 oktober 2004 @ 16:25:
Als de Tweakers.net site een beetje goed in elkaar zit, dan is het juist veel sneller op te lossen dan met bijv. harde html code.

Ik geloof dat je crisp niet helemaal goed begrijpt. De Tweakers.net frontpage wordt ook niet met compleet harde html code opgebouwd. Alleen heeft crisp het lokaal met harde code getest waardoor hij er niet voor in kan staan dat het als het op de frontpage gebruikt zou worden even snel is. Maar zelfs dan is er waarschijnlijk nog een snelheidsverschil ook al zou je de niet harde code gebruiken.

[Verwijderd]

Klopt, maar ik vind het een beetje vreemd dat op zo'n goede en drukbezochte site dit soort dingen niet snel opgelost kunnen worden. Ja, ik weet het, iedereen heeft het enorm druk, en dat respecteer ik ook. Maar ik vind het vooral vreemd, aangezien ik dit eigenlijk alleen bij tweakers.net krijg, dus ik vermoed dat er iets aan de javascript layers aangepast moet worden.