【解決済み】ImageManager.requestPictureの使い方について

[べるろ＊(米工事)]

恐れ入ります。

スクリプトImageManager.requestPictureを用いてピクチャ表示用画像の先読みを行いたいのですが、なかなかうまくいかずピクチャの読み込み時に依然ラグが生じてしまします。
現在設置しているイベントの具体的な内容は以下の通りです。

トリガー：並列処理
実行内容：コモンイベントの呼び出し
コモンイベントの内容：ImageManager.requestPictureを用いて同マップ内で表示予定の画像(10～50枚)をすべて読み込むスクリプトを実行し、最後に「イベントの一時削除」

そもそもImageManager.requestPictureの使い方としてこれが正しいのかも分かっていません。
スクリプト関連に詳しい方、すでにこのスクリプトを使用されている方がいらっしゃいましたらご助言お願いいたします。

[WTR]

並列処理してる理由はなんでしょう？
1回でいいはずなので自動実行にしてみては。

関係なかったらすみません。

[べるろ＊(米工事)]

回答ありがとうございます！
並列にしているのは他のイベントを同時に自動処理で行う場面がいくつかあり、ピクチャ表示と事前読み込みの処理順が前後する可能性を防ぐためです。
一応自動実行でも試してみましたが、状況は同じでした。

並列処理してる理由はなんでしょう？
1回でいいはずなので自動実行にしてみては。

関係なかったらすみません。

[WTR]

なるほどー。関係なしでしたか。

ところで並列処理だと処理順が補償されるという考え方がイマイチ理解できません。
プリロードを自動実行後なにかスイッチをONにして、そのスイッチをトリガーに他の自動実行が開始、みたいな処理がよくないでしょうか。

仕組みを知ってるわけじゃないんで適当なことしか言えませんが
プリロードの命令を出すだけで、本当にメモリに転送完了するまで自動で待ってくれてるわけではないのかも？
だとしたらプリロードイベントの最後にwaitいれたら変わったり？
すべてカンですが…

[べるろ＊(米工事)]

重ねてのアドバイスありがとうございます。

並列にしたのは処理順を保証するというより、処理が他のイベントより後になることを防ぐための処理です。
おっしゃる通り、プリロードを行う場合はスイッチなどを利用してプリロードイベントが完了してから他のイベントを実行することが理想です。
ただ、どうやらツクールMVの仕様上、コモンイベント内のスクリプトで呼び出したメソッドは呼び出し元のイベントと並列で実行されてしまうようなのです。
なので、プリロード処理が完了する前にコモンイベントが終了して次のイベントに進んでしまいますから、試してみたところコモンイベントが先に実行されようが並列で実行されようがあまり関係ないようでした。
それを見越して、次に実行させるイベントの前に長いウェイトをかけてみても結局ラグは生じてしまいました。
もし画像読み込みの完了まで画面処理をウェイトさせるようなスクリプトがあれば正常に実行されたかどうかくらいは判別できるのですが、javascriptをそこまでよくわかっていないので方法がわかりません……

なるほどー。関係なしでしたか。

ところで並列処理だと処理順が補償されるという考え方がイマイチ理解できません。
プリロードを自動実行後なにかスイッチをONにして、そのスイッチをトリガーに他の自動実行が開始、みたいな処理がよくないでしょうか。

仕組みを知ってるわけじゃないんで適当なことしか言えませんが
プリロードの命令を出すだけで、本当にメモリに転送完了するまで自動で待ってくれてるわけではないのかも？
だとしたらプリロードイベントの最後にwaitいれたら変わったり？
すべてカンですが…

[WTR]

うーん、どうやらお役に立てないようで。。

待ってもダメということはそもそもプリロードが走ってないのではという気がしなくもないですが
ローカルだと816 x 624サイズを何もせずに100枚表示しても即時表示されるんでなんとも効果がわかりにくくて無理でした
Community_Basicプラグインでキャッシュの上限が設定されてるっぽいですが上限に引っかかるサイズだったりしないか、
実際に一度透明状態のピクチャを表示しておく手段だと結果が違うか、
あと気になるのはその辺ですかねぇ…

[tubo]

ロード処理は元々並列処理なので、ロード完了を保証したい場合は loadPictureか reservePictureで読み込んで、
ImageManager.isReady()で読み込み完了を確認する必要があります。

それでも固まる場合は、画像が重すぎて初回描画時に固まっている可能性が高いです。
その場合は先に見えないように一度描画する必要があります。

[べるろ＊(米工事)]

ImageManager.loadPicture と ImageManager.isReady の組み合わせでプリロードできました！ありがとうございます！
ところで、新規ピクチャ表示時のラグは解消されたのですが、同じピクチャ番号に上書きするとき画像が一瞬消えるのは仕様なのでしょうか？
同じ画像ファイルを再び同じピクチャ番号に上書きした場合は消えずにスムーズに切り替わるのでこちらもプリロードする方法がありそうですが……

ロード処理は元々並列処理なので、ロード完了を保証したい場合は loadPictureか reservePictureで読み込んで、
ImageManager.isReady()で読み込み完了を確認する必要があります。

それでも固まる場合は、画像が重すぎて初回描画時に固まっている可能性が高いです。
その場合は先に見えないように一度描画する必要があります。

[tubo]

WTRさんのおっしゃっているようにキャッシュ上限を確認して、問題なければ描画のラグの可能性が高いです。
サイズが大きい画像は描画にラグが発生することがあります。
特に初回描画が重いので、前もって描画を行うと改善されるかもしれません。
透過度０だと描画処理を行わないので、画面外に描画するか透過度１で描画してください。

それでもだめならピクチャを２枚使って、画面外に１枚描画しておき入れ替えるくらいしかないです。

[べるろ＊(米工事)]

WTRさん、tuboさん
スクリプトの書き換えに加えてキャッシュ上限も引き上げたところ、すべての問題が解決されました。
長々とお付き合いくださりありがとうございました！

うーん、どうやらお役に立てないようで。。

待ってもダメということはそもそもプリロードが走ってないのではという気がしなくもないですが
ローカルだと816 x 624サイズを何もせずに100枚表示しても即時表示されるんでなんとも効果がわかりにくくて無理でした
Community_Basicプラグインでキャッシュの上限が設定されてるっぽいですが上限に引っかかるサイズだったりしないか、
実際に一度透明状態のピクチャを表示しておく手段だと結果が違うか、
あと気になるのはその辺ですかねぇ…

WTRさんのおっしゃっているようにキャッシュ上限を確認して、問題なければ描画のラグの可能性が高いです。
サイズが大きい画像は描画にラグが発生することがあります。
特に初回描画が重いので、前もって描画を行うと改善されるかもしれません。
透過度０だと描画処理を行わないので、画面外に描画するか透過度１で描画してください。

それでもだめならピクチャを２枚使って、画面外に１枚描画しておき入れ替えるくらいしかないです。