Native client что это за плагин

Отключаем плагины и ускоряем Google Chrome

Один из простейших способов по ускорению браузера Google Chrome, за счёт отключения ненужных в работе плагинов, которые впустую занимают память и потребляют ресурсы компьютера.

Плагин (англ. plugin, от plug in – подключать) – это отдельный программный модуль (часть программы), который позволяет отображать на web-странице то содержание, которое не может быть отображено при помощи браузера. К таковым относятся: видео, аудио, онлайн игры, презентации и другое. Плагины создаются и распространяются разработчиками этих форматов данных. К примеру, сейчас наиболее популярны такие плагины как Adobe Flash, Quicktime, Silverlight и др.

Но далеко не все плагины нужны в повседневной работе. Большинство из них можно спокойно отключить. Отключив ненужные вам плагины, вы сможете ускорить работу браузера. В данной статье я расскажу вам как это сделать и что можно отключить, чтобы ускорить Google Chrome.

И так, для того чтобы зайти на страницу «Плагины» в браузере Google Сhrome следует указать в его адресной строке: chrome://plugins/ – и нажать кнопку Enter. Открывшаяся страница будет иметь следующий вид.

Давайте разбираться, какие плагины мы можем отключить, а какие оставить.

  • Widevine Content Decryption Module – плагин поддержки EME API, позволяющий правообладателю запретить копирование аудио/видео контента через HTML5. Подробней читайте тут.
    Моё мнение : зачем себя ограничивать, отключаем.
  • Native Client – плагин поддержки графики или звука высокого качества в приложениях. Подробней читайте тут.
    Моё мнение : если не используете приложения можно отключать.
  • Adobe Flash Player – плагин поддержки Flash.
    Моё мнение : пока нужен, оставляем.
  • Google Earth (GEPlugin) – плагин интеграции с приложением Google Earth, для просмотра карт в 3D.
    Моё мнение : по сути, мне хватает и софта, отключаю.
  • Chrome Remote Desktop Viewer — как я понял, это плагин для одноименного приложения, которое позволяет подключаться к удаленным компьютерам и предоставлять другим пользователям безопасный доступ к вашему компьютеру.
    Моё мнение : штука интересная, но мне как бы не нужная, отключаю.
  • Java(TM) – плагин поддержки Java (не путать с JavaScript) .
    Моё мнение : по сути, редко что-то такое использую, так что отключил.
  • Chrome PDF Viewer – плагин просмотра PDF документов прямо в браузере.
    Моё мнение : не часто нужно, а если нужно, то есть Acrobat Reader, отключаю.
  • Google Update – плагин для обновления ПО Google.
    Моё мнение : по опыту знаю, что отключение этой назойливой штуки чревата проблемами, так что пусть будет, оставляем.
  • Adobe Reader – плагин для просмотра PDF файлов в браузере.
    Моё мнение: стрёмно обновлять, следают адобовские «костыли», отключен.
  • VLC Web Plugin – плагин VLC проигрывателя для прослушивания/просмотра аудио/виде файлов в браузере.
    Моё мнение : интегрировался гад, обычно мне не нужен, отключаю.
  • Windows Presentation Foundation – как я понял, это плагин подсистемы из .NET Framework (начиная с версии 3.0) . Подробней читайте тут.
    Моё мнение: написано, что плагин для Firefox, да и вообще, вроде не нужно, отключаю.

Если у Вас в списке есть ещё какие-то плагины – пишите в комментариях, будем разбираться, а заодно поможем другим.

Как видите, тут нет ничего сложного — при загрузке страницы сначала с помощью JavaScript производится проверка наличия модуля, и в случае успеха он загружается в контейнер с id embed1. В случае неудачи выводится сбивающее с толку сообщение — «The Native Client plugin was unable to load». Почему сбивающее с толку? Сейчас я это покажу. Земля в иллюминаторе Возвращаемся в директорию /googleclient/native_client/tests в папку earth/ (см. рис. 4). Рисунок 4. Файлы примера Как нетрудно догадаться, сценарий run.py запускает приложение, но нам это совсем не нужно. Вместо этого откроем в браузере html-страницу earth.html. и… получим то самое сообщение (см. рис. 5). Как же так? Ведь плагин мы установили? Рисунок 5. Модуль не загружен Дело в том, что, несмотря на наличие Native Сlient-плагина, модуль не грузится по той простой причине, что он не собран, не откомпилирован, а представлен только исходным кодом (файл earth.сс), на языке С++. Впрочем, в той же папке мы видим файл Makefile, и это позволяет надеяться, что ситуацию можно исправить. Сначала соберём и запустим Standalone-приложение: make debug run После этого запустится самостоятельное приложение, представляющее собой вращающееся изображение земного шара, а в папки примера появится исполняемый файл — earth_debug. Теперь соберём Native client-модуль: make release nacl Если все прошло нормально, появятся ещё два файла — earth.nexe и earth_release.nexe. Можно опять открыть earth.html в браузере, и теперь картинка должна быть совсем другой (см. рис. 6). Рисунок 6. Земля. Рассмотрим пример посложнее. В папке googleclient/native_client/tests/xaos находятся исходники и сценарий сборки известного фрактального конструктора Xaos. Правда, не исходники самого Xaos, их сборочный скрипт скачает отдельно. Собирать просто: ./xaos_tool.sh all И, раскрыв браузером xaos.html, наслаждаемся результатом (см. рис. 7). Рисунок 7. Редактируем фракталы На самом деле в этом и предыдущем примере мы выступаем в роли разработчика. Конечному пользователю приложения достаются уже откомпилированные модули, и всё, что ему нужно, — оснастить браузер Native client плагином. Ну а мы продолжим развлекаться. Теперь приступим к обещанной quake. Тут готового сценария нет, поэтому будем действовать вручную. Заходим в папку googleclient/native_client/tests/quake/ и скачиваем исходные коды игры: wget http://www.libsdl.org/projects/quake/src/sdlquake-1.0.9.tar.gz … wget http://www.libsdl.org/projects/quake/data/quakesw-1.0.6.tar.gz … Теперь их разархивируем: tar -x —strip-components=1 -f sdlquake-1.0.9.tar.gz … tar -x -f quakesw-1.0.6.tar.gz … Должно образоваться множество файлов — исходников и одна директория — id1/. Следующим шагом наложим необходимый патч из native Client: patch -p1 Рисунок 8. Наши победят! И пока всё… Да, на этом, к сожалению, пока всё. К сожалению, технология пока действительно сырая, и автору не удалось последовательно написать с нуля и запустить Google Native Client-приложение ни на одной платформе. Более того, на данный момент времени NaCL отказывается собираться с Python 2.6.x, браузер с установленным NaCL-плагином неоднократно замечен в неадекватном поведении, некоторые тесты не запускаются под платформой Windows. С другой стороны, API NaCL открыт и документирован (/googleclient/native_client/scons-out/doc/html), поэтому для настоящего энтузиаста нет препятствий попробовать свои силы в написании приложений «невзирая на». Трудно сейчас сказать, насколько перспективным окажется это занятие, но интересным — наверняка. 1. Домашняя страница проекта — http://code.google.com/p/nativeclient. 2. Описания архитектуры GoogleNative Client (PDF) — http://nativeclient.googlecode.com/svn/trunk/nacl/googleclient/native_client/documentation/nacl_paper.pdf

Пользователи текущей стабильной версии Google Chrome могут заметить, что в списке установленных плагинов (на chrome:plugins) появился новый — Widevine Content Decryption Module. В Google Chrome OS он появился еще в 26 версии, а до браузера дошел только сейчас. Что это за зверь?

Плагин Widevine Content Decryption Module (Widevine CDM) добавлен в браузер для поддержки Encrypted Media Extensions (EME) API, который в свою очередь появился в спецификации HTML5 для работы с DRM (технические средства защиты авторских прав).

А теперь простыми словами.

Welcome to Native Client

Владельцы аудио- и видео-контента хотят транслировать его в сети средствами HTML5, но не хотят давать право его копировать. Для этого организация W3C добавила EME в спецификацию HTML5. А на стороне браузера поддержкой этого дела должен заниматься специальный плагин (в случае с Google Chrome, это Widevine CDM).

François Beaufort (ç — это французская буква, а не битый пиксель у вас на мониторе), евангелист проекта Chromium и сотрудник Google, объяснил поддержку EME следующим образом. Крупные компании, продвигающие идею защиты онлайн-контента от копирования, не отстанут (для поддержки DRM уже сейчас используют плагины Flash и Silverlight). А EME это хороший способ внедрить единый стандарт, который не потребует от пользователя самостоятельно устанавливать различные плагины.

Другого мнения придерживается Brendan Eich, создатель языка Javascript и технический директор Mozilla.

По его словам, решение поддержать EME подрывает открытость Web и ущемляет права пользователей. А еще он считает, что EME открывает дорогу для появления бесконечного числа нестандартизированных CDM-плагинов, которые по сути являются аналогами ActiveX и создаются под конкретные ОС.

Кстати, Widevine CDM не является частью проекта Chromium, а представляет из себя такой же закрытый плагин Google, как и Flash (PPAPI) и PDF Viewer. Т.е. встраивается исключительно в Chrome. В мобильную версию Google Chrome плагин встроить планируют в 32 версии.

Читать еще:  Пропали контакты на андроиде что делать

