• WebGL 2 Specification

WebGL 2の最大の特徴は、2012年10月に標準化された組み込み向け3DグラフィックAPIのOpenGL ES 3.0の機能をベースにしているところです。

OpenGL ESは3DグラフィックをサポートするためのAPIで、WebGLではこの機能をブラウザ内で使えるようにすることで、ゲーム機の3Dグラフィックのような高度な3D表現をJavascriptから操作することが可能になります。

既に多くのブラウザではWebGL 1をサポートしており、すでにゲームを中心に使われる様になってきました。ChromeのCMでも使われていたChrome World Wide Mazeで使われていたので、実はWebGLを見たことがある人は多いと思います。(本記事ではWebGL 1.0をWebGL 1と表記します)

WebGL 2では、WebGL 1をベースに上位互換性を保ちつつ、さらなるパフォーマンス向上と多くの機能強化を行ってきました。

WebGL 2の特徴

WebGL 2はOpenGL ES 3.0をベースとしているため、その特徴をそのまま引き継いでいます。 大きな特徴は、陰影処理やマッピングなどの高度な表現の最適化です。3Dグラフィックでもリアリティある表現が多く求められるようになり、そのような複雑な処理を行いやすくする機能が充実しています。

Brandon Jones氏は、TojiCode: What’s coming in WebGL 2.0にて、WebGL 2の特徴と新機能を次のようにまとめています。各項目の詳細については元記事を参照してください

特徴

• Multiple Render Targets – 陰影処理などの遅延を行うDeferred Shadingの基礎技術
• Instancing – 同じオブジェクトが沢山ある処理を早くする
• Vertex Array Objects – 頂点計算の処理をまとめて行う
• Fragment Depth – フラグメントのデプス値をサポート

新機能

• Multisampled Renderbuffers
• 3D Texture
• Sampler Objects
• Uniform Buffer Objects
• Sync Objects
• Query Objects
• Transform Feedback

実装状況

WebGL 2は、Firefoxで実装が進められており、現在公開されているNightly buildで動かすことができます。

Mozilla WikiのWebGL2ページでは、サンプルコードも掲載されており、自分で試すことができます。

まとまったデモのソースコードなどはまだ公開されていませんが、下記の多くのオブジェクトを影付きで動かすデモがYoutubeで公開されています。

今後、Web上でも3D表現を使ったゲームやコンテンツが増えていくと予想されます。

WebGLの最大の問題は、Internet Explorerではサポートされていないことだと言われてきましたが、現在ベータ版のInternet Explorer 11からWebGL 1のサポートを開始しました。これによりさらにWebGLによる開発が活発化していくでしょう。

3Dグラフィックの分野は、まだまだ発展中の分野で新機能やパフォーマンスの向上が継続的に行われています。

WebGL 2はOpenGL ES 3.0という最新の3Dグラフィック環境を、ブラウザとJavascriptで試すことができるため、3Dプログラミングに興味のある方は注目してみると面白いのではないでしょうか。

前回の記事では、 wri.peの紹介と、HTML5のApplication Cacheを使ったHTMLや画像などの読み込み高速化の話をしました。今回は、Web StorageのlocalStorage/sessionStorageを使い、Ajax通信部分と表示の高速化を行う手法を説明しましょう。

localStorageを用いた通信と表示の高速化

前回のApplication Cacheで、HTMLの読み込みが高速化されました。これでも十分速くはなったのですが、画面に全ての情報が表示されるまでには、ちょっと時間がかかります。

wri.peではメモの一覧や、メモ本体の読み込み・保存はXHR(XMLHttpRequestの略。Ajax通信で使うモジュール名)を使って行っています。この内容は常に変更されるためApplication Cacheに入れるわけには行きません。そのため、実際に画面に全ての情報が表示されるのは、XHRでメモ一覧を取得した後になります。

回線が安定していれば大体一秒程度の時間ですが、ページ遷移ごとに1秒待たされると「さくさく動く」という感じではなくなってしまいます。

そこで、サーバから取得した情報をJavaScriptでキャッシュしておき、次回アクセス時には、このキャッシュの内容を表示してから、XHRを使い最新の情報をサーバから取得するようにします。

これにより、まずはキャッシュの内容を表示し、その後XHRで取得した内容を表示するため、キャッシュが古かった場合には、画面の書き換えが発生します。

一つのブラウザでwri.peを使っていれば、前回の保存内容が最新のモノなので、多くの場合はキャッシュで問題ありません。

