クラッシュ時のエラーコンソールを確認するに, 主たる原因はcanvasグラフィックを描く際のメモリ浪費にあると当たりをつけ, この部分を修正するユーザースクリプトを作ってみた.
なお, これで本当に問題が解決するかどうかは全く不明なため, 本スクリプトを利用する際は全て自己責任にてお願いします. 現状困っていないのであれば無理に導入する必要はありません.
(今日の今日作った突貫工事品だし, さほど検証もしていないし. 効果があるといいなあ. 何度もクラッシュするのは精神的にきついので)
→実際に改善効果があるっぽいので, 困っている方は是非試してみて下さい.
追記:2018/02/03
[重要]
Chrome 64.0.3282.140にて, 致命的にパフォーマンスが落ちた(メモリを浪費する)場合は
追記:2018/02/05
対処方法をまとめました.
追記:2018/02/14
[重要]
Chrome 64.0.3282.167(Official Build) (64 ビット)
が公開されました. 本バージョンでは上記不具合が解消しています.
[使い方]
通常のユーザースクリプトの導入と一緒.
- Web Extensionsをサポートする環境(FireFox, Chrome, Opera等)
Tampermonkeyアドオンを導入して下記コードを新規ユーザースクリプトとして登録 - レガシーFireFox(※動くかどうか確認していないが多分動くと思う)
GreaseMonkeyアドオンを導入して下記コードをユーザースクリプトとして登録
導入するとカンバス周りのAPIの中身を書き換えて, ゲーム本体に手を入れることなくパフォーマンスが改善します.
// ==UserScript==
// @name aigis_oshiro_light
// @namespace defghi1977
// @description 千年戦争アイギス/御城プロジェクト:REの動作を保護します
// @include http://assets.shiropro-re.net/html/Oshiro.html
// @include http://assets.millennium-war.net/*
// @version 0.1
// @grant none
// ==/UserScript==
//createImageDataメソッドの呼び出し過ぎによるメモリ浪費を抑え
//予期せぬクラッシュの頻度を下げます
'use strict';
{
const proto = CanvasRenderingContext2D.prototype;
const o_createImageData = proto.createImageData;
const initialSize = 2048 * 2048 * 4;//16MB
let sharedBuffer = new ArrayBuffer(initialSize);
proto.createImageData = function(x, y){
const requiredSize = x * y * 4;
if(requiredSize > sharedBuffer.length){
sharedBuffer = new ArrayBuffer(sharedBuffer.length * 2);
}
const array = new Uint8ClampedArray(sharedBuffer, 0, requiredSize);
array.fill(0);
const id = new ImageData(array, x, y);
return id;
};
}
なに?殿はコピペは嫌か?
しからばこのリンクをクリックするのだ!
インストーラが立ち上がるから導入が楽ぞ!
スクリプトの導入は自己責任だが、中身は大したことないから安心するが良いぞ!
[原因(仮説)]
本ゲームはゲーム内のテキスト(およびドット絵)を描画する際にゲームサーバーから転送された(文字)画像を利用している.
この画像は何らかの形式で圧縮されており, これを展開した後にcanvas要素に描画することとなるが, その際に生成するImageDataオブジェクトの数がべらぼうに多い.
具体的には1操作につき多くのImageDataオブジェクトが生成されるが, その都度数百KB〜十数MBのメモリを消費しており, 現状全て使い捨てである.
そのため, ゲーム本編よりもむしろイベント会話中の方がメモリの浪費が激しく, ブラウザが不安定となり得, これは経験的なゲームクラッシュのタイミングとも一致している.
・追記
なお, 得られた画像は内部で高コストなcanvas要素としてキャッシュされており, これらも徐々にメモリを逼迫していく(メモリリーク). そのため, ゲームを進行していくとどこかのタイミングでメモリが確保できなくなりクラッシュする(しやすくなる)のである.
[対策]
根本的にフレームワーク側の「お大尽」なメモリ管理に起因する問題であるため, ユーザースクリプト側での対策はかなり限定される. (フレームワーク内部のメモリリークを改善することは出来ない)
そのため対症療法ではあるが, ImageDataオブジェクトが単一のメモリ(ArrayBuffer)を共有するように機能を改めた. (createImageDataメソッドとputImageDataメソッドの呼び出し順を検証するに,ゲーム内部でのImageDataオブジェクトの再利用が存在しないことから)
こうすることでメモリの確保・開放のサイクル(ガベージコレクトの頻度)が抑えられ, 結果アプリの安定度が増す.
この考え方は他のブラウザゲームにも適用可能かもしれないので憶えておくと良いだろう.
・追記(2017/09/03)
Chromeではハードウェアアクセラレーションが有効な場合にImageDataオブジェクトを介したグラフィック操作が高コストとなる. そのため, 当該ゲームにおける推奨動作環境として「ハードウェアアクセラレーションをOFF」とする必要があるようだ.
・追記(2017/09/14)
Chromeに導入して一週間程経ったが,体感では大幅にクラッシュの頻度が減った(というかクラッシュしなくなった). 時折ゲームが停止しているように見えることがあるものの, おそらくメモリのガベージコレクトによるものであり, このタイミングでのクラッシュが無くなっただけでも大きな成果と言えよう.
・追記(2017/09/25)
前回の追記より2度クラッシュを経験. なおタイミングはテキスト読み込みと異なるため, 本スクリプトの対処範囲外のメモリリークによるものと推察される.
(…が64bitとは言えメモリを8GB積んでクラッシュするってのはアイギス側だけじゃなくてChromeが不安定すぎる気がする)
・追記(2017/09/25その2)
城プロ:REについて, 画像取扱処理の変更がシステム不安定化の一因ではないかとの推測を立てた.
- 以前・・・城娘アイコン画像を一覧としてcanvasに書き込み, そこから適宜スクリーンに転写
- 現在・・・城娘毎にcanvasを用意し, そこに描いたアイコン画像をスクリーンに転写
(いずれも画面遷移毎に生成・破棄)
つまり, 前よりcanvas要素の生成数が格段に増加している.
一般にDOMオブジェクトを過剰に生成・破棄するとブラウザが不安定化するが, canvas要素もHTMLCanvasElementインターフェースを実装するDOMオブジェクトである. 従ってある時から小さなcanvas要素を多量に生成・破棄するように処理が変更されたことでゲームが不安定化したのではないか?
対策としては一度生成したcanvas要素はキャッシュもしくはプールして使いまわすようにし, DOMオブジェクトの過剰な生成を防ぐ.
この動作をユーザースクリプト側で制御するのはおそらく無理なので, 何とかメーカー側で対処してもらいたいところ.
0 件のコメント:
コメントを投稿