Ну muticolor эффект просто по определению не может быть НЕ 50fps :) Конечно возможно перестройка самого туннеля идет не каждый фрейм, но отрисовка обязана быть 50fps, по-другому работать не будет.
Пример. 8bit, 3.5MHz, 64x32 но нужно учитывать что это multicolor т.е. помимо самого эффекта еще значительное время тратится на его правильный вывод. Впрочем вы и без меня все это знаете :)
Ну если бы это была единственная несправедливость этого мира… :)
Вообще Chrome по-моему опыту довольно стабилен в плане соответствия результатов ожиданиям, хотя да, иногда выдает закидоны. Стабильнее всех FF за что его и люблю (ну и за Firebug конечно же :) )
Можно использовать тот же Modernizr или любой другой скрипт для определения необходимых уловий с последующим заданием CSS class у <html> а потом задавать нужные CSS хаки в контексте выставленного class'а.
Все это классно и, уверен, IE10 будет весьма адекватным браузером. Вот только нам (веб разработчикам) еще долго придется учитывать наличие «тяжкого наследия» Microsoft в виде IE7, IE8 (хоть IE6 фактически ушел — и то радует), так что до IE10 в качестве mainstream еще не скоро дело дойдет, а жаль.
Вот если у этого hud интерфеса сделать так чтобы когда вводишь имя опции, справа отображалось окно с функциями этой опции с галками, т.е. ты тыкаешь в галки и в строку добавляются операторы — вот это будет вообще гениальная штука для интерфейса. Примерно так:
Да, LESS я не использовал, синтаксис SCSS показался более логичным, а возможностей побольше. Compass — это в принципе просто framework вокруг SASS предлагающий массу готовых решений типовых задач в виде mixins.
Например:
— готовая и прозрачная кастомизация CSS3 стилей с подстановкой префиксов специфичных для браузера
— работа с CSS Sprites (и их автоматическая генерация)
— и многое другое :)
К примеру SCSS селектор из приведенного вами (в комментарии ниже) примера SCSS кода:
Согласен, даже если рассматривать только работу подсистемы стилей в браузере то IMHO задача matching'а CSS правил на DOM nodes по затратам никак не может сравниться с задачей отрисовки DOM элементов страницы с наложенными на них CSS стилями. Т.е. например правило:
#someElement {
opacity: ...;
background-image: ...;
....
/* а можно и CSS 3D transformations и прочие плюшки ... */
}
По-моему подобной функции (компиляции LESS на клиенте) не место на production, а насколько это удобно при разработке — тут видимо решать каждому самостоятельно.
У Compass есть замечательная функция, его можно запустить в режиме отслеживания изменений, при этом на каждое изменение .scss файла в проекте от производит инкрементальную (быструю) компиляцию, так что обычно за время пока я переключаюсь из редактора в браузер и нажимаю там F5 — обновленная версия скомпилированного CSS файла уже лежит в каталоге сайта и, соответственно, подгружается в браузер.
Я тоже могу ошибаться, но учитывая опыт последних нескольких проектов (в которых был использован альтернативный, но решающий ту же задачу проект Compass) могу сказать что заметных на глаз проблем с производительностью при отрисовке страниц не было ни в одном браузере.
Думаю что если сравнивать потенциальную дополнительную нагрузку для браузера от «тяжелого» селектора и от скрипта — то последняя будет, как правило, больше.
Зато реализация стилей на LESS (или SASS/SCSS/Compass) позволяет экономить кучу времени на разработке проекта и еще бОльшую кучу сил (и нервов :) ) на его поддержке т.к. позволяет иметь структурированный и разбитый на логические блоки код вместо «спагетти» стилей в которые превращается почти любой изначально хорошо сделанный CSS код после несколько раундов правок и доработок.
Во-первых как девелопер люблю Firefox в первую очередь за то что он наиболее предсказуем в плане разработки — как правило его рендеринг преподносит меньше всего сюрпризов, так что используется как reference под который потом фисится рендер в остальных браузерах.
Во-вторых, конечно же, Firebug, все-таки по удобству работы с ним не сравнится ни один из встроенных отладчиков в других браузерах.
В-третьих — привычка т.к. являюсь пользователем Mozilla (не Firefox, а оригинальной Mozilla) еще с версий в районе 0.6.x
Chrome использую для Gmail и прочих Google Docs т.к. их реализация вкладок в отдельных процессах позволяет быстрее освободить память от довольно тяжелых JS приложений.
Частный пример когда использование массивов в качестве аргументов, IMHO, вполне оправданно — параметры конфигурации. Зачастую их больше одного т.е. скалярные типы не подходят и, как правило, задание этих параметров опционально т.е. в виде списка аргументов их не перечислишь. Конечно можно использовать setter'ы, но они подходят только в случае задания конфигурации самого объекта, но не подходят для «временного» изменения параметров конфигурации на момент вызова какого-то метода класса.
Другой пример — передача набора данных, содержимое которого заранее не определено, например список параметров запроса.
Поменяли ведь они Ins/Del в линейке ThinkPad, может и на это решатся.
Самое обидное — никакой альтернативы с нормальным классическим блоком этих клавиш в линейке не осталось. Если соберусь менять ноут — прямо хоть клавиатуру от старого переставляй :)
DR forever :)
Вообще Chrome по-моему опыту довольно стабилен в плане соответствия результатов ожиданиям, хотя да, иногда выдает закидоны. Стабильнее всех FF за что его и люблю (ну и за Firebug конечно же :) )
Например:
— готовая и прозрачная кастомизация CSS3 стилей с подстановкой префиксов специфичных для браузера
— работа с CSS Sprites (и их автоматическая генерация)
— и многое другое :)
К примеру SCSS селектор из приведенного вами (в комментарии ниже) примера SCSS кода:
можно было бы оптимизировать в Compass как:
… и обрести независимость от возможных проблем из-за изменений размеров картинки. Или еще лучше:
будет в сумме явно менее затратно чем:
У Compass есть замечательная функция, его можно запустить в режиме отслеживания изменений, при этом на каждое изменение .scss файла в проекте от производит инкрементальную (быструю) компиляцию, так что обычно за время пока я переключаюсь из редактора в браузер и нажимаю там F5 — обновленная версия скомпилированного CSS файла уже лежит в каталоге сайта и, соответственно, подгружается в браузер.
Думаю что если сравнивать потенциальную дополнительную нагрузку для браузера от «тяжелого» селектора и от скрипта — то последняя будет, как правило, больше.
Зато реализация стилей на LESS (или SASS/SCSS/Compass) позволяет экономить кучу времени на разработке проекта и еще бОльшую кучу сил (и нервов :) ) на его поддержке т.к. позволяет иметь структурированный и разбитый на логические блоки код вместо «спагетти» стилей в которые превращается почти любой изначально хорошо сделанный CSS код после несколько раундов правок и доработок.
Во-вторых, конечно же, Firebug, все-таки по удобству работы с ним не сравнится ни один из встроенных отладчиков в других браузерах.
В-третьих — привычка т.к. являюсь пользователем Mozilla (не Firefox, а оригинальной Mozilla) еще с версий в районе 0.6.x
Chrome использую для Gmail и прочих Google Docs т.к. их реализация вкладок в отдельных процессах позволяет быстрее освободить память от довольно тяжелых JS приложений.
Другой пример — передача набора данных, содержимое которого заранее не определено, например список параметров запроса.
Спасибо Speccy за наше счастливое программерское детство :)
Самое обидное — никакой альтернативы с нормальным классическим блоком этих клавиш в линейке не осталось. Если соберусь менять ноут — прямо хоть клавиатуру от старого переставляй :)
*Посматривая на свою нокию 6230i* Аппарат с датой выхода — конец 2009-го года, оказывается, уже старичок… Экзамен на гика я точно провалил :)