JavaScriptでキャッシュを行うには、Web StorageのlocalStorageという機能を使います。

localStorageでは、localStorage.key1 = 'ABC';の様にlocalStorageオブジェクトに設定したデータをページの遷移やリロードに関わらず保存します。ここにXHRで取得した情報を入れておけば、キャッシュとして利用することができます。

localStorageに保存したデータは、プロトコル、ホスト名、ポートが同一の場合に読み出すことができます。そのため、同一ホスト名で動いている別のJavaScriptから情報を読み出せるため、独自ドメインなどで運用しない場合は、気をつけて使用してください。

XHRとlocalStorageを使ったサンプルが下記の様になります。

(invalid jsdo.it code)

効果を分かりやすくするために、通信部分に1秒の遅延を入れてあります。リロードするたびにランダムでJSONを取得しますが、その前に前回取得したJSONを表示する様になっています。

このようにlocalStorageに前回のアクセス情報を保存しておくことで、XHRを待たずにユーザに情報を表示させることができます。

iOSで勝手に再読込がかかってもsessionStorageがあれば大丈夫

iOSでWebアプリを作る上での最大の敵は、別のウインドウや別のアプリに切り替えた後、アプリのウインドウに戻った際に行われるページのリロードにあると思います。

この仕組みのおかげでユーザが入力中の内容が消えてしまい、ユーザビリティが大きく損なわれてしまいます。wri.peでもメモを入力中に他のアプリに切り替えただけで、メモが消えてしまってはメモ帳として使うことができません。

入力中の内容を常にlocalStorageに入れておけば、再読込がされても内容を保持することができます。しかしlocalStorageはドメイン単位で保持されるので、複数のタブでwri.peを開いていた場合、保持内容が上書きされてしまいます。

Web StorageにはlocalStorage以外に、sessionStorageという規格があります。localStorageは同一ドメインで共有された情報でしたが、sessionStorageはウインドーやタブごとに情報が保持されます。

sessionStorageを使ったサンプルが下記の様になります。sessionStorage.draft_bodyという変数はページが再読込されても保持されます。ウインドウやアプリの切り替えに伴う再読込でも、sessionStorageの内容は保持されます。

(invalid jsdo.it code)

wri.peに限らず入力フォームがありスマートフォン対応しているサイトの場合には、このsessionStorageを使う事でユーザビリティを大幅に向上できます。数行のJavaScriptで対応できるのでスマートフォン対応しているサイトぜひ試してみてください。

デザインはdribbbleから

wri.peを公開後、よく聞かれるのはデザインについてです。wri.peはアプリアイコンと英語の査読を除いて一人で作りました。

デザインをイチから考えるのは難しいので、まずは定番のTwitter Bootstrapを使ってとりあえずアプリを作りました。

その上で、dribbbleという世界のデザイナがデザインやスクリーンショットを投稿するSNSサイト上で「webapp」や「mail」などのキーワードで検索して、自分が目指すようなデザインを探します。

そこで、左にナビゲーションバーを出し、大きなアイコンを表示しているサイトがいくつかあり、これを参考にして、下記の様なデザインにしました。

はじめは上のような感じで作ったのですが、ナビゲーションとアプリの境目がはっきりするように、下のように色を調整してみました。

これだと画面に特徴がなく印象が弱いので、白黒を基本にして特徴色として自分の好きなオレンジを選びました。カラーコードを決めるのはCOLOURloversを参考にしました。

wri.pe

wri.pe（モバイル）

フリーでアイコンを配布しているサイトは多くあるのですが、サイズの変更が容易なことと、CSSのみで管理が容易な事からFont AwesomeというWeb Fontsを使っています。

Web FontsもCSS3の一機能で、ブラウザで使うフォントを外部から読み込む事ができます。Font Awesomeでは外字領域にいろいろなアイコンを定義して配布しています。

Font Awesomeはベクターなので、サイズを変更しても絵が崩れない、アイコンの色をCSSで指定できるという利点があります。しかし単色のアイコンしかないという欠点もあります。

デザインができなくても、このように既存のツールや情報の組み合わせで、それっぽいサイトを作ることができます。

デスクトップもスマートフォンも一つのHTMLで実現

Twitter Bootstrapでは、“Responsive utility”を使うことで、一つのHTMLで複数のデバイスに対応させる事ができます。wri.peも開発当初はこの機能を使っていたのですが、最近のスマートフォンは解像度が上がりタブレットとの境界が曖昧になっており、単純にタブレットやスマートフォンといった区別では、使いやすいサイトを作るのが困難だと感じました。

