Компания Adobe выпустила (http://labs.adobe.com/technologies/flashplatformruntimes/fla.../) первую бета-версию Flash Player 11.2 (http://labs.adobe.com/downloads/flashplayer11-2.html). Новая версия примечательна добавлением поддержки многопоточного декодирования видео для платформ Windows, Mac OS X и Linux, что позволяет добиться заметно большей производительности и отзывчивости интерфейса при воспроизведении видео высокого разрешения на любых системах с поддержкой аппаратных механизмов акселерации декодирования видео (в Linux пока поддерживается только Broadcom Crystal HD и NVIDIA VDPAU).Отмечается, что реализация многопоточного декодирования видео сопряжено со значительной сменой внутренней архитектуры, что открывает двери для реализации новых интересных возможностей в будущем. Среди заметных улучшений, связанных с поддержкой многопоточного декодирования видео: устранение дрожания изображения при воспроизведении потокового видео и в некоторых сценариях взаимодействия ...
URL: http://labs.adobe.com/technologies/flashplatformruntimes/fla.../
Новость: http://www.opennet.me/opennews/art.shtml?num=32146
Чувствую, не скоро их gnash'евцы догонят... А жаль.
А кто-то ещё надеется на это?The latest beta release of Gnash has been made at version 0.8.9 in mid March, 2011
В Gnash давно VA-API.
С видео может и догонит. А вот со всем остальным у gnash большие проблемы и там действительно скорее всего не догонит.
Только вот flash для видео уже не нужен так как все нормальные сайты на html5 переходят.
Ага. А теперь заставьте их (компоненты бразуеров) юзать XvMC/VDPAU.
Браузеры которые не изобретают свой велосипед а используют например gstreamer для воспроизведения видео (opera, midori) сразу и поддерживают ровно то что gstreamer умеет. А ускорение видеокартами он умеет.
> Ага. А теперь заставьте их (компоненты бразуеров) юзать XvMC/VDPAU.VDPAU??? %) %)
а кажется понял!...
....далее ты скажешь:
"а теперь заставте всех пользователей купить видиокарту от Nvidia"...
а потом (через несколько лет) скажешь:
"а теперь заставте всех пользователей удалить Wayland и установить проприетарный драйвер!":-D хитрый план однако! :-D :-D
> Чувствую, не скоро их gnash'евцы догонят... А жаль.Действительно. Раньше они станут все не нужны, потому что HTML5 и так умеет все то же что и флеш, только без дебильных дырявых плагинов.
неужели? а потоковое видео он тоже умеет?
Буквально недавно экспериментировал. Источником была веб-камера. Поток вещал через vlc по http а проигрывался через html5. Для просмотра просто потребовалось вместо пути к файлу адрес потока указать в коде страницы и все нормально проигрывалось. Так что умеет.
> неужели? а потоковое видео он тоже умеет?Вообще-то, уже давно.
Но при этом совершенно непонятно стремление возложить функции обычного медиа-плеера на браузер. Стандарт на RTSP известен уже давно, скормил урлу любому нормальному плееру (просто щелкнув по ссылке в браузере), и любуйся. Нет, им зачем-то интегрированный в браузер плеер надо. Ждем, когда начнется шквал воплей "а почему ваш гадкий HTML5 музыку из моей домашней папки не играет?" А когда сделают и это - "почему кофе не варит?"
В общем, свинья везде грязь найдет.
> Действительно. Раньше они станут все не нужны, потому что HTML5 и так
> умеет все то же что и флеш, только без дебильных дырявых
> плагинов.HTML5 сейчас явно проигрывает флешу хотя бы потому, что во флеше хорошо отработаны технологии баннеров, тизеров, наложения рекламы на видео и т.д. Проще говоря, флеш - это основа современной навязчивой рекламы в интернете. И портирование соответствующего инструментария под HTML5 требует определенных усилий. Именно из-за этого и не стихает пока шквал воплей "ваш HTML5 - отстой, флеш рулит!!1"
А всего-то людям надо - баннер показать, да чтоб поярче и дергалось.
>А всего-то людям надо - баннер показать, да чтоб поярче и дергалось.а людям ваш баннер НЕ нужен! ;)
>Чувствую, не скоро их gnash'евцы догонят... А жаль.Да ладно вам. Всегда есть "ведуший" и "ведомый" которывй вечно гонится за первым. Так было всегда и будет.
А так в целом отличная новость. Спасибо.
Фишка в том что обычно когда ведущий - проприетарщина и она кому-то оказывается нужна, он мгновенно становится сначала ведомым, а потом умирает, потому что ведомому платить никто не будет. Но flash представляет из себя такую бесполезную муть, что переписывать его никто особо не чешется. gnash скорее жив, чем мёртв. lightspark вообще никогда не работал, хотя архитектура и подход там гораздо более вменяемые были.
s|скорее жив, чем мёртв|скорее мёртв, чем жив|
Теперь просмотр видео во флеше будет нагружать на 100% все имеющиеся ядра цпу, а не только одно.
И не говорите :((Постоянно ведь, открыты вкладки в браузере, где-то там в фоне флешка-другая, потом смотришь top и видишь:
2557 2488 stax 2706:09 224m 17m 2324m 20 0 R 2 126.1 2.8 plugin-containe
Вот прямо сейчас ест 126%, да. Никакого видео и т.п не отображает - только флеш-реклама где-то в фоне.
$ ps auxwww|grep 2557
stax 2557 115 2.7 2380212 222928 ? Rl Oct26 2712:18 /usr/lib64/firefox/xulrunner/plugin-container /usr/lib64/flash-plugin/libflashplayer.so -greomni /usr/lib64/firefox/xulrunner/omni.jar -appomni /usr/lib64/firefox/omni.jar 2488 true plugin
Убиваешь этот флеш, на следующий день обычно опять.. С быстрым процессором и несколькими ядрами (у меня Core i5-2500K) обычно это незаметно, разве что частота ядер не может опуститься до минимума, но если оно будет жрать все ядра - будет совсем плохо.Хотя там и так много тредов
$ ps auxH|grep plugin-container|grep libflashplayer|wc -l
18что позволяет ему сожрать >100% cpu.
В файрфоксе сие легко лечится использованием AdBlockPlus с правильной подпиской. Ну а если совсем одолели - есть тяжелая артиллерия: noscript. Отшивает вообще всю жручую интерактивность. Хоть js, хоть флеш, хоть что. Останется лишь то что вы явно разрешите.
В данном случае логичнее использовать FlashBlock.
> В данном случае логичнее использовать FlashBlock.Упомянутые как-то кардинальнее и эффективнее. Мастхэв!
Достаточно отключить флэшовый плагин, т.к. фаерфокс сам по себе флэш крутить не умеет. Adblock & noscript тоже хороши, но отнюдь не обязательны для блокировки флэша
Аха , только как были проблемы с "ненажимаемостью" кнопок в режиме параметры разрешить запретить там, так они и остались. Так же проблема со звуковыми устройствами по умолчанию в Linux https://bugbase.adobe.com/index.cfm?event=bug&id=2968177, так и не решена ... а мы тут за многопоточность взялись , принцип типа глядите сколько у нас фич фичастых - а оно на самом деле нех ... не работает. Кирпичу уже пора либо открыть сей блоб либо закопать ...что бы скорее ХТМЛ5 стало стандартом дефакто.
Вот читаю про Flash - закопать, сплошная дырка - вобщем Flash это худшее, что можно только придумать.
Согласен - путь до идеала данного плагина еще весьма долог. Но все смотрят на него как на соперника HTML5 что в корне заблуждение!!! Flash - это многофункциональная система, лишь небольшая часть функционала которой имеется в HTML5. Развивается эта система семимильными шагами. Если не делали приложений на AS3 то никогда не поймете о чем я.
Прежде чем плевать и хаять - попробуйте узнать о Flash побольше (создать что-нибудь).
> Если не делали приложений на AS3 то никогда не поймете о чем я.почему эт не поймём.. я например вполне могу понять (представить :)) это чуство:
"""
эх.. вот я дубина, потратил кучу времени на изучение и оттачивание навыков работы с Flash и AS......а как было хорошо: окружающие меня любили и уважили, тёлочки мне давали при виде flash-чатов которые я делал. я был самым респектовым компьютерщиком на районе!!... ... ...
а теперь Flash закапывают??!!!... нависла угроза "HTML5".. чтоже делать.... НО НЕТ! Я БУДУ СРАЖАТЬСЯ! Я НАЙДУ ДЛЯ СЕБЯ ОПРАВДЕНИЕ о том что Flash ещё рано на свалку истории! этоже такая замечательна технология (пусть хоть и проприетарь, на зато мне так весело было его изучать!)... надо срочно СРОЧНО попытаться всеми силами продлить ему жизнь.. я буду агитировать снова и снова! снова и снова!!! Я СИЛЬНЫЙ!
*далее-проговривавает-в-полголоса* флэш не умер, флэш не умер, флэш не умер, <...>, семимильные шаги, <...>
""":-D
Не худшее а не доработанное, и самое дрянное это политика компании. Пример: разработчик пульсаудио предлагает свою помощь в исправлении багов , естественно отказ и получается собака на сене и сама не ест и другим не даёт.
Согласен, и со скоростью реакции у них слабовато. Я писал баг репорт уже наверное год или больше назад, а воз и ныне там. Но вы поставьте себя на место Adobe. Политика партии у них такая - до последнего не открываться, например. Надо уважать чужой выбор. Сомниваюсь, что там одни люмпены работают. Контора серьезная и на рынке не год-два - значит есть причины.
И вообще - поздержанней реагируйте на все - мы все со своими тараканами.
> Согласен, и со скоростью реакции у них слабовато.У них с этим вообще никак. Я им писал про 2 бага в виндовой версии. Они вообще забили. За год изменений не дождался, а потом перестал мониторить. Для сравнения, мозилловцы растриажили все мои баги и починили их. Около дюжины. Кому я буду писать баги в следующий раз - угадаете? Да, у меня нет цели пробить все стены моим лбом! Я делаю нечто только если ожидаю ответный результат. А на мусорку пусть дураки работают. Адоб зарекомендовал себя именно безответной мусоркой, куда баги улетают навечно.
> Надо уважать чужой выбор.С какой это стати? Политика - плевать на пользователей и делать себе хорошо, делая другим плохо. Давить, давить, давить.
> Согласен - путь до идеала данного плагина еще весьма долог. Но все
> смотрят на него как на соперника HTML5 что в корне заблуждение!!!
> Flash - это многофункциональная система, лишь небольшая часть функционала которой имеется
> в HTML5.С этим трудно спорить. Вот мы сейчас в новом проекте очень долго пытались приспособить websockets, потратили пару недель на решение всех возможных проблем, экспериментировали с самыми разными серверных реализаций websockets и socket.io, но блин, оно настолько нефункционально, экспериментально и плохо поддерживается, что руки опустились и мы сейчас будем переделывать на использование flash sockets. Весь интерфейс и код приложения на html5/js, но общение с сервером через малюсенькую скрытую флешку, открывающую обыкновенный сокет к серверу и предоставляющую js-интерфейс. Никто не горит желанием завязываться на флеш, но тупо нет других технологий, позволяющих работать с сервером без лишнего оверхеда и с низкой латентностью. Ну то есть можно было вместо флеш использовать джава-апплет и java-to-js bridge или silverlight, но "спасибо, мы уж лучше возьмем флеш!".
> Вот мы сейчас в новом проекте очень долго пытались приспособить websockets, потратили пару недель на решение всех возможных проблем, экспериментировали с самыми разными серверных реализаций websockets и socket.io, но блин, оно настолько нефункционально, экспериментально и плохо поддерживается, что руки опустились и мы <...>а ещё есть Server Side Events: https://developer.mozilla.org/en/Server-sent_events
...хотя если подумать -- глюки которые в WebSockets есть сегодня -- если через месяцок другой исправят то будет довольно забавно слышать фразы типа: "ну мыто уже начали делать реализацию через Flash... мыже не знали что глюки будут исправлятся, бы думали что глюки будут вечны" :)
Не исправят. Уже сколько исправляют, блин. В настоящий момент из мейнстриймовых есть ровно один браузер, поддерживающий вебсокеты - google chrome - да и там реализацию постоянно меняют, равно как и меняют спецификацию и реализацию серверной стороны.Да и проблема не только в глюках; на вебсокетах не получается (server-side) сделать нормальный аналог select/poll, например, что мешает реализации приложений по некоторым дизайнам. Т.е. на выбор из серверных дизайнов предлагаются: асинхронные коллбэки на входящее от клиента событие. Требует двух тредов, если мы хотим обрабатывать входящие запросы, совсем не прерывая исходящего потока в неожиданный момент и мерзкие проблемы с синхронизацией и thread-safety. Блокирующий wait+read: опять же два треда, чтобы это как-то работало, и другие неприятности. Эмулируемый аналог select/poll, например как в websockify: при посылке сообщения от клиента оно задерживается на клиенте, а на сервер приходит пустая нотификация о новом сообщении, что через коллбэк устанавливает флаг о наличии сообщения в сокете. Потом можно сделать тот самый wait, заблокирующий до новых данных от клиента, который не зависнет, т.к. на него придет реальное сообщение от клиента. Из недостатков - высокая (иногда очень высокая) латентность.
Я не знаю, почему для вебсокетов нельзя делать настоящий select или неблокирующий ввод/вывод. Почему-то ни практически один фреймворк не дает, а тот, что дает, эмулирует это через хак выше.Еще есть проблемы с реализацией SSL-вебсокетов. Формально вроде можно, фактически - реализовано и поддерживается не везде и работает плохо, например с точки зрения load balancing при использовании haproxy и т.д.
Все это в сочетании с жутким draft-состоянием вебсокетов и будущими изменения стандарта, а так же тем, что везде, кроме chrome нынче вебсокеты работают через websocket-эмуляцию из флеш-сокетов весьма способствовали желанию плюнуть и просто использовать *НОРМАЛЬНЫЕ* tcp-сокеты из флеша, а не этот жуткий хак под названием "вебсокеты". Которые на самом деле всего лишь долгоживущие HTTP/1.1 соединения под другим соусом. Вы и не представляете, какое облегчение вернуться к настоящим сокетам со всеми плюшками после этих "веб".
И да, к счастью, проект для серьезной и достаточно узкой аудитории и позволяет выставить требование "необходим флеш!". Всяко лучше, чем "необходим chrome, меняйте браузер!".
PS server-sent events выглядят интересно, надо посмотреть. Хотя тут, видите, ограничение: из IE не поддерживается. Вебсокеты тоже не поддерживаются, но там легко делается фоллбэк на флеш-сокеты, а тут совсем другой дизайн и это может быть нетривиально :-/
нащёт синхронизации нитей не очень понял %)... какие там могут быть нити (thread) в Node.Js ? (не на Java же вы там пишете такие web-приложения? :))> PS server-sent events выглядят интересно, надо посмотреть. Хотя тут, видите, ограничение: из IE не поддерживается.
MsIE поддерживает всё тоже самое что и поддерживает Chrome Frame... всё что требуется это:
вставить в <head>...</head> нечто вроде этого:
<meta http-equiv="X-UA-Compatible" content="chrome=1" />
<script src="http://bit.ly/vOeAWz"></script>:-) :-)
такчто в списке скверных браузеров остаётся только Opera (я не знаю как там у Opera дела с поддержкой SSE и WebSockets, но традиуионна Opera как технологически всегда плётся позади, нещитая чистого-MsIE)
только я надеюсь, что ни кому в голову не пришла идея о том что"""
если я прошу пользователя-MsIE установить в компьютер Adobe Flash Player -- то это нормально......а если я прошу пользователя-MsIE установить в компьютер ChromeFrame-компонент -- то я большой подонок :-)
"""??? :-)
т.к. тут всю ситуацию можно разделить лишь на два случая:
1. прошу ли я ВООБЩЕ чтолибо (неважно что) польователя доустановить?
2. сайт просто открывается и работает?кстате (для тех кто щитает что прощще отучить пользователя от MsIE, чем все другие способы) скажу следущее -- переучить пользователя использовать Firefox вместо MsIE -- на самом деле намного сложнее чем это кажется. вы можете рассказать пользователю о вирусах и прочей фигни: о скорости открытия страниц, об удобстве.. и пользователь КАКБЫ согласится с вами.. но черз пару дней начнёт опять яросно открывать MsIE :-D. это даже несмотря на то что MsIE и Firefox имеют почти одинаковые GUI :-)...
....связанно это с тем что пользователи которые долгое время пользуются MsIE -- уже на подсознательном уровне свято верят что Голубой-Значок-Эксплорера это символ интернета и всемирной паутины :-D . мало кто из людей любит менять свои привычки
такчто вместо того чтобы придумывать всевозможное flash-костыли (для MsIE) -- стоит задуматься о том что самый нормальный массовый MsIE-костыль остаётся
"Chrome Frame" + "табличка о том что пользователь в нуждается Chrome Frame" :-)
На питоне. От обертки в виде node.js пришлось отказаться по другим причинам. Ну да не суть.
а от Tornado почему пришлось отказаться? %)
Навязывание callback-дизайна, и для реализации шаблона "независимо от входящих сообщений мы шлем поток сообщений в сокет" требуются описанные выше извраты. По два треда на каждый коннэкшн + ручная реализация thread-safety, т.к. торнадо сам не обеспечивает: а то вдруг, пока мы активно шлем поток в вебсокет, к нам из него данные придут и дернут коллбэк?
Это, в прочем, касается Socket.io реализации (TornadoIO), как более предпочтительно для вебщиков варианта. Не помню, смотрел ли я голые вебсокеты на торнадо.eventlet+websockets позволяет работать не через коллбэки, но там опять же нет select/poll! Сэмулировать можно вышеописанным способом с высокой латентностью - но это полумера, а не решение.
> Навязывание callback-дизайна...правда, но не совсем :-)... callback это всеголишь универальный интерфейс (хотя конешно не такой гибкий как Deferred, но зато простой :-))..
но ведь зато callback лёгким движением руки превращается.... в generator-based-линейный-код, путём использования http://www.tornadoweb.org/documentation/gen.html
:-)
кстате говоря -- подобная конструкция (превращаюшая callback-код в generator-based-код) -- ожидается в следующем Javascript -- ECMAScript-6.0
* * * * * *
чтоже касатеся select() и двух-нитей....
....зачем вообще всю эту низкоуровневость вызывать напрямую? tornado.ioloop выполняет роль epoll().. создавать же свой собственный epoll() (в отдельной нити) -- чего ради?
почему нельзя воспользоваться стандартным средством (tornado.ioloop) ? чем оно плохо? %) %)
и разумеется что Ternado не thread-safity... единственная гарантированно-thread-safity функция там это
IOLoop.add_callback(callback)
...оно и понятно почему :-) .. ведь thread-safity отнимает вычислительные ресурсы, в то время как Tornado ращщитан на-то-что хорошо-бы чтобы в программе была-бы только одна-единстенная нить, но с неблокирующими операциями. а иначе сам себе злобный буратино
Да нет, отдельная нить нужна чтобы callback'и принимать в ней, не сбивая потока, отсылающего сообщения в сокет - только если фреймворк требует коллбэки. А если бы работал poll - читаем, когда выясняем, что можно И одновременно хотим читать - нити на фиг не сдались.Через коллбэки было неудобно работать в моем случае: дизайн нужен в духе "после открытия сокета, мы активно работаем и шлем туда кучу данных, и корректность потока данных прежде всего, а иногда мы считываем входящие сообщения из сокета и на их основе немного корректируем исходящий поток". И так получается, что если нас дернут на входящие сообщение "когда попало", а не когда мы захотим его прочесть, то без приема коллбэка в отдельном треде, чтобы не нарушить текущий поток, туго. Ах да, и разумеется, попытка приема сообщения не должна заблокироваться (или дайте мне уже select/poll, наконец!).
Что касается ioloop, все опять упирается в то, что сокеты != вебсокеты. Я бы и на этом торнадо сделал все, что требуется, но код а-ля http://www.tornadoweb.org/documentation/ioloop.html просто не прокатывает для https://github.com/SocketTornadIO/SocketTornad.IO - не выходит сделать setblocking(0) для вебсокета и самому читать :( Для обычных сокетов работает, конечно. Претензии, в общем, не к торнадо, а к вебсокетам.
поглядел я исходники от Торнадовской реализации Websocket http://www.tornadoweb.org/documentation/websocket.html (всмысле включая исходники зависимых базовых классов)...всё сделано элегантно, в неблокирующем виде... (WebSocketHandler базурется на RequestHandler, который в сочетании с Application -- используют обычный tornado.netutil.TCPServer и конешноже tornado.ioloop)
...и даже можно сделать WebSocketHandler.stream.setBlocking(0) ... :-) только незачем это делать так как сёравно всю "грязную" работу исполняет tornado.ioloop [хотя кстате говоря судя по исходным кодам -- допускается избавление от глобального ioloop и видимо использование отдельного ioloop (наверно в отдельной ните)]
но КОРЕНЬ проблемы как я вижу заключается вообще с тем что -- Вами потребовалось -- для реализации алгоритма использовать отдельную нить (и в ней отдельный epoll() для группы соеденений).
в конечном итоге -- нежелание работать в callback-стиле (или в стиле который какимто образом модифицирует callback-стиль в другой более приятный стиль) -- приводит к дополнительным костылям, а они в свою очередь приводят к следующим костылям, .... и в конечном итоге это приводит к тому что:
* либо: очередной костыль не удаётся придумать
* либо: очередной костыль придумывается, но он создаёт чрезмерное потребление ресурсов(ну не приспособлен Python работать в многонитевой среде! даже нет официальной функции которая-бы выбрасывала-бы срочное исключение в чужую нить из своей нити (сигнал в нить, интерпретируемый как исключение)! уже даже только этот факт должен приводить к мыслям о том что Threading нужно обходить стороной :))
а вот исходники от https://github.com/SocketTornadIO/SocketTornad.IO -- ещё поизучать я неуспел.... может быть там реально есть какието технические проблемы... например мне странно слышать что websocket не является обычным сокетом... (а чем тогда он является? ну понятное дело что в начале происходит процесс рукопожатия.. и что "сообщения" посылаются "кадрами" -- но во всём остальном -- этоже обычный socket... даже хотябы судя по реализации websocket от tornado %))
> Весь интерфейс и код приложения на html5/js, но общение с сервером через малюсенькую скрытую флешку, открывающую обыкновенный сокет к серверу и предоставляющую js-интерфейс.
>>>малюсенькую скрытую флешку<<<да хоть какая маленькая-бы она не была-бы -- сёравно это заставляет пользователя устанавливать себе в браузер Adobe Flash Player (тоесть эту чортову проприетарную дыру для rootkit`ов и вирусов.... а теперь не хотители завести разговоры про flashblock и прочии костыли? :-))
В принципе, в данном случае (когда на перепутье), думаю нужно прикинуть целевую аудиторию.
Будет ли для нее скажем 80% вероятность иметь Flash player как само собой разумеющийся факт. И проанализировав ситуацию с websockets на данный момент думаю, как выше упомянули, где-нибудь через годик допилят до нормального состояния, поэтому я бы сразу делал заготовку под будущую возможность (т.е. websockets). Передо мной, в свое время, стоял выбор использовать ли WebStorage. В итоге я отказался от поддержки старых браузеров (но это правда немного другая песня).
> Вот читаю про Flash - закопать, сплошная дырка - вобщем Flash это
> худшее, что можно только придумать.Ну так адоб заслужил плохую репутацию за дело.
1. они долго выдавали спеки на формат лишь под nda и с условием что не будешь с ними конкурировать. Да, когда они поняли что их ща уроет хтмл5, они развинтили гайки, только вот такая "доброта" не считается.2. поэтому альтернативные плагины недоразвиты а отсутствие конкуренции привело к стагнации (сравните темпы развития с браузерами, они по скорости выполнения js давно рвут этот ваш as, даже несмотря на динамическую типизацию!).
3. средства ауторинга флеша всерьез есть только под одну проприетарную систему. А вообще-то все что связано с сервированием намного удобнее и дешевле делать под слегка другими ОС. Разработчику на рабочей машине удобнее всего то же что на боевом сервере - отлаживаться просто и реалистично, не надо держать в бошке особенности нескольких ос, можно без проблем запустить дев-копию проекта на машине разработчика и прочая. В этом у адобы и флеша лютый, абсолютный фэйл. Посмотрите на том же хабре (вебдевовский ресурс) какае операционки в почете у вебдевов.
4. у флешплагина 100500 багов и недоработок, 90% из них живет годами! До них только недавно дошло наконец сделать 64 битную версию флеша. Адоб-овцы, уловите мысль: в моей системе только 64 битный софт! Уже лет 5. И браузер таковым был все 5 лет. Шит от адобы этим похвастать не мог. Что? Они не могли осилить столько лет jit в другой набор команд проца?! А вот браузеры - смогли! И очень давно! Вот вам гады! Конкуренция - рулит! Только так такие как адоб и понимают.
5. флешплагин есть лишь под ограниченное множество платформ. На arm например с флешом вообще все сложно. А вот с опенсорсными браузерами там никаких проблем - и под это они тоже компилятся.
6. адоб слишком долго груши околачивал. За это время хтмл5 набрал силу и смог все что умел флеш, уделал его по скорости скриптов в разы и ... попу адоб теперь рвет героически, но поезд уже ушел.
7. в флеше крайне много дыр. Это основной источник взломов виндузятников в данный момент(впрочем, за пальму первенства в номинации "вот дерьмо!" довольно успешно борется оракл с его жабой). адоб не гугл и не мозилла - за найденные дыры хакерам не платит. поэтому дыры летят на черный рыно а не адобе: идиотов готовых колупать здоровый блоб дизасмом неделями чтобы чисто изд альтруизма сэкономить адобу человеко-часов нынче мало. а адоба потом еще и тупит чуть не месяц с фиксами. лузеры не способные адаптироваться к изменению реалий во всей красе. нам не нужны лузеры и тормоза. и мы не хотим выгребать малваре из всех систем оптом. поэтому виндовые админы вообще часто блочат этот кошмар в групповых политиках: сразу в разы меньше вирья в корп. сети. с такой политикой реагирования на проблемы безопасности - на свалку истории! нам не нужны вирусы!
8. Адоб жадные чудаки на букву м. они постоянно хотят впаривать только свои продукты. окей, удачи, но это имеет свою цену: формат оказывается в невыигрышных условиях. Сколько хороших редакторов для хтмл и жабаскрипта? Да еще и бесплатные половина. А для флеша? Угадайте что больше понравится разработчикам в целом (не лично вам, а новым) ;). А еще адоб почему-то мнит что право поставлять их гребаный плагин это крутая привилегия. Только вот желающих платить за нее все меньше. А зачем? хтмл5 бесплатен и есть целый ряд открытых браузеров под него. приветы адобе.
9. некоторые фирменные проблемы адоб лечить не намерен. почти не работает копипаст текста, нет автозаполнения форм и их истории, нельзя заадресовать конкретную часть флешки ссылкой. а в хтмл5 нет таких дебильных проблем. ну вот например: я могу послать по аське ссылку на именно вот этот комент, тупо скопипастив ее. потому что хтмл. А будь оно на флеше - это было бы невозможно, только ссыль на вьюшку всей простыни как максимум. маздаищще неудобное. Вписывается в веб как квадратное колесо.
10. Первых 9 пунктов вполне достаточно чтобы искренне желать флешу наиболее лютой смерти из всех доступных опций.
Если какой-то лох потратил зря время на освоение проприетарного шита от адобы - его трудности. пусть переучивается, валит в дворники или довольствуется вторыми ролями и привыкает к мысли что пи...ц неизбежен.
> Согласен - путь до идеала данного плагина еще весьма долог. Но все
> смотрят на него как на соперника HTML5 что в корне заблуждение!!!По сути хтмл5 уже может все что было надо от флеша. Мувики - может. Произвольный обсчет и рендер сцен - может. Локальные данные - может. По сути можно например некислые игры создавать.рекламу. красивые эффекты. кастом контролы. свои шрифты. что еще надо то?
> Flash - это многофункциональная система, лишь небольшая часть функционала которой имеется в HTML5.
По факту, фич хтмл5 уже достаточно для почти всех задач. Более того, ряда фич хтмл в флеше просто нет.
> Развивается эта система семимильными шагами.
Угу, особенно 10я версия, застрявшая в развитии как IE6. Я уж со счета сбился сколько лет была одна и та же версия формата (т.е. никаких принципиальных изменений тупо не было).
> Если не делали приложений на AS3 то никогда не поймете о чем я.
Зато мы поймем много чего другого. Например, что сейчас самое время учить хтмл5, а вот перспективы флеша выглядят довольно мутно.
> Прежде чем плевать и хаять - попробуйте узнать о Flash побольше (создать
> что-нибудь).Ну так пусть адоб сделает например хороший бесплатный редатор под линух? А то для хтмл5 таких навалом. Только не говорите что я виндами должен пользоваться, мне они неудобны и не нравятся. Только рак на горе скорей свистнет. Тем хуже для адобы, впрочем.
Сначала думал не парировать, но уж больно вы хотите, чтобы кто-то что-то сказал.
Идеализмом или максимализмом нужно переболеть. Вы никогда не найдете идеала - так устроен мир. На данный момент (исключительно моя оценка) нет причин отказываться от Flash и это не слепая вера в живучесть данной системы.
Конечно - многое из выше сказанного верно, но не все.
Ну и повторюсь - вы вообще не знакомы с данной технологией.
Чел всё же старался. Я пожалуй отвечу.> такая "доброта"
Nothing personal, just business.
> по скорости выполнения js давно рвут этот ваш as
Adobe принимала участие в разработке js машины для firefox.
> Разработчику на рабочей машине удобнее всего то же что на боевом сервере
Вы на сервере иксы держите?
> хабре (вебдевовский ресурс)
Нет, хабре - это клон слешдота для школьников-студентов из Понаехоловска.
Серьёзные разработчики, если это не связано с пиаром компании, там редкость.> какае операционки в почете у вебдевов
Виндовс, конечно. Потому что надо тестировать в IE, как минимум.
Ну и пофапать на хакинтош, не без этого.> 4. у флешплагина 100500 багов и недоработок, 90% из них живет годами!
Официальную статистику в студию.
> хтмл5 набрал силу и смог все что умел флеш, уделал его по скорости скриптов в разы
Грубая ложь. И прошу вас уточняйте, что скоростью js бравирует троянистый google chrome. Вы, разумеется, собираете его себе под ARM ?
> 8. Адоб жадные чудаки на букву м. они постоянно хотят впаривать только свои продукты.
См. п.1
> Сколько хороших редакторов для хтмл и жабаскрипта?
Один - Intellij Idea
> По сути хтмл5 уже может все что было надо от флеша
См. комментарий про сокеты.
> Ну так пусть адоб сделает например хороший бесплатный редатор под линух
Вы так часто повторяетесь о редакторе, что становится очевидно, ваша осносная проблема - относительная дороговизна пакета приложений Adobe.
Однако с выходом на некоторый уровень проблемы такого рода исчезают сами собой. Приличный дизайн одного сайта стоит от тысячи долларов. Приблизительно столько же прототип. Подчеркиваю, "от". В реальности бюждет может быть значительно выше, всё зависит от масштабов, амбиций. Стоимость инструментов Adobe и платформы для их запуска при коммерческой разработке перестает быть значимой.
>> Разработчику на рабочей машине удобнее всего то же что на боевом сервере
> Вы на сервере иксы держите?любая Тыква это Овощ -- но не любой Овощ это Тыква :-)
...т.е. -- автор имел ввиду что если на боевом сервере установлено: Git, Lighttpd, Tornado.. то очень удобно чтобы у каждого разработчика группы на рабочей машине тоже былобы установленно: Git, Lighttpd, Tornado
....объяснять почему? или уже стало самому ясно? :-) :-)
>> какае операционки в почете у вебдевов
> Виндовс, конечно. Потому что надо тестировать в IE, как минимум.
> Ну и пофапать на хакинтош, не без этого.а по вашему -- какое-количество виндусов должно быть у разработчика? ведь потестировать надо и MsIE6 и MsIE7 и MsIE8 и MsIE9 ??? как всё это установить на одну-и-туже венду? :-)
...попахивает VirtualBox... но заем тогда нужна Windows как хост система(?).. правильно -- незачем! :-D :-D
>> Сколько хороших редакторов для хтмл и жабаскрипта?
>Один - Intellij IdeaКстати, поддерживает ActionScript, Flex :)
> Flash - это многофункциональная система, лишь небольшая часть функционала которой имеется
> в HTML5.Ложь.
> Развивается эта система семимильными шагами
Ещё большая ложь. Со времён AS3 там ничего не появилось, да господи - 64битную версию они 10 лет пилили.
> если не делали приложений на AS3 то никогда не поймете о чем я
Делали игры, теперь делаем на HTML5, ни на какой флеш никогда уже не вернёмся.
После третьего ролика на ютубе полностью подвесил FF7 :(
> После третьего ролика на ютубе полностью подвесил FF7 :(plugin-container используется?
да
у одного моего знакомого -- подобная проблема началась в FF7
он к тому же падает через раз
HTML5 разве умеет кушать камеру с микрофоном и слать на сервер?
Ткните в доку и сервер, если умеет.
В теории стандарт такое предполагает. Называется Stream API. Но не один броузер его не поддерживает. Сейчас Google, Mozilla и Opera работают над WebRTC, который должен собрать воедино все необходимые для этого технологии. Хоть код вполне рабочий, но политические причины мешают его внедрению в броузеры.