Witam,

Zrobiłem animację przesuwającą DIV'a po ekranie w pionie (menu). DIV ma
wymiar 290x350 i zawiera w tle CSS bitmapę oraz parę elementów p - nie
jest skomplikowany. JS przesuwa go w zdarzeniu timera (setInterval) co
10mS. Pod IE działa to bardzo płynnie a pod Chrome i FF widać delikatną
skokowość. Czego to może być przyczyną? Brak akceleracji sprzętowej w
niektórych przeglądarkach czy mało wydajny JS w tych dwóch
przeglądarkach? Czy jest jakaś sztuczka na korektę tego stanu rzeczy?

--

Pozdrawiam
Marek

do góry

W dniu 2013-01-31 10:29, Marek pisze:
> Witam,
>
> Zrobiłem animację przesuwającą DIV'a po ekranie w pionie (menu). DIV ma
> wymiar 290x350 i zawiera w tle CSS bitmapę oraz parę elementów p - nie
> jest skomplikowany. JS przesuwa go w zdarzeniu timera (setInterval) co
> 10mS. Pod IE działa to bardzo płynnie a pod Chrome i FF widać delikatną
> skokowość. Czego to może być przyczyną? Brak akceleracji sprzętowej w
> niektórych przeglądarkach czy mało wydajny JS w tych dwóch
> przeglądarkach? Czy jest jakaś sztuczka na korektę tego stanu rzeczy?

Ja by zrobil tak:

1. timeout: 1000 / fps (ile tam ramek na sekunde potrzebujesz)
2. setTimeout zamiast setInteval. Dlaczego? W google znajdziesz mnostwo
informacji na ten temat. :-)

--
Cezary Tomczyk
http://www.ctomczyk.pl/

do góry

Dnia Thu, 31 Jan 2013 12:24:53 +0100, Cezary Tomczyk napisał(a):

> 1. timeout: 1000 / fps (ile tam ramek na sekunde potrzebujesz)
> 2. setTimeout zamiast setInteval. Dlaczego? W google znajdziesz mnostwo
> informacji na ten temat. :-)

W jQuery wykorzystują właśnie setInterval(), a ich animate() jest
bezproblemowe. Przyczyna musi leżeć gdzieś indziej.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

W dniu 2013-01-31 21:35, Borys Pogoreło pisze:
> Dnia Thu, 31 Jan 2013 12:24:53 +0100, Cezary Tomczyk napisał(a):
>
>> 1. timeout: 1000 / fps (ile tam ramek na sekunde potrzebujesz)
>> 2. setTimeout zamiast setInteval. Dlaczego? W google znajdziesz mnostwo
>> informacji na ten temat. :-)
>
> W jQuery wykorzystują właśnie setInterval(), a ich animate() jest
> bezproblemowe. Przyczyna musi leżeć gdzieś indziej.

To już jakaś zaraza musi być :P "bo w jQuery napisali...". To, że coś
jest napisane w jQuery tak, a nie inaczej, nie świadczy akurat o tym, że
jest dobrze. W ogóle zdefiniowanie pojęcie "dobrze napisane" jest
trudne, wiem.

Osobiście w niektórych projektach używam jQuery i ok. Aczkolwiek
niekoniecznie muszę się zgadzać z tym, jak jQuery jest napisane. 6 lat
developerki, ale kod nie zachwyca. Trochę się to zmienia, ale poczekamy,
zobaczymy.

A co do setInterval:
http://zetafleet.com/blog/why-i-consider-setinterval
-harmful

Osobiście zawsze do animacji używam setTimeout z powodów np. opisanych w
podanym przeze mnie linku.

--
Cezary Tomczyk
http://www.ctomczyk.pl/

do góry

W dniu 2013-01-31 10:29, Marek pisze:
> Zrobiłem animację przesuwającą DIV'a po ekranie w pionie (menu). DIV ma
> wymiar 290x350 i zawiera w tle CSS bitmapę oraz parę elementów p - nie
> jest skomplikowany. JS przesuwa go w zdarzeniu timera (setInterval) co
> 10mS. Pod IE działa to bardzo płynnie a pod Chrome i FF widać delikatną
> skokowość. Czego to może być przyczyną?

Przyczyną jest tutaj nieznajomość position:fixed :)


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

Dnia Thu, 31 Jan 2013 22:12:58 +0100, Cezary Tomczyk napisał(a):

>>> 1. timeout: 1000 / fps (ile tam ramek na sekunde potrzebujesz)
>>> 2. setTimeout zamiast setInteval. Dlaczego? W google znajdziesz mnostwo
>>> informacji na ten temat. :-)
>>
>> W jQuery wykorzystują właśnie setInterval(), a ich animate() jest
>> bezproblemowe. Przyczyna musi leżeć gdzieś indziej.
>
> To już jakaś zaraza musi być :P "bo w jQuery napisali...". To, że coś
> jest napisane w jQuery tak, a nie inaczej, nie świadczy akurat o tym, że
> jest dobrze. W ogóle zdefiniowanie pojęcie "dobrze napisane" jest
> trudne, wiem.

Zniknąłeś drugą część mojego zdania. :)

Ich animate() wykorzystuję często i nie mam zastrzeżeń - więc widocznie da
się to zrobić dobrze za pomocą setInterval().