そこで、Bootstrapを参考にしつつ、スマートフォンやタブレットでは、縦と横でレイアウトが変わるようなライブラリを自作する事にしました。

仕組みとしては非常に簡単で、起動時にJavaScriptでデバイスの種類を判定して、bodyタグのクラスに追加します。これでHTMLのクラス指定だけで、複数デバイス対応のHTMLを書くことができます。

var userAgent = window.navigator.userAgent.toLowerCase();

var device_type = 'desktop';
if(userAgent.indexOf('ipad') > 0 ||
   userAgent.indexOf('iphone') > 0 ||
   userAgent.indexOf('ipod') > 0 ||
   userAgent.indexOf('android') > 0) {
   var win = $(window);
   if(win.width() > win.height()){
       device_type = 'tablet';
   }
   else {
       device_type = 'phone';
   }
}

$(document.body).addClass(device_type);

すこし書きやすくするために、下記の様なCSSも定義します。

body.desktop .hidden-desktop,
body.desktop .visible-phone,
body.desktop .visible-tablet
{
    display: none;
}

body.phone .visible-desktop,
body.phone .hidden-phone,
body.phone .visible-tablet
{
    display: none;
}

body.tablet .visible-desktop,
body.tablet .visible-phone,
body.tablet .hidden-tablet
{
    display: none;
}

この様に定義しておくことで、デスクトップでのみ表示させたい部分を<div class="visible-desktop">...</div>で囲うだけで、スマートフォンやタブレットでは表示されなくなります。

(invalid jsdo.it code)

wri.peでは、このようにHTML内でデバイス毎に、表示・非表示を指定することで一枚のHTMLで複数のデバイスに対応しています。

おわりに

2回に渡って、wri.peでHTML5をどのように活用しているかについて解説させて頂きました。

HTML5はアニメーションや見た目の互換性などビジュアル面が注目されがちですが、Application CacheやWeb Storageなどロジック方面も大幅に強化されおり、プログラマとしても面白い点がたくさんあります。今後HTML5が普及していく上で、この記事が少しでも参考になれば幸いです。

「wri.peで学ぶ、イマドキのWebアプリの作りかた（前編）」を読む

エキスパートが手がけたプロダクトを題材に技術的な解説を行っていくシリーズ連載、今回は wri.peです。 難しい機能の実装や、先進的なAPIの利用を通じて、執筆者が得たノウハウを余すところなく紹介していきます。

HTML5を活用したメモ帳アプリ [wri.pe]

最近、仕事で作っているミイルが忙しかったり、趣味で作っているMobiRubyがなかなか進まなかったりして、個人でWebサービス的なモノを作っていない事が自分としてちょっと気になっていました。

そこで息抜きとして、ゴールデンウイークに集中してWebサービスを一つ作ろう！と思い立ち、wri.peというWebサービスの開発に着手しました。

wri.peは自分が使いたいと思えるメモ帳を作ったので、下記の様な特徴を持っています。

• Markdownフォーマットをサポート
• Gmailの様なアーカイブ機能
• 全文検索
• カレンダーへのマッピング
• iPhone / iPadをサポート
• キーボードで操作ができる

ゴールデンウイーク期間中に一通り作った後、一カ月ほど自分で使いながらブラッシュアップし、6月3日に正式にリリースしました。

初めて個人でプレスリリースを打ってみたところ、個人でリリースしたWebサービスとしては多くの国内外のメディアやブログに取り上げていただきました。

wri.pe

wri.pe（モバイル）

wri.peが目指すモノ

wri.peは息抜きで作ったモノですが、せっかく作るのだからといくつかの目標を立てました。詳しくはブログをご覧頂きたいのですが、その中の一つに、新しい技術で製品レベルのサイトを作った場合に起こる問題点などを把握したいという目標がありました。

HTML5の機能やBackboneJSなど耳にすることはあっても、実際に製品レベルのサイトで使って大丈夫なのか自分の肌感覚として把握できていないと仕事などで使うことができません。

HTML5というと、CSS3を用いたアニメーションや3D表現、ビデオやオーディオの標準化など、ブラウザ上の表現力向上が多く取り上げられます。 またHTML5の仕様には入りませんでしたが、WebSocketを用いたリアルタイム通信やGeolocation APIを使った位置情報の取得なども、広義のHTML5として話題になっています。

そこでwri.peでは、HTML5の中でも速度の向上にターゲットを絞って、新しい機能を使ってみることにしました。

