【ITニュース解説】Every data grid claims to handle live data.

データグリッドとは、Webアプリケーションでよく使われる、表形式でデータを表示し操作するための部品である。株価のリアルタイム表示や、センサーデータの監視画面など、常にデータが更新され続ける「ライブデータ」を扱う場面で、データグリッドがどれだけスムーズに動作するかが重要になる。このニュース記事では、データグリッドがライブデータをどれだけ効率的に扱えるかを検証するため、人気ゲーム「Doom」をデータグリッドの「画面」として動かすというユニークな実験が行われた話を紹介する。これは単なるデモではなく、データグリッドのリアルタイムデータ処理性能を徹底的に測定し、改善するための重要な取り組みだった。

この検証のために、まずオリジナルのDoomゲームのプログラムを「doomgeneric」という、描画されたフレームを生のピクセルデータとして渡すだけのシンプルな版に移植した。これを「Emscripten」というツールを使って、Webブラウザで高速に動作する「WebAssembly」形式に変換した。WebAssemblyは、ブラウザ上でCやC++などの高性能なプログラムを動かすための技術だ。この実験環境では、一般的なゲームで使われる描画機能（SDL、オーディオ、canvas）は一切使わない。ゲームの各フレームは320x200ピクセルの画像データとして生成され、Webページに渡される。プログラムはこの新しいフレームを前のフレームと比較し、どこが変更されたかを特定する。そして、変更があった「行」だけを、データグリッドの通常のデータ更新関数 grid.rows.apply を使ってグリッドに送り込む。データグリッドは、これがゲームの画面データだとは知らず、ただデータが更新されたと認識して処理を進める。

最初の試みでは、最も単純な方法として、ゲーム画面の1ピクセルをデータグリッドの1セルに対応させた。例えば、80x50ピクセルの画面では、4,000個のセルを使ってDoomの画面を表現し、各セルの背景色を対応するピクセルの色で塗る。この方法では、約33フレーム/秒（fps）でゲームを動かすことができた。しかし、データグリッドが更新処理を行うのにどれくらいの時間がかかっているかを正確に測定すると、すぐに課題が見つかった。データをグリッドに送る rows.apply という呼び出し自体のエンキュー（処理待ち行列に入れる）コストは約17ミリ秒だったが、これは真の性能ではなかった。データグリッドのような複雑な描画コンポーネントは、ブラウザの描画処理のタイミングに合わせて、実際に画面に表示されるDOM（Document Object Model、Webページの構造）への書き込みを遅延させるのが一般的だ。そのため、正確な測定のためには、データ更新関数が呼び出されてから、実際に画面上のセルの色が変化し、ブラウザに描画されるまでの時間を測定する必要があった。このために専用の測定ツール（ハーネス）を作成し、以後の性能改善の基準とした。

この測定の結果、160x100ピクセル以上の解像度（1万セル以上）になると、Webブラウザそのものがボトルネックになることが判明した。ブラウザが1フレームごとに何万ものDOM要素（この場合はグリッドのセル）のスタイルを変更し、再描画する処理は、ゲームのような高速な更新には追いつけないのだ。これは、DOMを直接大量に操作する方法に限界があることを示していた。

この限界を克服するために、デモでは異なる描画方法が採用された。新しい方法では、データグリッドは1列200行という構成になる。つまり、ゲーム画面の各「行」を、グリッドの1つの「セル」として扱うのだ。そして、この1つのセルの中に、その行のすべてのピクセル情報を表現する。具体的には、同じ色が連続するピクセルを結合し、それを「ハードストップCSSグラデーション」という技術を使って描画する。CSSグラデーションは、CSSのスタイル指定で色を段階的に変化させる表現方法で、これを使うことで、複数の色の帯を1つのCSSプロパティで効率的に表現できる。この方法によって、たとえ35,000ピクセルもの情報が1フレームで更新されても、データグリッドに送られるのは約170行分の書き込みに抑えられるようになった。これにより、320x200のネイティブ解像度で、デスクトップ版Chromeでは30〜60fpsという高速な動作を実現し、今ではゲームエンジン自身の35fpsというフレームレート制限がボトルネックとなっている。デモでは、性能に応じて80x50、160x100の解像度を切り替える機能や、最初の数秒間で30fpsを維持できない場合に自動的に160x100に切り替えるフォールバック機能も提供されている。

このDoomのデモを通じた徹底的な検証は、単なる面白い実験で終わらず、実際にデータグリッド製品自体に大きな改善をもたらした。その改善点のうち2つは、すぐにすべてのユーザーに提供された。

1つ目は、「条件付き書式ルールのコスト削減」だ。条件付き書式とは、データの内容（例えば株価が上がった、下がったなど）に応じてセルの見た目を変更する機能である。これまでは、このようなルールを多くのセルに適用すると更新コストが増大する傾向があったが、一括更新時にはスタイルが適用されていないセルと同じコストで処理されるようになった。これにより、たとえライブボード上の4,000個すべてのセルに条件付き書式が設定されていても、1フレームでスムーズに更新できるようになっている。

2つ目は、「部分更新の最適化」だ。以前は、一部のデータが変更されただけでも、必要以上に多くの処理が行われることがあったが、この改善により、実際に変更された「行」と「セル」だけが処理されるようになった。セルの属性、CSSクラス、表示テキスト、セル位置などの情報は、その値が実際に変更された場合にのみ書き換えられる。また、セルのテキストや幅が変わった場合のみ実行される「オーバーフロータイトル」（テキストがセルに収まりきらない場合に表示されるツールチップのようなもの）の測定処理も、必要最小限に抑えられている。この最適化により、80x50グリッドで4,000個のスタイル付きセルが変更されても約49ミリ秒、900個のセル変更なら約33ミリ秒で画面に反映されるという結果が出ている。

これらの改善は、特別な設定やオプションを有効にすることなく、データグリッドの全てのユーザーに自動的に適用される。これにより、ウェブソケット（リアルタイム通信技術）やポーリング（定期的なデータ取得）ループ、あるいは株のトレーディングフィードのようなリアルタイムデータを扱うアプリケーションは、1回のデータ更新あたりの処理量が自然と減り、より効率的に、そして高速に動作するようになったのだ。このDoomを使った検証は、データグリッドがライブデータを扱う上でのボトルネックを特定し、それを根本的に解決する大きな一歩となったと言えるだろう。