Pull to refresh

Comments 56

Интересно конечно, но у меня оно отъедает ~12% одного ядра.
Chromium 11, Linux.
Действительно, очень занятно.
И, действительно, жаль что:

С Ubuntu 11.04 + Firefox 4.0.1 сжирает больше 65% ядра…
Что-то «Кроссбраузерный» в заголовке топика плохо вяжется с последним абзацем
Внимательный читатель мог заметить, что данная «тайная техника» не работает в IE. Могу посоветовать только отдавать ему другой код с GIF или Flash, ждать IE10 и готовить лопату.
Вы правы. Дело в том, что обнаружил этот «подарок» я уже в самом конце процесса написания статьи. Был уверен, что раз IE9 поддерживает SVG, то такая простая анимация там заработает. Соответственно, название статьи решил уже не менять.
Остроумное решение:) Но на практике — не проще ли анимировать спрайт? Тем более, что работать будет и в IE. Ну да, будет нужен JS, зато не будет нужен SVG:)
Мы не ищем простых путей! :)
Не так… «Мистер знает толк в извращениях» ;-)
Можно дополнительно задействовать спрайт персонально для IE.
Разумеется, можно.
Но смотрите, что получается — у нас один костыль для браузеров, и другой для IE. Мне кажется, это как-то неизящно. Не проще ли сделать один костыль, но уж который работает везде?
Способ, работающий без JavaScript, всегда зачастую (при прочих равных) предпочтительнее способа, работающего с помощью JavaScript. И если в большинстве браузеров можно обойтись без JS, то применять JS имеет смысл только в оставшихся.
Всегда предпочтительнее иметь и поддерживать одно решение, а не два — потому что это проще в поддержке.
Всегда сначала ищется кроссбраузерное решение, а потом добавляются хаки. Противоположная стратегия приводит к масштабному головняку, как правило.

Тем более, что в данном случае вариант со спрайтами по объему примерно равен исходному варианту с SVG.

Это, конечно, дело вкуса отчасти, но я свои причины думать именно так, изложил выше:)
Если на первом месте не потребительские качества сайта, а простота его сопровождения для разработчика, тогда единое решение, конечно, может иметь преимущество.
Когда разработчик тратит время на поддержку двух костылей вместо одного — вот тогда потребительские качества сайта и начинают страдать. Потому что время тратится контрпродуктивно.

Я согласен, что решение без JS в общем случае лучше. Это баян, собственно. Но одно решение, даже с JS, всяко лучше, чем два.

KISS и DRY.
Разные решения применяются в разных нишах (ценовых, качественных и проч.), это нормально.

А следуя парадигме «одно решение для всех браузеров», недолго дойти и до того, чтобы, например, для всех браузеров использовать таблицу вместо списка для резинового меню шириной 100%, когда {display: table} в действительности не поддерживается лишь менее чем 10% браузеров (IE 6/7). Graceful degradation, progressive enhancement. ;-)
Следуя вашей логике, для IE такое меню надо сверстать таблицей, а для браузеров — списком:)
Для браузеров и IE8+ (более 90% браузеров) — список, для IE6/7 — нерезиновое меню при помощи float либо динамическая генерация таблицы из списка средствами JS. Правильным браузерам — правильное решение, остальным — приемлемое. ;-)
> получил солнышко из хвоста лисы

Это ухо.
У меня эта картинка ест 5% процессора. Аналогичная анимация на флеш будет грузить процессор не больше (а скорей всего сильно меньше).
кроме того вместо 25 изображений будет достаточно 2х. планеты и лисы.
Если уж говорить о вращении — это вообще идеально делается на чистом CSS, например:

s3.amazonaws.com/37assets/svn/463-single_spinner.html