Строго говоря, Google не позиционировало свою технологию Native Client как платформу для Rich Internet Applications, но по формальным признакам она вполне вписывается в этот класс ПО.

Ее суть — запуск в браузере модулей, написанных на нативном коде (увы, адекватного перевода на родной язык термина «native code» в голову не приходит) для архитектуры x86.

В отличие от JavaFX или Silverlight, в этой технологии нет компиляции в байт-код и какой-либо виртуальной машины. Была создана среда выполнения, позволяющая запускать обычные, «родные» для этой платформы программы в безопасном для данной системы окружении.

Отключаем плагины и ускоряем Google Chrome

Разработчики идеально выдержали модель «песочницы».

Во избежание взаимодействия Native Client непосредственно операционной системой весь код исполняется в отдельном, изолированном контейнере. Это позволяет модулю использовать системные ресурсы, но в то же время ограждает ОС от возможного случайного или злонамеренного повреждения.

В целом Native Client (NaCL) состоит из контейнера, играющего роль песочницы, и среды исполнения (runtime) нативного кода. Третьим элементом выступает плагин для веб-браузера. Для коммуникации между браузером и NaCL-модулем предоставлены два варианта: simple RPC-интерфейс (SRPC) и давно известный Netscape Plugin Application Programming Interface (NPAPI).

Писать модули для Google Native Client предполагается на любом компилируемом на данной системе языке программирования.

Native Client распространяется под лицензией BSD, имеет реализации для различных браузеров и платформ.

Еще несколько лет назад Native Client многими рассматривался как веб-платформа будущего. Сейчас новости об этой технологии занимают довольно скромное место на фоне известий о новых API HTML5, но Google от него отказываться явно не собирается. Так, начиная с 14-й версии браузера Google Chrome, Natve Client включен в состав обозревателя, и его пользователям больше не требуется устанавливать никаких дополнительных плагинов.

Вам также могут быть интересны следующие статьи:

Разработчики из проекта Chromium сообщают, что уже в 31 версии их браузера поддерживается Portable Native Client (PNaCl, произносится «pinnacle»). Что это за зверь такой, и в чем его отличия от простого NaCl вы можете прочитать дальше…

Для начала напомним, что такое обычный NaCl.

От браузера к ОС: что такое Native Client и чем он может быть полезен?

Это технология, которая позволяет браузеру исполнять нативный код, а разработчикам — писать свои веб-приложения, например, на C или C++. Применение NaCl позволяет добиться высокой производительности и низкоуровневого контроля за работой приложения. С применением NaCl созданы такие игры как Mini Ninjas и Bastion.

Можете, кстати, обратить внимание, что плагин NaCl встроен в браузер и отображается на странице chrome:plugins.

К сожалению, NaCl не дает возможность подготовить приложение, которое будет работать на любой платформе. В результате разработчики должны компилировать исполняемые nexe-модули под каждую архитектуру. Собрать по модулю на каждую платформу еще можно, но как их распространять? Особенно это актуально, если веб-приложения встроены в сайт, а не устанавливаются из того же Chrome Web Store.

PNaCl решает эту проблему и позволяет создавать действительно портативные и независимые от архитектур приложения. Как это происходит? Процесс компиляции разбивается на два этапа:

  • компиляция исходного кода в байткод, который не зависит от архитектуры;
  • перевод байткода в нативный код под каждую архитектуру.

В результате первого этапа разработчик получает специальный pexe-модуль, который можно использовать в приложениях также, как и любые другие HTML, JS и CSS вставки. Этот же компонент можно распространять через сайт.

А вот второй этап уже происходит в браузере. Chrome сам преобразовывает байткод в нативный код, который будет актуален для конкретной платформы и ОС.

В результате разработчик создает одно приложение, которое будет работать на x86, ARM и MIPS. А чтобы приложения, созданные на PNaCl, работали и в других браузерах, а не только в Chrome, можно использовать pepper.js.

Если вы разработчик, то добро пожаловать в документацию.

А если вы просто любопытный пользователь, то вот вам PNaCl-демки.

От браузера к ОС: что такое Native Client и чем он может быть полезен?

Отметив в начале августа 20-летний юбилей, браузеры почти сразу перешагнули и ещё одну важную ступеньку: на прошлой неделе в бета-версии Google Chrome 14 был включён экспериментальный компонент Native Client (NaCl). Мне повезло рассказывать об этом уникальном проекте с самых первых его дней (см. Компьютерра #763) — и тем приятней констатировать сейчас, что цель, которую ставили перед собой авторы, в общем достигнута.

Чего не хватает веб-браузерам, не считая утопической стопроцентной совместимости? Увы, скоростей. Даже с учётом всех мыслимых инноваций и модификаций последних лет — революционных Javascript-движков, использования GPU, предварительного рендеринга страниц, новых протоколов (слышали про SPDY?) и прочего подобного — скорость исполнения веб-приложений на порядки медленней той, что обеспечивает любая нативная программа, выполняемая непосредственно микропроцессором. Вот здесь-то и вступает в игру NaCl.

Проект, ведомый уже три года по инициативе и под крылом Google, позволяет веб-программистам писать такие приложения, которые будут исполняться внутри браузера со скоростью, лишь слегка уступающей скорости программ в машинных кодах, но сохранят переносимость, присущую веб-приложениям.

Фокус объясняется просто: Native Client — это «песочница», внутри которой работают программы, написанные на C/C++ и других классических языках, компилируемых непосредственно в машинный код. Но замкнутые в своём участке памяти, NaCl-приложения общаются с внешним миром только через программный интерфейс, связывающий их с Javascript-движком браузера. Поэтому не имеет значения, в какой операционной системе идёт работа, важно лишь для какого процессора они скомпилированы (сейчас NaCl-программы могут быть в инструкциях x86 и ARM).

Native Client часто сравнивают с ActiveX, ставшей настоящим кошмаром IT. Но тот, кто знаком с новым проектом не понаслышке, утверждают, что правильной аналогией будет не ActiveX или Java, а скорее VMware в браузере: для NaCl нет нужды писать новые приложения — можно адаптировать уже существующие!

Поскольку речь идёт об исполнении непроверенного машинного кода, полученного извне, вопрос обеспечения безопасности выходит на первый план. Можно ли гарантировать, что NaCl-программа не навредит системе, где она исполняется (почистив жёсткий диск, украв ценную информацию и пр.)? Авторы уверены, что это возможно.

Native Client формирует три степени защиты. Во-первых, перед исполнением код подвергается анализу на предмет выявления потенциально опасных последовательностей. Во-вторых, программа изолирована от других приложений аппаратно, средствами микропроцессора. В-третьих, связь с окружающим пространством организована с помощью Javascript, а значит и воспользоваться NaCl сможет только теми ресурсами, которые доступны Javascript-программам. Наконец, исходные тексты опубликованы под свободной лицензией, что само по себе добавляет уверенности.

Native Client ценен не только собственными уникальными свойствами, но и наличием открытого, оформившегося API (Pepper), посредством которого он увязывается с элементами HTML5. Возможность гибко, стандартным образом вписать NaCl-программы в существующую веб-архитектуру, предположительно, даст толчок лавинообразному росту числа таких приложений. А простота переноса существующих наработок в среду Native Client (особенно легко портируются линуксовые программы, а системные библиотеки даже не требуют изменений в коде) позволит не изобретать велосипед.

Важность текущего момента в том, что эксперименты завершены и начата практическая стадия. Native Client незримо присутствует в Chrome уже на протяжении нескольких версий — в виде тестовой опции, активировать которую необходимо вручную. Начиная с версии 14, стабильный релиз которой ожидается в сентябре, NaCl-среда будет активирована по умолчанию, что сразу же расширит список её пользователей с узкого круга разработчиков до минимум нескольких миллионов рядовых сетян (Chrome сейчас третий по популярности браузер в мире).

Помимо прочего, Native Client стал ещё и бесспорно уникальной функцией браузера Chrome. В условиях жесточайшей конкуренции, когда наткнуться на оригинальную идею — счастье, этот факт трудно переоценить

Какими будут NaCl-программы? Теоретически, на их плечи лучше всего взвалить обязанности, для которых требуется обработка больших объёмов данных в кратчайшее время. Вот почему ожидается, что основными областями применения будут мультимедийные функции браузеров и игры (к примеру, Google реализовала так встроенный в Chrome PDF-вьюер).

Однако по факту самым востребованным свойством Native Client стала его независимость от операционных систем. NaCl-программа без модификаций и настройки работает в MS Windows, Mac OS X, Linux и Chrome OS. Правда, список приложений пока невелик (см. официальный сайт), но уже есть интересные сторонние разработки (например, NaClBox, позволяющий запускать DOS-игры в браузере).

Читать еще:  Жесткий диск требует форматирование что делать

Ближайшее будущее Native Client связывается с двумя тенденциями. Первую должны сформировать разработчики прикладного софта, которые с помощью NaCl могут сравнительно легко переносить имеющиеся наработки в Сеть и таким образом наделять их кроссплатформенностью. Подать пример собирается лично Google, где надеются со временем превратить сам браузер Chrome в приложение NaCl (а значит и уменьшить хлопоты по адаптации к разным ОС, и усилить защиту, поскольку браузер будет работать в закрытой «песочнице»).

Другую тенденцию сформируют пользователи, требуя поддержки NaCl-приложений в браузерах, конкурирующих с Chrome. Поскольку исходники открыты, ничто кроме идеологических соображений не должно помешать проникновению Native Client в Firefox, Safari, Opera и Internet Explorer. Ожидается, что это произойдёт с участием создателей браузеров или без них (при помощи плагинов).

Наконец, в отдалённой перспективе Native Client может сыграть важную роль в становлении облачной Chrome OS — где отныне возможен запуск приложений, едва ли хоть в чём-то уступающих программам для классических операционных систем. И здесь скрыт самый жирный плюс этой оригинальной разработки. Да, сторонники Native Client, безусловно, большие оптимисты. И верить им или нет, решать вам. Но в любом случае новинку стоит оценить лично. Ведь если ожидания оправдаются, резко и необратимо изменятся не только браузеры, но и весь мир вычислительной техники: браузеры станут полным эквивалентом операционных систем и фундаментом для обновлённой софтверной индустрии

Google Native Client

Содержание статьи

Наша жизнь все больше перемещается в Сеть. Браузер стал главной программой на ПК, а Гугл вовсю штампует ноутбуки с Chrome вместо полноценной ОС. Казалось бы, в этих условиях перспективы обычных, не веб-ориентированных языков программирования крайне сомнительны. И тем не менее нас, старых добрых хардкорных программистов на си приплюснутом, еще рано списывать на свалку истории — мы все еще получаем кучу денег :), потому что без нормального машинного кода до сих пор никто не обходится.

Потребность в запуске нативного кода в браузере появилась не на пустом месте. Как бы ни старались разработчики JavaScript и HTML 5 движков, производительность их творений не выдерживает конкуренции с обычным кодом на C или C++. Если нам нужно показать крутую графику или поразить окружающих высококачественным звуком, то типичными инструментами веб-разработчика подобное реализовать затруднительно. Именно это и стало одной из основных причин для появления технологии Native Client от Google.

Что такое Native Client

Ребята из Гугла начали свой нелегкий труд над NaCl в далеком 2008 году. Задачи, которые они ставили перед собой, были сложны и амбициозны. Первым делом надо было обеспечить легкую переносимость legacy кода в NaCl. Это была фактически первопричина всей этой затеи. Если у нас есть куча старого и не очень кода на плюсах, который работал сугубо на десктопах, и мы вдруг решили, что пора осваивать веб, то нам не надо учить новые языки программирования и технологии, а достаточно лишь портировать имеющийся код на Native Client платформу.

Но даже если мы и готовы переписать все с нуля на незнакомых нам языках, не факт, что у нас выйдет то, что мы ожидали. Показывать качественную 2D- и 3D-графику, использовать многопоточность, да и вообще быть ближе к железу у нас ну никак не выйдет. Это была вторая цель, которую преследовала Google. Кроме того, как я уже сказал, никто не отменял относительно низкую производительность скриптовых языков в браузере.

Ко всему прочему, умные парни из Google подумали и о безопасности пользователей. Весь нативный код выполняется в двойной (!) песочнице, что позволяет блондинкам и прочим продвинутым личностям не бояться забагованных приложений и атак злых вирусов.

Ну и на десерт у нас платформонезависимость. Да-да! Мы можем написать плюсовый код, и он будет работать на Windows, OS X и даже, не побоюсь этого слова, Linux. А вишенкой на этом десерте будет поддержка x86- и ARM-архитектур.

В 2011-м Гуглец включил поддержку NaCl в Chrome. Другие браузеры, к сожалению, пока не поддержали инициативу интернет-гиганта. Старожилам интернета в голову невольно могут прийти воспоминания об ActiveX, который и ныне здравствует (в кругу любителей IE), но, в отличие от технологии Майкрософт, Native Client распространяется с открытым исходным кодом под новой лицензией BSD. Да и над безопасностью в NaCl подумали лучше.

Для чего можно использовать Native Client

На практике Native Client можно использовать в первую очередь для запуска игрушек в браузере. Собственно, первый опыт уже есть — под Google NaCl портировали Quake. Да, да, ту самую кваку 1996 года выпуска, в которой ты провел столько лет, разрубая жирных огров саперной лопаткой (если ты не знаешь, как зарубить лопатой вооруженного гранатометом и бензопилой огра, напиши мне) и разрывая в клочья зомби из рокетлаунчера.

Исполнение машинного кода в браузере отлично поможет разгрузить сервер. Например, если у нас есть онлайн-сервис для конвертации видео в разные форматы, то алгоритм работы с ним должен выглядеть примерно так: пользователь загружает видео на сервер, долго ждет, пока наш мощный CPU перелопатит файл, выбрасывая в атмосферу много калорий тепла, а потом счастливый юзер скачивает результат с нашего сервера. Но если мы перенесем конвертор с сервера на клиент, то мы сразу уберем нагрузку с нашего железа и нехило расчистим интернет-канал, который за «умеренную» плату предоставил нам хостер. Да и пользователь будет доволен — в среднем конвертация должна пройти быстрее, так как сотни мегабайт туда-обратно по сети не гоняются. А для юзеров с паранойей можно с гордостью заявить, что их драгоценные personal data целиком обрабатываются только на их ПК. Это, кстати, актуально и для корпоративного сектора.