> A co do setInterval:
> http://zetafleet.com/blog/why-i-consider-setinterval
-harmful
>
> Osobiście zawsze do animacji używam setTimeout z powodów np. opisanych w
> podanym przeze mnie linku.

Owszem, te powody mają sens, ale nie w przypadku animacji! Tu nas nie
interesują opóźnienia sieciowe, zaś powód #3 jest wręcz zaletą -
priorytetem funkcji jest wykonać się w określonym czasie, nie określoną
liczbę razy, co w razie problemów z kodem może się dowolnie przeciągnąć.

Co do #1 to mam mieszane uczucia - daje to jednak pewność, że kod będzie
się wykonywać aż do czasu wyłączenia timera.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

W dniu 2013-02-01 01:32, Borys Pogoreło pisze:
> Dnia Thu, 31 Jan 2013 22:12:58 +0100, Cezary Tomczyk napisał(a):
>
>>>> 1. timeout: 1000 / fps (ile tam ramek na sekunde potrzebujesz)
>>>> 2. setTimeout zamiast setInteval. Dlaczego? W google znajdziesz mnostwo
>>>> informacji na ten temat. :-)
>>>
>>> W jQuery wykorzystują właśnie setInterval(), a ich animate() jest
>>> bezproblemowe. Przyczyna musi leżeć gdzieś indziej.
>>
>> To już jakaś zaraza musi być :P "bo w jQuery napisali...". To, że coś
>> jest napisane w jQuery tak, a nie inaczej, nie świadczy akurat o tym, że
>> jest dobrze. W ogóle zdefiniowanie pojęcie "dobrze napisane" jest
>> trudne, wiem.
>
> Zniknąłeś drugą część mojego zdania. :)

Ekhm, zniknąłem? :/

> Ich animate() wykorzystuję często i nie mam zastrzeżeń - więc widocznie da
> się to zrobić dobrze za pomocą setInterval().

Nie napisałem, ze nie działa, ale ze mogłoby to być inaczej napisane :-)

>> A co do setInterval:
>> http://zetafleet.com/blog/why-i-consider-setinterval
-harmful
>>
>> Osobiście zawsze do animacji używam setTimeout z powodów np. opisanych w
>> podanym przeze mnie linku.
>
> Owszem, te powody mają sens, ale nie w przypadku animacji! Tu nas nie
> interesują opóźnienia sieciowe, zaś powód #3 jest wręcz zaletą -

Ok, co to animacji opóźnienia sieciowe #2 może nie maja generalnie
znaczenia.

> priorytetem funkcji jest wykonać się w określonym czasie, nie określoną
> liczbę razy, co w razie problemów z kodem może się dowolnie przeciągnąć.

Jeśli akcja B zależy od wyniku akcji A (i tak w kolko), a akcja A
zamiast wykonać się w 100ms wykona się w 200ms, to w międzyczasie akcja
B uruchomi się i będzie błąd, gdyż nie ma jeszcze wyniku z akcji A.
Czemu właśnie przeciwdziała setTimeout.

> Co do #1 to mam mieszane uczucia - daje to jednak pewność, że kod będzie
> się wykonywać aż do czasu wyłączenia timera.

O ile chcemy by się wykonywał aż do czasu wyłączenia timera.

--
Cezary Tomczyk
http://www.ctomczyk.pl/

do góry

W dniu 2013-01-31 23:42, Paweł Piskorz pisze:
>
> Przyczyną jest tutaj nieznajomość position:fixed :)

Świetnie zbudowałeś napięcie. A czy po tym wstępie mógłbyś wątek
rozwinąć? :-D

--

Pozdrawiam
Marek

do góry

W dniu 2013-01-31 21:35, Borys Pogoreło pisze:
> Dnia Thu, 31 Jan 2013 12:24:53 +0100, Cezary Tomczyk napisał(a):
>
>> 1. timeout: 1000 / fps (ile tam ramek na sekunde potrzebujesz)

No ale ja napisałem, że co 10mS robię przesuwanie.

>> 2. setTimeout zamiast setInteval. Dlaczego? W google znajdziesz mnostwo
>> informacji na ten temat. :-)

Kurcze... nigdzie nie znalazłem tego. Jedyna rzecz jaka mi do głowy
przychodzi, to przypadek gdy komputer nie wyrabia się z przesuwaniem
elementu graficznego i "przerwania" zaczynają nachodzić na siebie.
Wydaje mi się ta czynność zbyt banalna aby tak się mogło dziać.

> W jQuery wykorzystują właśnie setInterval(), a ich animate() jest
> bezproblemowe. Przyczyna musi leżeć gdzieś indziej.
>

Sprawdzałeś dla 10mS?

--

Pozdrawiam
Marek

do góry

Dnia Fri, 01 Feb 2013 16:36:26 +0100, Marek napisał(a):

>> W jQuery wykorzystują właśnie setInterval(), a ich animate() jest
>> bezproblemowe. Przyczyna musi leżeć gdzieś indziej.
>
> Sprawdzałeś dla 10mS?

U nich to działa "od drugiej strony" - określasz czas trwania animacji, zaś
funkcja liczy liczbę klatek. Ale z tego co widzę, to jeden "krok" trwa
13ms.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry