Мартин Грэслин (Martin Graesslin), один из ключевых разработчиков оконного менеджера KWin, представил (http://blog.martin-graesslin.com/blog/2012/01/kwin-effects-w.../) новое достижение на поприще интеграции (http://www.opennet.me/opennews/art.shtml?num=32730) поддержки JavaScript: визуальные эффекты для KWin теперь можно создавать на языке JavaScript, а не только на C++.
C точки зрения производительности, эффекты на JavaScript ничем не отличаются от эффектов на C++. Система наложения эффектов в KWin разделена на две стадии: реагирование на изменение в оконном менеджере (например, закрытие окна) и рендеринг. Скриптовый API взаимодействует только с оконным менеджером и не касается отрисовки, все операции рендеринга как и раньше производятся низкоуровневыми подпрограммами на C++.API для разработки эффектов максимально приближен к API для разработки скриптов-дополнений к KWin. Для создания анимационных эффектов предлагается использовать API, базирующийся на п...
URL: http://blog.martin-graesslin.com/blog/2012/01/kwin-effects-w.../
Новость: http://www.opennet.me/opennews/art.shtml?num=32948
> C точки зрения производительности, эффекты на JavaScript ничем не отличаются от эффектов на C++ну хорошо.
жду эффектов на PHP, Python... ^_^
Не надо питона, мне уже хватило выколупывания значков в трее на этом по 20 мегз штучка!
Вас тоже вынужден отправить взглянуть на ман по сарказму ;)
> Вас тоже вынужден отправить взглянуть на ман по сарказму ;)man что?
>> C точки зрения производительности, эффекты на JavaScript ничем не отличаются от эффектов на C++Написано слишком расплывчато чтобы не придрались (или сравнивали "на глаз"). Любой, более менее понимающий разницу между С++ и ECMAScript поставит под сомнение это заявление.
>ну хорошо.
То что вы сглотнули заявление без анализа - вам чести не прибавляет.
>жду эффектов на PHP, Python... ^_^
В PHP - ладно, уйдет в web, а вот пидоны не нада нафиг.
> То что вы сглотнули заявление без анализа - вам чести не прибавляет.читайте ман по сарказму ;)
>читайте ман по сарказму ;)Не распарсил?
> Не распарсил?Ман по сарказму? ;]
>Ман по сарказму? ;]Цикл?
>новое достижение
>JavaScript
>визуальные эффекты для KWin
>WebGLКак бы в итоге сам Kwin не переписали на яваскрипте с рендером на WebGL -_-
И почему все так и норовят переписать весь софт на яваскрипте?
Потому что если прикрутить jit, то все начинают понимать что лучше быстрее разрабатывать, чем долго компилить.
В общем-то, это даже интересно. Но к javascript'у надо привыкать некоторое время, потому что он, имхо, вообще нафиг нечитабельный в том виде, в каком на нём пишут.
А вы не читайте советских газет, то есть творчества быдлокодеров.
> А вы не читайте советских газет, то есть творчества быдлокодеров.А вы себя к этому направлению не относите?
Ну, у вас одно ИМХО, у других программистов другое ИМХО. JS популярный язык, в котором отношение количества выполняемых действий к количеству строк кода довольно велико.
Эффект от отсутствия компиляции нивелируется отсутствием статической типизации. Те ошибки, которые в С++ отлавливаются при компиляции в JS приходится искать дебаггером в рантайме, что отнимает намного больше времени. Аргумент не катит.
Это называется обфускация :)
> Это называется обфускация :)Иди на брейнфаке пиши - тебе понравится. Там вся программа - сплощная обфускация. Зато я тебе гарантирую что твою программу никто не сопрет. В силу мучительности этого процесса.
>Это называется обфускация :)Какая тут к черту обфускация, когда человек пишет про compile-rime vs run-time, а?
//лузер, вернись к обсуждению: http://www.opennet.me/openforum/vsluhforumID3/82693.html#30
Откройте для себя юнит тестирование.
Динамические языки надо запретить, т.к. Толстый их не понимает. И правоассоциативные операторы с ними, они вносят сумятицу в неокрепший ум. И интерпретаторы. И программирование. И запускать программы не надо. Только компиллировать.
> Динамические языки надо запретить, т.к. Толстый их не понимает.Я б сказал что типизация позволяет ловить кучу багов на этапе компиляции. А у JS ни вам типизации, ни компиляции. И объявление переменных без кейворда. Ну просто все чтобы можно было удобно... где-нить... обосраться в коде и потом неделю сношать себе мозг при достаточном размере кода - "блин, почему же тут возникает этот бред?!" :).
Все-таки хорошо если тебя предупреждают когда ты сравниваешь автобус и бананы, а не просто выдают результат, посчитав что так и надо.
Если вы пишете тесты с хорошим покрытием у вас мало багов. Если вы не пишете тесты,с хорошим покрытием, у вас много багов.
Все остальное, как то: вид типизации, длинна бороды программиста и фазы луны, на качество кода не влияют.
> Если вы пишете тесты с хорошим покрытием у вас мало багов. Если
> вы не пишете тесты,с хорошим покрытием, у вас много багов.Понимаешь, если часть багов отстрелена на уровне валидации сорца - ловить тестами придется меньше багов. Более того, как известно, программа не может полностью проанализировать другую произвольную программу и выдать однозначный вердикт. Что означает что любой тест так или иначе не найдет энное число багов.
> Все остальное, как то: вид типизации, длинна бороды программиста и фазы луны,
> на качество кода не влияют.Да как сказать? JS прост в освоении. Поэтому ща на нем побежит писать толпа обезьян которые вообще ни в зуб ногой не шарит по поводу того что оказывается автобусы с бананами сравнивать странно. Ну и нас завалит гoвнокодом, среди которого нормальный выбирать - замучаешься потом.
> программа не может полностью проанализировать другую произвольную программу и выдать однозначный вердиктУтверждение применимо и к компиляции. Так что тут о двух концах палка.
> И объявление переменных без кейвордас дуба свалилсся чтоле x_X ? освой наконец уже в Javascript -- синтаксисическую конструкцию "use strict"
И щито? Есть места (типа IE) гиде ваш юз скрипт не работает и всем насрать. Так-то :)
И давно IE стал движком JS для KDE?
> И объявление переменных
> без кейворда ...нету, не видел такого
В фоксовском движке, например, сделали нечто вроде промеждуточной модели между динамической и статической типизацией. Компилер определяет что и какого типа попадает в переменные, и если код писал не сотона, то у него это получается. Дальше он ими оперирует уже как статически-типизированными и вроде даже может сообщать о случаях когда переменная в одном месте определяется одним типом, а потом внезапно его меняет на пол-пути.
> Потому что если прикрутить jit, то все начинают понимать что лучше быстрее
> разрабатывать, чем долго компилить.Ага, только вот работает потом так что 4-ядерник становится унылее первопня. Хотя по скорости вычислений и делает его раз в 100.
Не надо путать производительность Javascript и производительность манипуляций с DOM в браузере.
> Не надо путать производительность Javascript и производительность манипуляций с DOM в браузере.А с фига ли динамически типизируемый язык в котором даже массивов нормальных (позволяющих работать с данными побайтово, без диких изгалений и костылей) станет быстрее плюсов? При таком поднасирании в исходных установках никакой jit сие не скомпенсирует. Ну и памяти оно может выжрать прорву, а отдаст... когда-нибудь... может быть... если кому будет не влом дебажить - утечка ли это или gc протормозил. Как все это работает - ежику понятно. Будет у кед системным требоавнием минимум 2 гиг памяти и ребут машины раз в три дня :)
>А с фига ли динамически типизируемый язык в котором даже массивов нормальных (позволяющих работать с данными побайтово, без диких изгалений и костылей)data = new Int32Array()
>Ну и памяти оно может выжрать прорву, а отдаст... когда-нибудь... может быть... если кому будет не влом дебажить - утечка ли это или gc протормозил. Как все это работает - ежику понятно. Будет у кед системным требоавнием минимум 2 гиг памяти и ребут машины раз в три дня :)Смайлик в конце не оправдывает идиотизма претензий.
>станет быстрее плюсов?Скорость программы определяется качеством выбранных алгоритмов и мало зависит от языка программирования.
> data = new Int32Array()Ага, а это работает в том js который в кедах?
> Смайлик в конце не оправдывает идиотизма претензий.
А вы приходите через пару лет и мы послушаем как вы будете лечить что "да ладно, память дешевая, блаблаблаблабла" :)
> Скорость программы определяется качеством выбранных алгоритмов
Несомненно.
> и мало зависит от языка программирования.
Смотря с чем сравнивать. Если конечно сравнивать линейный перебор массива на 100500 миллионов элементов с деревом или хэш-таблицей, оно конечно да. Но в свои несколько раз JS сольет на одном и том же алгоритме. Ну кроме случая когда это - ничегонеделание и ожидание действий юзера.
Внезапно да! Да и не за горам V8
> А вы приходите через пару лет и мы послушаем как вы будете
> лечить что "да ладно, память дешевая, блаблаблаблабла" :)Смайлик в конце не оправдывает идиотизма претензий.
> Смотря с чем сравнивать. Если конечно сравнивать линейный перебор массива на 100500
> миллионов элементов с деревом или хэш-таблицей, оно конечно да. Но в
> свои несколько раз JS сольет на одном и том же алгоритме.
> Ну кроме случая когда это - ничегонеделание и ожидание действий юзера.
>одном и том же алгоритмеА программисты на С++ способны освоить алгоритмы? Правда? Так чего они ждут?
Насколько я понял из новости, эффекты написаны на C++, а на JavaScript'е просто написаны (будут) скрипты для запуска эффектов. Например:
Подключить рябь.длл //Написан на C++ и окомпелированная библиотека с реализацией функции рябь()
Если окно получило фокус, то выполнить рябь().Что-то вроде того.
P.S. Не силен я в программировании, тем более в JavaScript'е. Изучал чисто для того чтобы получше разбираться в компьютерах.
> Насколько я понял изновости, эффекты написаны на
C++, а на JavaScript'е
> просто написаны (будут)скрипты для запуска эффектов.
Например:
> Подключить рябь.длл //Написан на C++ и
окомпелированная библиотека
с реализацией функции
> рябь()
> Если окно получило фокус, товыполнить рябь().
> Что-то вроде того.
Похоже на то, этакий avisynth
Создатели KDE движутся в правильном направлении. Берут пример с GNOME 3.
Ну чего так все увлекаются этим JavaScript?Лучше бы Lua, почему? Да он проще в обучении...
У Qt есть удобная интеграция с а-ля JavaScript (Qt Script). Для Lua нет. Кроме того, QML и пр. тоже юзают JavaScript - нет смысла разводить зоопарк языков
А что за элемент AnimationEffect? Упоминаний о нём я не нашёл в Qt 4.8.
> представил реализацию на JavaScript известного эффекта затухания (Fade), вариант на C++ которого занимает более 200 строк, а на JavaScript укладывается в 7 строк:В 29 раз короче, это замечательно. Еще лучше будет, когда это будет означать в 29 раз быстрее скорость выполнения..
> означать в 29 раз быстрее скорость выполнения..Звезды погаснут раньше.
Сколько в 29 строках кода на с++ может быть утечек памяти? Две? Три? А уязвимостей?
> Сколько в 29 строках кода на с++ может быть утечек памяти? Две? Три?Как будто с JS память не может течь. Не, ну что за ламерство, а?
> А уязвимостей?
Уязвимостей эффекта окон? Это вобще как? oO
>Как будто с JS память не может течь.
>Как будто в С++ память не может НЕ течь.Как то так.
>Уязвимостей эффекта окон? Это вобще как? oO
// for debug
printf(windowTitle);
см новость о sudo.
посмешил, спасибо. в Qt если что - QString, такие дела
Их там может быть ровно 0, причём с очень большой вероятностью.
Ноль, говорите? С очень большой вероятностью, говорите?
А знаете сколько багов было исправлено в плазме, например?
https://bugs.kde.org/reports.cgi?product=plasma&output=show_...
16 @#$@#%! тысяч, и тысяча еще не закрыта.
В Конкьюере вообще 25 000.
Теперь еще раз расскажите, что "Статическая типизация защит нас от ошибок" или что "разработчики KDE могут писать безупречный код". Я посмеюсь.
А вы думаете, будь они на JS, ошибок было бы меньше?
А чем им QML и его shader плагин не угодил?*с тоской посмотрел на wayland и qml-compositor, где эффекты на яваскрипте летают*
Нафик не нужна ваши строгая типизация. ДЕЙСТВИЕ должно определять тип данных.# perl -e '$a=1; $b=2; print($a+$b,"\n")'
3
# perl -e '$a=1; $b=2; print($a.$b,"\n")'
12Никогда никаких неожиданностей не возникнет. Фактически, программа будет работать так, как надо. То, как она работает, должно зависеть от того, что вы напишите в ДЕЙСТВИИ. При строгой типизации работа программы зависит от того, что вы напишите в типах, действия с типами. Это плохо. Долой типизацию, действия должны определять результат.
Люблю perl.
perl -e '$a="ha"; $b=2; print($a+$b,"\n")'
2это нормально?
Безусловно. В общем случае - перед действием достаточно простой проверки. или после получения результата.
Но я тоже "ЗА" то, что бы действие над данными определяло результат единолично, каковы бы небыли данные. Это поможет избежать дебильных рантайм ошибок.
> Это поможет избежать дебильных рантайм ошибок.По мне так как раз наоборот.
> По мне так как раз наоборот.Не наоборот, а так и есть. Ошибок не будет, будут нормально обрабатывать входные данные. Да, результат будет зависеть от данных, но проверяйте данные, кто ж вам запрещает, вы же итак это делаете. Странные данные на выходе? Ну поглядите - что вы подали на вход? Проверяйте.
Ага, кроме обычных проверок по бизнес-логике, еще в каждой зачуханной функции делать проверку на соответствие типов переданных значений? Может пусть лучше это компилятор сразу проверит?
Мож, кто эффект снега снова запилит.