В 2011 купил себе Corsair FORCE GS 128GB SSD. С тех пор сменилось 4 поколения интеловских камней, 2 поколения оперативки и 5 поколений графона от nVidia. На этом ssd несколько раз переставлялась система, он форматировался, на нем у меня живут Battlefield 4, Overwatch, ANNO 2205 и всякие файлы подкачки. С него же выполняются всякие операции в домашних проектах, критичные к скорости чтения с диска.
Сейчас 2016-ый год, ssd life все-еще утверждает, что жить диск будет до 2022. Полет нормальный.
Понятно, почему вынос меню вне .layout и применение transform увеличивают плавность, но совсем не понятно, почему добавление класса на время анимации делает это. Почему transition нет в .app-menu постоянно?
P.S. В коде в статье много семантических ошибок, советую смотреть код в оригинальной статье.
Спешу себя поправить по поводу «рендера в текстурку». Тут, возможно, я несколько погорячился, рендер в текстуру происходит не всегда, суть действительно в работе со слоями, но я боюсь даже представить насколько хитро работает внутри оптимизации. В текстуру он рендерит именно при афинных преобразованиях и прочих, производимых на видеокарте, не затрагивающих DOM (не приводящую к его пересчету). Это при медленных анимациях очень хорошо видно, покуда он применяет обычное сглаживание, характерное для текстур, а не pixel-perfect (т.е. черная линия в 1px будет выглядеть как серая в 2px).
Статья о том, как правильно пользоваться свойством will-change была как-то тут же на хабре, но, походу, канула в небытие, так что нашел похожую на dev.opera. Что касается горячих клавиш и, например, мобильных устройств — во втором случае все равно есть задержка в 40+ мс между событиями onTouch и onClick (не помню точно набор событий, но не суть), можно вешать на onTouch, а если пользователь не кликнул, а решил скроллить — отвешивать обратно. В случае горячих клавиш — вообще не использовать, оставлять это свойство только на тех элементах, которые с большей частью вероятности будут анимированы.
will-change. Оно указывает браузеру переместить элементы в отдельный слой так, чтобы он затем не проверял весь каркас на предмет сборки или отрисовки.
Нет, оно работает несколько иначе. Дело в том, что когда применяется анимация с transform, браузер копирует отрисованный элемент в виде текстуры и двигает уже непосредственно её. Однако, покуда он не знает, когда будут проводиться эти самые анимации, а держать и перерисовывать в памяти кучу подобных текстурок накладно, он это по-умолчанию делает в момент когда анимация началась, именно по этому он может (и обычно делает это) подвиснуть вначале анимации и сделать её не плавной. will-change говорит ему о том, что этот объект будет изменяться через animation и эту процедуру рендера в текстуру необходимо сделать заранее. Вот только после этого ему постоянно нужно проделывать достаточно много лишней работы (даже если вы просто будете водить курсором по пунктам меню), а так же будет жрать лишнюю память. Как следствие — это свойство лучше всего использовать ровно перед тем, как сама анимация будет совершена, например, навешивать это свойство при ховере, иначе пользователи будут вам благодарны, что у них браузер анимации воспроизводит плавно, но памяти стал есть в два раза больше.
P.S. На сколько я знаю, справедливо для webkit, gecko и как там у Edge движок называется, вероятно, весь процесс реализован иначе.
Этого уже достаточно и с производительностью все ok. А дичь, которую предлагают в конце статьи — это какие-то извращения с костылями. И не факт, что через n месяцев оно по прежнему будет выигрывать в производительности, потому что оптимизировать будут именно приведенный выше код.
На самом деле это далеко не так.
Начиная от того что в Вашем примере не используются 3d трансформации, и заканчивая тем что Вы используете проценты.
Создайте страницу с большим количеством тегов и посмотрите на Ваш пример в дев тулс.
После этого примените 3d трансформацию но оставьте проценты
И после этого замените проценты на пиксели.
Так и знал, что будет использовано какое-то магическое свойство, которое в половине браузеров не работает. Ну и за одно выдержки с MDN:
— Не применяйте will-change к большому числу элементов.
— Используйте умеренно.
— Не применяйте will-change к элементам для выполнения преждевременной оптимизации.
— Дайте ему достаточно времени, чтобы работать.
Ухты, webperf 101 в 2016 году на хабре, вот это да!
И еще забавно читать про «будущее за will-change». Это казалось будущим 2 года назад, но по итогам от этого свойства было скорее больше проблем, чем пользы, и оно все еще не поддерживается в IE/Edge, так что лучше по-стариночке юзать translate3d() там, где это необходимо.
Конкретные IQ тесты могут и устареть. Но принцип всё равно останется прежним и в новых тестах. Поскольку интеллект — это способность распознавать закономерности/контексты (т.е. способность к самообучению на произвольных данных), то общая идея измерения уровня интеллекта всё равно должна сводиться к тому, чтобы выявить, насколько сложные закономерности человек может распознать. Даже у обезьян способности к обучению проверяют через умение распознавать закономерности. Конечно, обезьян тестируют чуть-чуть по-другому. У них нет такой мелкой шкалы уровней, как IQ, а есть всего три уровня обучаемости. На самом деле, даже два, поскольку третьего уровня ни одна обезьяна пока не продемонстрировала. Есть даже гипотеза о том, что животные в принципе не способны к третьему уровню, что это особенность людей (кстати, далеко не всех… но многих). Но в любом случае концептуально тест для людей и тест для обезьян ничем не отличаются. Всё равно решение теста сводится к выявлению закономерностей.
Если не изменяет память, то на данный момент многие ученые заявляют о, по сути, бесполезности IQ метрик, так как тесты очень старые и не соответствуют действительному историческому контексту. В общем, обновить их надобно.
Неспособность распознать контекст — это всегда следствие низкого уровня интеллекта. Неслучайно тесты IQ построены таким образом, чтобы выявлять способности испытуемых распознавать закономерности. Закономерность — это когда смысл отдельных элементов зависит от контекста. Чем более запутанную закономерность человек может распознать, тем более широкий контекст он способен схватывать. И эта его способность численно выражается через коэффициент IQ.
Проблема контекста — это процесс воспитания. Для человека это занимает годы учебы и практики в конкретной области,
Причем смена области деятельности низводит, как правило, на нулевой уровень понимания.
То есть непонимание контекста, точнее его невоспириятие, это не признак низкой интеллектуальности, а отсутвие ус тойчивых когнитивных связей.
Заметим, что человек часто действует стереотипно, не проявляя интеллекта, как возможности творческой оценки ситуации.
Это и дает обычно преимущество компьютеру в использовании стереотипов, как возможности более быстрого их перебора.
Очень порадовала оговорка во врезке про то, что понимание языка искусственным интеллектом так трудно запрограммировать из-за того, что смысл отдельных слов зависит от контекста. С учетом того, что суть естественного интеллекта состоит в способности быстро и точно распознавать контекст, получается, что понимание языка искусственным интеллектом так трудно запрограммировать, потому что трудно запрограммировать интеллект. Кто бы мог подумать? Оказывается, при программировании искусственного интеллекта легко запрограммировать только искусственность, а вот с интеллектом уже намного сложнее.
Мой любимый пример про смысл слов, который зависит от контекста: «Американцы слишком много жрут». На форуме хейтеров Америки эта фраза будет означать «Граждане США употребляют слишком много пищи». А на автомобильном форуме эта же фраза будет означать «Автомобили американского производства потребляют слишком много топлива». У естественного интеллекта нет никаких проблем с пониманием, поскольку он обычно точно знает, на каком именно форуме он сейчас бессмысленно тратит время.
Сейчас 2016-ый год, ssd life все-еще утверждает, что жить диск будет до 2022. Полет нормальный.
P.S. В коде в статье много семантических ошибок, советую смотреть код в оригинальной статье.
Статья о том, как правильно пользоваться свойством will-change была как-то тут же на хабре, но, походу, канула в небытие, так что нашел похожую на dev.opera. Что касается горячих клавиш и, например, мобильных устройств — во втором случае все равно есть задержка в 40+ мс между событиями onTouch и onClick (не помню точно набор событий, но не суть), можно вешать на onTouch, а если пользователь не кликнул, а решил скроллить — отвешивать обратно. В случае горячих клавиш — вообще не использовать, оставлять это свойство только на тех элементах, которые с большей частью вероятности будут анимированы.
Нет, оно работает несколько иначе. Дело в том, что когда применяется анимация с transform, браузер копирует отрисованный элемент в виде текстуры и двигает уже непосредственно её. Однако, покуда он не знает, когда будут проводиться эти самые анимации, а держать и перерисовывать в памяти кучу подобных текстурок накладно, он это по-умолчанию делает в момент когда анимация началась, именно по этому он может (и обычно делает это) подвиснуть вначале анимации и сделать её не плавной. will-change говорит ему о том, что этот объект будет изменяться через animation и эту процедуру рендера в текстуру необходимо сделать заранее. Вот только после этого ему постоянно нужно проделывать достаточно много лишней работы (даже если вы просто будете водить курсором по пунктам меню), а так же будет жрать лишнюю память. Как следствие — это свойство лучше всего использовать ровно перед тем, как сама анимация будет совершена, например, навешивать это свойство при ховере, иначе пользователи будут вам благодарны, что у них браузер анимации воспроизводит плавно, но памяти стал есть в два раза больше.
P.S. На сколько я знаю, справедливо для webkit, gecko и как там у Edge движок называется, вероятно, весь процесс реализован иначе.
Этого уже достаточно и с производительностью все ok. А дичь, которую предлагают в конце статьи — это какие-то извращения с костылями. И не факт, что через n месяцев оно по прежнему будет выигрывать в производительности, потому что оптимизировать будут именно приведенный выше код.
Начиная от того что в Вашем примере не используются 3d трансформации, и заканчивая тем что Вы используете проценты.
Создайте страницу с большим количеством тегов и посмотрите на Ваш пример в дев тулс.
После этого примените 3d трансформацию но оставьте проценты
И после этого замените проценты на пиксели.
— Не применяйте will-change к большому числу элементов.
— Используйте умеренно.
— Не применяйте will-change к элементам для выполнения преждевременной оптимизации.
— Дайте ему достаточно времени, чтобы работать.
И еще забавно читать про «будущее за will-change». Это казалось будущим 2 года назад, но по итогам от этого свойства было скорее больше проблем, чем пользы, и оно все еще не поддерживается в IE/Edge, так что лучше по-стариночке юзать translate3d() там, где это необходимо.
Причем смена области деятельности низводит, как правило, на нулевой уровень понимания.
То есть непонимание контекста, точнее его невоспириятие, это не признак низкой интеллектуальности, а отсутвие ус тойчивых когнитивных связей.
Заметим, что человек часто действует стереотипно, не проявляя интеллекта, как возможности творческой оценки ситуации.
Это и дает обычно преимущество компьютеру в использовании стереотипов, как возможности более быстрого их перебора.
Мой любимый пример про смысл слов, который зависит от контекста: «Американцы слишком много жрут». На форуме хейтеров Америки эта фраза будет означать «Граждане США употребляют слишком много пищи». А на автомобильном форуме эта же фраза будет означать «Автомобили американского производства потребляют слишком много топлива». У естественного интеллекта нет никаких проблем с пониманием, поскольку он обычно точно знает, на каком именно форуме он сейчас бессмысленно тратит время.