サイトの高速化のためにHTML5を使用する

ほとんどのブラウザでは、通信をキャッシュする機能を有していて、同じページや画像の表示を高速化しています。 このキャッシュの制御はWebサーバで設定を行い、HTTPヘッダに特別な値を設定する事で有効期限などを設定することができます。 HTML5では、そうした既存のキャッシュ機構に加えて、Application Cacheというキャッシュ機構を持っています。

Application Cacheで通信を減らそう

このApplication Cacheは本来、Webアプリをオフラインでも動かすために、通信状況に関係なくHTMLや画像を読み込むことのできるキャッシュとして設計されました。 しかし通常のWebサイトでもこのApplication Cacheを使うことで、画像などを読み込むためのネットワークアクセスを抑制し、ページの読み込み速度を上げることができます。

Application Cacheは、マニフェストファイルと呼ばれるファイルにキャッシュしたいファイル名を書くだけでキャッシュが行われます。そのため、HTMLやJavaScriptファイルに変更の必要がなく、手軽に導入できるというメリットがあります。

変更頻度の低いロゴなどの画像やCSSなどをこのマニフェストファイルに記述し、HTMLの中でマニフェストファイルのパスを指定するだけです。

なお、wri.peではrack-offlineというライブラリを使い、マニフェストファイルを生成しています。

例) http://wri.pe/application.appcache

CACHE MANIFEST
# 91ccff4f438451ad735c534b974c29e2ff1b08a9da4e71f928b5fc2f4ba6bd02
/assets/app-437607bb972a49c7922a504cfe02226a.css
/assets/app-7c794995cb685c8412ee2f1facea67e3.js
/fonts/fontawesome-webfont-311.ttf
/fonts/fontawesome-webfont-311.woff
/images/wripe114s.png
/images/dropbox_icon128.png
/images/wripe400s.png
/images/wripe-top880.png
/images/masuidrive64.jpg

NETWORK:
*

HTML部

:html:
<!DOCTYPE html>
<html lang="en" manifest="application.manifest" xmlns:og="http://ogp.me/ns#" xmlns:fb="http://www.facebook.com/2008/fbml">
<head>
....

Application Cacheでは、コメントも含めマニフェストファイルが１文字でも変更されるとキャッシュが破棄され、ネットワークから最新のデータが読み込まれます。 このキャッシュの制御はJavaScriptから行う事が可能なのですが、iOS 6ではバグがあるようでJavaScriptからキャッシュの更新などが正しく行えないようです。

またリソースの変更後にマニフェストファイルを更新しても、その変更が反映されるのは次回の読み込み時になります。そのため、更新頻度の高いファイルをキャッシュする用途にはあまり向きません。

wri.peでは、RailsのAssets Pipelineという機能を使い、JavaScriptとCSSをそれぞれ一つのファイルにまとめることで、ファイルの読み込み回数を減らし、表示を高速化しています。

実際に読み込み時間を比較してみます。赤い縦の線が、大体画面に表示される時間だと思ってください。

キャッシュのない状態では1,150ms、キャッシュありでは200msほどになります。

テストでは、回線が高速なため、思ったよりも差が出なくなっていますが、スマホなどでキャッシュなしの場合には、これより数倍遅くなる事が多いと思われます。キャッシュありの場合では回線速度に依存せず、安定して高速な読み込みが可能です。

また、Application Cacheにキャッシュされているファイルは、ネットに繋がっていない状態でも読み出すことができます。 試しにPCをネットから切り離すか、iPhone/Androidをフライトモードにして、https://wri.pe/app にアクセスしてみてください。全てのファイルがキャッシュから読み込まれるため、ネットに繋がっていない状態でも同じように表示されるでしょう。

ただしメモ帳のデータはApplication Cacheには入っていないので、本来であればオフライン時に読み込むことはできません。しかしそれらの情報はまた別の方法でキャッシュしているため、オフライン状態でもメモ一覧が表示されるのです。

次回予告

今回はApplication Cacheを使い、各種ファイルの読み込みを高速化する手法を取り上げました。

wri.peでは、メモ帳データのようにAjax通信で取り出すためキャッシュしにくいデータも、localStorageを使いキャッシュしています。

次回はlocalStorageを用いたデータのキャッシュや、PC向けブラウザ、iPhone/Android、iPadなどのタブレットを一つのHTMLで対応する手法について解説します。

「HTML5でサイトを高速化─wri.peで学ぶ、イマドキのWebアプリの作りかた（後編）」に続きます。