Здесь всё-таки человек делал анимацию из переключающихся кадров…
По ссылке одна серость. В смысле вся страница залита светло-серым и ничего на ней нет.
У меня там крутится анимация загрузки. Видимо, это и есть демонстрация поворота средствами CSS.
Chrome.
FF4/ Как я уже говорил — абсолютно ничего не вижу на странице.
А вот исходный APNG — отлично крутится =)
Кроссбраузерность — миф.
В FF4 этих CSS keyframe animations еще нет. Есть внушительный баг в мозилловской багзилле на эту тему, там уже второй десяток патчей люди пишут для того, чтобы реализовать этот функционал. В ближайшее время (4.1-4.2) по идее должны принять — правда, разумеется, не с "-webkit-" префиксами свойств.
Это также можно сделать и на CSS, как уже сказали, и на том же SVG. Я хотел показать наиболее близкую замену простому анимированному PNG.
Я про то что в статье сказано «Flash слишком нагружает процессор». Это как минимум некорректно. А если по честному — просто неправда.
Такие вещи можно реализовать на JS:
Берем PNG, в котором все кадры анимации расставлены в ряд.
Создаем DIV размером с 1 кадр и overflow: hidden;
Пихаем в него наш PNG с position: absolute, и изменением left: меняем кадры по таймеру.
UFO just landed and posted this here
Вариант с отдельным img лучше, если надо обеспечить кликабельность картинки (именно картинки, а не всего дива).
UFO just landed and posted this here
А как вы собрались отличить клик по диву в месте, где бэкграунда нет, от клика в месте, где бэкграунд есть?
UFO just landed and posted this here
ок ок, для случая обычной анимации вариант с бэкграундом дива лучше.
Дисклеймер: я, конечно, за прогресс, но давайте смотреть фактам в лицо.

> Flash в этом качестве даже не рассматривался – слишком нагружает процессор (1), плохо встраивается в страницу поверх других элементов(2), да и стоит не у всех(3).

Пункт раз — спорно. Не поленитесь, сделайте бенчмарк. Из собственного опыта могу сказать, что флэш реально тормозит или совсем криво написаный, или очень большой и под сафари на маке, и то есть варианты. Опять-таки, последние версии плеера используют хардварное ускорение как для 2d, так и для 3d и видео.

Пункт два — гм, возможно. Но пробовали ли вы использовать wmode? kb2.adobe.com/cps/155/tn_15523.html

Пункт три — у меня нет анимации в Хроме 11 и Сафари 5 на Mac OS 10.6.7. Позвольте на этом моменте попедантствовать.
Прошу внимания к следующим ссылкам: www.adobe.com/products/player_census/flashplayer/version_penetration.html
Ну или en.wikipedia.org/wiki/Adobe_Flash#User_experience, если угодно.
Минимальная цифра, которую я увидел тут — 92%. Действительно, восемь процентов — это существенно.

Давайте посчитаем сколько мы могли потерять только на хроме и сафари.
Источник — та же Википедия: en.wikipedia.org/wiki/Usage_share_of_web_browsers
Исхожу из того, что картинка не работает во всех версиях и на всех платформах браузеров — честно, лень искать и считать обратное. Если кому-то будет действительно интересно, погуглите.
Google Chrome (14.6%)
Safari (6.3%)
Итого, даже округлив, 20%.

PS. Ах да, еще какие-то версии IE не работают…
PSS. Ожидаю слив кармы. На здоровье. Только давайте так — минус в карму сопровождается коментарием. Сможете?
Google Chrome 13.0.767.1 dev, Linux, лис отлично крутится.
За что же вам карму сливать, право слово? Конструктивная критика только приветствуется.

> Из собственного опыта могу сказать, что флэш реально тормозит или совсем криво написаный, или очень большой и под сафари на маке, и то есть варианты.
Видите, вы сами сказали, что есть проблемы со скоростью на маке. От себя могу добавить, что на линуксе на Core 2 и GF 260 я могу играть только в очень простые игры на Flash. Сложные безбожно тормозят. Открытие параллельно 10 флешек (на одной странице или вкладок с YouTube) убивает процессор в ноль. Можно даже уронить иксы. Может быть, я делаю что-то не так, но ведь не от хорошей жизни появились Gnash, Swfdec и Lightspark? Каждый из которых также пока малоюзабелен.

> Но пробовали ли вы использовать wmode?
Конечно. На сколько я помню, есть проблемы с другими объектами, наложенными поверх такой флешки.

> Пункт три — у меня нет анимации в Хроме 11 и Сафари 5 на Mac OS 10.6.7.
Вот это уже серьезно. Тут я ничего не могу сказать, т.к. не имею мака, но оснований вам не верить у меня нет.
Я тоже каждый раз недоумеваю сливу кармы. Но я, собственно, не об этом.

