onScroll performance?

[bleicher]

Grüße,
ich wollte mit ein Paar Effekten spielen, wie das nachträgliche position:fixed für das Menü, sobald es dabei ist aus dem view gescrollt zu werden.
was mir aufgefallen ist - das abfragen von windows.scrollY im event scroll des window geht ein wenig auf die CPU.
gibt es elegantere Methoden für das reagieren auf scrollen?
MFG
bleicher

[JürgenB]

Hallo bleicher,

Events wie onscroll, onresize oder onmousemove feuern während der Aktion sehr oft, eben Pixelgenau, wobei das die Browser unterschiedlich handhaben. Ich habe da mit onresize mal etwas experimentiert.

Du musst dir überlegen, ob wirklich bei jedem Scrollpixel reagiert werden muss. Abhilfe wäre, dir zu merken, wann die letzte Aktion war und erst nach z.B. 0.1 s die nächste Aktion zulassen. Alternativ könntest du auch auf den onscroll verzichten und per setinterval alle z.B. 0.1 s die Scrollposition abfragen.

Gruß, Jürgen

[bleicher]

Grüße,

Du musst dir überlegen, ob wirklich bei jedem Scrollpixel reagiert werden muss. Abhilfe wäre, dir zu merken, wann die letzte Aktion war und erst nach z.B. 0.1 s die nächste Aktion zulassen. Alternativ könntest du auch auf den onscroll verzichten und per setinterval alle z.B. 0.1 s die Scrollposition abfragen.

das würde wiederum vor sich hin nerven, auch wenn nicht gescrollt wird. wie soll das "mit merken des letzten aufrufes" funktionieren? soll ich tatsächlich den onScoll beim feurn wegnehmen und mit setTimeout nach 0,n sekunden wieder ranhängen?
MFG
bleicher

[JürgenB]

Hallo bleicher,

... wie soll das "mit merken des letzten aufrufes" funktionieren? soll ich tatsächlich den onScoll beim feurn wegnehmen und mit setTimeout nach 0,n sekunden wieder ranhängen?

nein. Bei jedem Scroll-Event die Zeit abfragen und bei jeder Aktion die Zeit merken. Ob das performanter ist, als immer zu reagieren, musst du prüfen.

Gruß, Jürgen

[bleicher]

Grüße,

nein. Bei jedem Scroll-Event die Zeit abfragen und bei jeder Aktion die Zeit merken. Ob das performanter ist, als immer zu reagieren, musst du prüfen.

ich befürchte, dass die Zeitabfrage bei jedem scrollEvent keine entlastung gegenüber der einzigen if(window.scrollY>230) abfrage bringen würde :/
MFG
bleicher

[JürgenB]

Hallo bleicher,

nein. Bei jedem Scroll-Event die Zeit abfragen und bei jeder Aktion die Zeit merken. Ob das performanter ist, als immer zu reagieren, musst du prüfen.

ich befürchte, dass die Zeitabfrage bei jedem scrollEvent keine entlastung gegenüber der einzigen if(window.scrollY>230) abfrage bringen würde :/

ich vermute, das Auslösen des Events, das Abfragen der Scrollposition oder der Zeit kosten nicht viel CPU-Zeit. Die dann noch ausgeführten weiteren Aktionen (Manipulation im DOM, Verschieben oder Größenänderung von Elementen, ...) werden die CPU belasten. Und die sollten nur durchgeführt werden, wenn es sinnvoll ist.

Gruß, Jürgen

[bleicher]

Grüße,

das würde wiederum vor sich hin nerven, auch wenn nicht gescrollt wird. wie soll das "mit merken des letzten aufrufes" funktionieren? soll ich tatsächlich den onScoll beim feurn wegnehmen und mit setTimeout nach 0,n sekunden wieder ranhängen?

ok - getestet, das führt uU zum "tothängen" des elements, wenn manin den 0,1sek "vorbeiscrollt" und anhält. CPUmäßig kein vorteil :/
MFG
bleicher

[molily]

was mir aufgefallen ist - das abfragen von windows.scrollY im event scroll des window geht ein wenig auf die CPU.
gibt es elegantere Methoden für das reagieren auf scrollen?

1. z.B. die Hälfte der Funktionsaufrufe verwerfen – nicht so schön, da mal nicht weiß, wie die Browser die Events feuern.

2. Throttle mit setTimeout/clearTimeout

clearTimeout(handle);
handle = setTimeout(payload, 500);

In payload dann scrollY abfragen und das Menü positionieren.

Mathias

[bleicher]

Grüße,

In payload dann scrollY abfragen und das Menü positionieren.

bei leineren zeitschritten gibt es keine nenneswerte ersparnis, bei größeren wird der ganze effekt ziemlich hässlicj. kann man das verlassen des viewports von einem element nicht anders als durch scroll abfragen?
MFG
bleicher

[Matthias Apsel]

Om nah hoo pez nyeetz, bleicher!

In payload dann scrollY abfragen und das Menü positionieren.

scrollTop bzw. PageYOffset

ändert natürlich an onscroll nichts

Matthias

[molily]

Hallo,

kann man das verlassen des viewports von einem element nicht anders als durch scroll abfragen?

Nein.

Ich habe eine ähnliche Vermutung wie Jürgen, ich denke nicht, dass das Abfragen der Scrollposition alleine für Performance-Probleme sorgt. Scroll-Events abzufragen ist immer Performance-kritisch, weil sie sehr häufig passieren und man außer Throttling an diesem Umstand nichts ändern kann. Aber ich denke nicht, dass das nennenswert auf die CPU geht. Zeig uns mal, was du genau tust, wie und in welcher Umgebung du die Performance misst und wie sich die Probleme auswirken.

Mathias

[Jean-Max]

Bounjoun molily,

Scroll-Events abzufragen ist immer Performance-kritisch, weil sie sehr häufig passieren

Ist das Abfragen der Mausposition, in dem Fall den Y-Wert, auch als Performance-kritisch anzusehen? Ich habe sowas:

function getMousePos(e){  
  var e = e || window.event;  
  doThisDependingOnMousePos(e.clientY);  
}  
  
function doThisDependingOnMousePos(mousePos) {  
  alert("I'm here: "+mousePos);  
}  
  
element.onmouseover = function(e) { getMousePos(e); doMore() }

Müsste erst beim Feuern des mouseover-Event berechnet werden, oder?

Adiou.

[molily]

Hallo,

Performance-kritisch heißt nicht, dass es die JavaScript-Engine ins Knie zwingt, den CPU mit 100% belegt, den Browser einfriert und die Seite unbenutzbar macht. Es heißt erst einmal, dass in kurzer Zeit hunderte oder tausende Events dispatcht werden, Event-Objekte erzeugt werden und Handlerfunktionen ausgeführt werden. Auch das ist an sich noch kein Problem, das können heutige Browser problemlos ab. Ob es zu einem Problem wird, hängt ganz davon ab, was man in diesen Handlern macht – wie Jürgen sagt: DOM-Manipulationen, Style-Änderungen sind aufwändig – und ob andere gleichzeitig laufende Prozesse dadurch beeinflusst werden könnten, dass die Event-Loop des Interpreters mit tausenden Funktionsaufrufen geflutet wird.

Allein das Auslesen von Event-Properties ist kein Problem, sie sind beim Erzeugen des Event-Objekts eh schon berechnet worden. Wenn man z.B. ein Spiel hat, verwendet man ohnehin eine feste Framerate, sodass der Effekt, den eine Mausbewegung auf die Darstellung hat, ohnehin erst beim nächsten regulären Frame umgesetzt wird.

Mathias

[Novi]

Hallo,

Ich habe eine ähnliche Vermutung wie Jürgen, ich denke nicht, dass das Abfragen der Scrollposition alleine für Performance-Probleme sorgt. Scroll-Events abzufragen ist immer Performance-kritisch, weil sie sehr häufig passieren und man außer Throttling an diesem Umstand nichts ändern kann. Aber ich denke nicht, dass das nennenswert auf die CPU geht. Zeig uns mal, was du genau tust, wie und in welcher Umgebung du die Performance misst und wie sich die Probleme auswirken.

Beim Scrollen schnellt die CPU-Auslastung gerne mal in die Höhe. Bei OpenOfficeOrg ereicht sie bei meinem duale core bis 50%-CPU-Auslastung. Da dies jedoch nur während dem eigentlichen (schnellen) Scrollen auftritt, ist es jedoch kein Problem und außer mit dem Taskmanager eigentlich auch nicht spürbar. Sprich eine kurzzeitige hohen CPU-Auslastung stört kaum.

Hat die hohe CPU-Auslastung, die durch dein Script verursacht wird, denn wirklich ein kurzzeitiges Einfrieren des Systems zu Folge oder willst du es nur wegen der angezeigten CPU-Auslastung optimieren.

Viele Grüße Novi