Как это работает

Native Client — это общее название для набора разнообразных программных компонентов, которые работают вместе для обеспечения безопасного функционирования C++ кода в вебе. На высоком уровне NaCl состоит из тулчейна (компилятора, линкера и так далее) и рантайм-библиотек, которые встроены в браузер и позволяют нативному коду безопасно работать с нужными API.

Для переносимости приложений между разными архитектурами существует расширение Portable Native Client (PNaCl). Отличие его заключается в том, что при компиляции код транслируется в промежуточное представление, а уже после запуска на той или иной платформе браузер переводит это представление в машинный код.

Для обеспечения безопасности Гугл сделал две вещи. Первая — это специальный набор API, с которым может работать код, выполняющийся под NaCl. Нативный модуль не должен пытаться выйти за пределы разрешенного API, вмешиваться в работу стороннего кода или браузера.

Второй важный момент, обеспечивающий беззаботную жизнь для пользователей Native Client, — это специальный анализатор кода, который должен удостовериться, что приложение не пытается сделать ничего противоправного.

Кроме того, NaCl-модули всегда запускаются в процессах с ограниченными правами. Эти меры предосторожности позволяют говорить о двойной песочнице для нативного кода, работающего в браузере.

C++ код может общаться с JavaScript посредством специальных сообщений. Сообщения пересылаются асинхронно, то есть не надо ждать, пока другая сторона получит его.

Пишем Hello NaCl

Теперь у нас есть представление о Native Client, и нужно пробовать написать что-нибудь полезное. или не очень. Мы будем делать Hello World, ну или Hello NaCl.

Для начала нужно скачать и установить Native Client SDK. Ссылку на страницу загрузки ты найдешь во врезке. Там же будет и инструкция по установке. Скажу лишь, что обязательно будет нужен Python 2.7 и make.

Вместе с SDK идет простой веб-сервер, который может хостить приложения на localhost. Самый простой путь запустить его — это выполнить следующие команды:
$ cd pepper_$(VERSION)/getting_started
$ make serve
SDK может содержать в себе несколько разных версий, правильную нужно подставить вместо $(VERSION). Также можно использовать любой другой веб-сервер. PNaCl включен по умолчанию в версии хрома 31 и старше. Но нужно следить, чтобы выбранная версия SDK поддерживалась установленной версией Chrome.

Читать еще:  Lavasoft web companion что это

Великий и могучий Гугл любит преданных разработчиков и потому любезно предоставил пример с минимальным кодом для создания NaCl-модуля. Лежит этот код в папке pepper_$(VERSION)/getting_started/part1 и состоит из нескольких файлов. Первый — это index.html. В нем находится HTMLLayout и JS-код для взаимодействия с плюсовым модулем. Если внимательно присмотреться, то можно заметить файл с расширением nmf, а точнее, hello_tutorial.nmf. Это манифест, который указывает на нашу HTML, NaCl-модуль и служит вместилищем дополнительных настроек для тонкого тюнинга.

Далее идет hello_tutorial.cc, он и является исходником на C++, который потом можно собрать с помощью Makefile. Сделать это до безобразия просто:
$ cd pepper_$(VERSION)/getting_started/part1
$ make
Если мы использовали веб-сервер, идущий вместе с SDK, то после сборки в хроме достаточно вбить такой URL: http://localhost:5103/part1, и ты станешь свидетелем чуда — текст на открывшейся странице изменится с LOADING. на SUCCESS. Впечатляет, не правда ли?

Так как мы собирались делать Hello NaCl, то нам придется немного изменить код. Для этого заглянем в файл index.html и найдем там JavaScript-функцию moduleDidLoad. Кстати, сейчас самое время пробежаться по всему коду HTML-файла и остановиться на непонятных вещах, благо все они щедро сдобрены комментариями. В функции moduleDidLoad происходит загрузка нашего NaCl-модуля hello_tutorial и вывод того самого текста SUCCESS, который мы успели лицезреть при переходе по линку /part1. Теперь пошлем нативному модулю слово hello, для этого достаточно вызвать функцию postMessage у переменной модуля. В коде это будет выглядеть примерно так:
function moduleDidLoad() <
HelloTutorialModule = document.getElementById(‘hello_tutorial’);
updateStatus(‘SUCCESS’);
// Посылаем сообщение Native Client модулю
HelloTutorialModule.postMessage(‘hello’);
>
Сообщение послали, теперь надо его получить. Для этого надо реализовать член-функцию HandleMessage в файле hello_tutorial.cc. В файле содержится TODO, которое недвусмысленно намекает на то, что нужно делать. В обработчике сообщения мы будем отправлять браузеру ответ с помощью функции PostMessage, но перед этим выполним пару проверок.
virtual void HandleMessage(const pp::Var& var_message) <
if (!var_message.is_string())
return;
std::string message = var_message.AsString();
pp::Var var_reply;
if (message == «hello») <
var_reply = pp::Var(«hello from NaCl»);
PostMessage(var_reply);
>
>
Как видно из кода, мы первым делом проверяем, пришла ли нам строка, а не что-то другое. Класс Var служит оберткой со счетчиком ссылок для сырых переменных C++. Именно объекты этого класса пересылаются между веб-страницей и нативным модулем. Далее мы проверяем, что нам пришло именно hello, и отправляем ответ, предварительно обернув его объектом класса Var.