Про тормоза.
Имхо вопрос очень и очень спорный. Линукс — да, это не целевая платформа, и Adobe не замечен в затачивании своего плагина под нее. Мое мнение, что флэш на андроиде будет работать лучше, чем под линуксом. Просто потому, что он важнее. Увы, увы. Какие следует сделать выводы? Если вы пишете хитрое приложение преимущественно под линукс, имеет смысл искать альтернативы. Если же линукс-пользователи планируются в долях процентов — лучшее враг хорошего. Тот же Youtube html5 сделал, но по умолчанию там флэш. И, кстати — вы Youtube смотрите с флэшем, ругаясь, или с html5? Но это тоже так, не по теме на самом деле.

По теме — есть такой бренд, Angry Birds. И у них недавно появилось html5 приложение. Признаться, у меня оно отъедает весь процессор в Хроме (MacOS, 2.5 core i5). Хотя по флэш-меркам, игра ничего особого не представляет. Ну про то, что флэш-игры у меня не тормозят, я боюсь просто говорить.

Про wmode:
Индивидуально. Спорить не буду. Сколько флэша использовал в своих проектах пока, это ни разу не являлось непреодолимым препятствием. Не уверен, что рассматривал все случаи.

Про анимацию.
Выше был коментарий, что в Хроме 13 под линуксом работает. Так что мои исходные 20% можно как минимум уменьшить до 10%. Все еще не считая IE.
Мое мнение, что флэш на андроиде будет работать лучше, чем под линуксом.

К сожалению, вы вполне можете оказаться правы. И здесь я, как разработчик, не-по-ни-маю! Ведь тот же линукс. Как можно заточить код под одну и не использовать его под другой платформой?

вы Youtube смотрите с флэшем, ругаясь, или с html5?

HTML5.
В любом случае замечание про тормознутость флеша некорректно. У меня на маке, если сделать аналогичный ролик аналогичным способом во флеш он будет отжырать 0% процессора, ваш ест 5%. Что меньше 5 или 0?
Ваши аргументы звучат примерно так «на флеше тормозят игры с физикой и сложной анимацией, а простенькая картинка на хтмл не тормозит — значит флеш тормознутый, а хтмл нет».

Флеш все же (тем более для такой простой задачи) плох. Он может забирать у страницы фокус (и нажатия горячих клавиш) при неосторожном клике, дыряв, и в некоторых бразуерах при запуске плагина сразу жэе подскакивает потребление памяти.

И на айпадике не заработает.

Тут все же проще сделать PNG со спрайтами и яваскриптом менять background-position: — именно так делает Гугл на своих анимированных логотипах. Правда, для ИЕ6 придется извратиться — там прозрачный фоновый пнг нельзя двигать, обходится созданием огромной картинки и сменой у нее свойств margin-left, margin-top и clip. Ну или сделать не совсем прозрачный GIF — а вот нефиг юзать такой страый браузер.
780КБ для такой простой анимации — это, по-вашему, нормально?
Где, как вам кажется, может найти применение данная наработка?
> 780КБ для такой простой анимации — это, по-вашему, нормально?
Во-первых, 587 КБ — SVGZ с сайта понимается всеми браузерами. Локально Файрфокс пока не открывает, в багзилле висит баг насчет этого.
Во-вторых, исходя из того, что в PNG применяется беспотерьное сжатие — вполне нормальный размер. Никто не запрещает использовать в кадрах JPEG.

> Где, как вам кажется, может найти применение данная наработка?
Для примера, если кодировать кадры в JPEG, можно реализовать превью видеороликов с плавной сменой кадров пока плеер не грузит видео/на паузе или в результатах поиска.
А если увеличить масштаб страницы в браузере, то анимация безбожно тормозит… Chrome 11.
UFO just landed and posted this here
UFO just landed and posted this here
В хроме тоже не заработало, в фф и опере нормально…
Вместо тега animate (или по по условию, что браузер его не поддерживает) можно использовать встроенный JS в SVG.
ff4 Ubuntu 11.04… тоже заметное подтормаживание (типа фпс низкий) и нагрузка проца высокая, будто он это изображение рендерит в реальном времени
Раз уж это практически единственный на Хабре топик про APNG, то напишу сюда (надеюсь, и автору интересно будет):

Библиотека для показа APNG при помощи canvas: github.com/davidmz/apng-canvas (БЕЗ предварительного раскладывания APNG на кадры)

Расширение для Хрома, включающее в нём показ APNG: chrome.google.com/webstore/detail/ehkepjiconegkhpodgoaeamnpckdbblp
Премного благодарен!
Sign up to leave a comment.

Articles

Change theme settings