В index.html уже есть обработчик сообщений от NaCl-модуля. Он просто выведет JS alert с полученной строкой:
function handleMessage(message_event) <
alert(message_event.data);
>
После того как мы сделали нужные изменения, можно пересобирать модуль и обновлять страницу http://localhost:5103/part1. Увидев message box с заветной строкой hello from NaCl, мы можем с гордостью заявить, что освоили новую технологию.

Заключение

Гугл придумал полезную штуку. Жаль, что пока никто, кроме «корпорации добра», не поддержал Native Client платформу. Достаточно высокая производительность является преимуществом по сравнению с Java, апплеты которой также могут выполняться в браузере, а высокий уровень безопасности уделывает ActiveX от Microsoft. Будем ждать, пока Chrome захватит мир или другие разработчики браузеров внедрят в свои творения Native Client.

LiveInternetLiveInternet

Рубрики

  • ОТКРЫТКИ разные (50)
  • АВАТАРКИ (36)
  • АКВАРЕЛЬ цветочная (70)
  • АКВАРЕЛЬ разная (109)
  • Америка (39)
  • Английский язык (18)
  • Анимация с кодами. (29)
  • анимация картинки (14)
  • АНТИКВАРНОЕ (71)
  • АРТ ДЕКО (41)
  • Аукционное (32)
  • валентинки (9)
  • видео (42)
  • ВИНТАЖ (116)
  • ВРЕМЕНА ГОДА (40)
  • ГОРОД (52)
  • ГРАВЮРЫ ЛИТОГРАФИЯ (20)
  • ДЕКОРАТИВНОЕ ПРИКЛАДНОЕ (59)
  • ДЕТАЛИ старинных картин (10)
  • ДЕТСКАЯ СТРАНИЧКА (202)
  • ДЛЯ ДОМА советы, интерьер,оформление . (117)
  • Для творчества (1)
  • ЖЕНСКИЙ ОБРАЗ (310)
  • ЖИВОПИСЬ галантный век (155)
  • ЖИВОПИСЬ городская (58)
  • ЖИВОПИСЬ деревенская (59)
  • ЖИВОПИСЬ портреты (101)
  • ЖИВОПИСЬ прошлого (208)
  • ЖИВОПИСЬ современная (263)
  • ЖИВОПИСЬ цифровая (8)
  • животные дикие (37)
  • животные домашние (75)
  • ЗНАМЕНИТОСТИ (132)
  • ИЛЛЮСТРАЦИИ разные (84)
  • ИЛЛЮСТРАЦИИ цветочные (10)
  • ИНТЕРЕСНО. (55)
  • ИСТОРИЯ прошлого (94)
  • История современная (21)
  • КИНО радио (28)
  • классика (5)
  • КЛИПАРТЫ (47)
  • космос (9)
  • КРАСОТА (32)
  • КУКЛЫ (35)
  • КУЛИНАРИЯ вторые блюда (125)
  • КУЛИНАРИЯ первые блюда (20)
  • КУЛИНАРИЯ разная (51)
  • КУЛИНАРИЯ салаты закуски (51)
  • КУЛИНАРИЯ выпечка (173)
  • МЕДИЦИНА релакс (123)
  • МОДА косметика человек (41)
  • МОНАРХИ их семьи (153)
  • Мудрость (31)
  • Музеи Англии (12)
  • МУЗЕИ мира (40)
  • Музеи России (52)
  • Музеи Франции (40)
  • МУЗЫКА диско, романтика, джаз, для души. (80)
  • НАТЮРМОРТЫ фото (33)
  • НАТЮРМОРТЫ. в живописи (156)
  • новогодние рамочки. (6)
  • НОВЫЙ ГОД (163)
  • ОБОИ видеорамочки (28)
  • оформление дневника (1)
  • ПАСХА (47)
  • ПИН АП (61)
  • ПОЖЕЛАНИЯ комментарии (66)
  • ПРИРОДА в живописи (126)
  • ПРИРОДА фото (63)
  • программы, комьютер. (27)
  • РАЗДЕЛИТЕЛИ кнопки (14)
  • рамочки без картинок (27)
  • рамочки с картинкой. (10)
  • РЕЛИГИЯ (151)
  • РЕТРО (120)
  • Рождество. (46)
  • САДЫ ПАРКИ (44)
  • сайты разные (27)
  • СПАСИБО + комментарии (13)
  • СТИХИ (46)
  • СТРАНЫ (58)
  • СХЕМЫ ДЛЯ ДНЕВНИКОВ (184)
  • ТЕКСТ (11)
  • уроки чайникам (37)
  • УЮТНЫЕ УГОЛКИ (122)
  • ФАРФОР (38)
  • флешки часики (23)
  • Фоны (20)
  • ФОТО (40)
  • ХРАМЫ соборы мечети (66)
  • ЦВЕТЫ в живописи (204)
  • ЦВЕТЫ фото (42)
  • ЧАЕПИТИЕ (39)
  • ЭПИГРАФЫ (7)
  • ЮМОР живопись стихи (107)
  • юридические консультации (5)

Музыка

Поиск по дневнику

Подписка по e-mail

Статистика

Отключаем плагины и ускоряем Google Chrome

Отключаем плагины и ускоряем Google Chrome

Один из простейших способов по ускорению браузера Google Chrome, за счёт отключения ненужных в работе плагинов, которые впустую занимают память и потребляют ресурсы компьютера.

Плагин (англ. plugin, от plug in – подключать) – это отдельный программный модуль (часть программы), который позволяет отображать на web-странице то содержание, которое не может быть отображено при помощи браузера. К таковым относятся: видео, аудио, онлайн игры, презентации и другое. Плагины создаются и распространяются разработчиками этих форматов данных. К примеру, сейчас наиболее популярны такие плагины как Adobe Flash, Quicktime, Silverlight и др.

Но далеко не все плагины нужны в повседневной работе. Большинство из них можно спокойно отключить. Отключив ненужные вам плагины, вы сможете ускорить работу браузера. В данной статье я расскажу вам как это сделать и что можно отключить, чтобы ускорить Google Chrome.

И так, для того чтобы зайти на страницу «Плагины» в браузере Google Сhrome следует указать в его адресной строке: chrome://plugins/ – и нажать кнопку Enter. Открывшаяся страница будет иметь следующий вид.

Давайте разбираться, какие плагины мы можем отключить, а какие оставить.

  • Widevine Content Decryption Module – плагин поддержки EME API, позволяющий правообладателю запретить копирование аудио/видео контента через HTML5. Подробней читайте тут.
    Моё мнение : зачем себя ограничивать, отключаем.
  • Native Client – плагин поддержки графики или звука высокого качества в приложениях. Подробней читайте тут.
    Моё мнение : если не используете приложения можно отключать.
  • Adobe Flash Player – плагин поддержки Flash.
    Моё мнение : пока нужен, оставляем.
  • Google Earth (GEPlugin) – плагин интеграции с приложением Google Earth, для просмотра карт в 3D.
    Моё мнение : по сути, мне хватает и софта, отключаю.
  • Chrome Remote Desktop Viewer — как я понял, это плагин для одноименного приложения, которое позволяет подключаться к удаленным компьютерам и предоставлять другим пользователям безопасный доступ к вашему компьютеру.
    Моё мнение : штука интересная, но мне как бы не нужная, отключаю.
  • Java(TM) – плагин поддержки Java (не путать с JavaScript) .
    Моё мнение : по сути, редко что-то такое использую, так что отключил.
  • Chrome PDF Viewer – плагин просмотра PDF документов прямо в браузере.
    Моё мнение : не часто нужно, а если нужно, то есть Acrobat Reader, отключаю.
  • Google Update – плагин для обновления ПО Google.
    Моё мнение : по опыту знаю, что отключение этой назойливой штуки чревата проблемами, так что пусть будет, оставляем.
  • Adobe Reader – плагин для просмотра PDF файлов в браузере.
    Моё мнение: стрёмно обновлять, съедают адобовские «костыли», отключен.
  • VLC Web Plugin – плагин VLC проигрывателя для прослушивания/просмотра аудио/виде файлов в браузере.
    Моё мнение : интегрировался гад, обычно мне не нужен, отключаю.
  • Windows Presentation Foundation – как я понял, это плагин подсистемы из .NET Framework (начиная с версии 3.0) . Подробней читайте тут.
    Моё мнение: написано, что плагин для Firefox, да и вообще, вроде не нужно, отключаю.
Ссылка на основную публикацию
Adblock
detector