文字の一部がブロック状に欠ける問題について

fspace · 2025-01-29

最新のツクールMZ（v1.8.1）とそれ以前のいくつかのバージョンで、文字描画時に文字の一部がブロック（XY軸に平行な矩形）状に欠ける問題が発生しています。また、同一の問題かどうかは不明ですが、欠けるのではなく塗りつぶされたようになったり、ずれたように乱れるケースも存在するようです。

この問題で困ってる人をちょくちょく見かけるので、わかる範囲のことを書いときます。

TL;DR

正確な原因は不明
NW.js内のChromiumの不具合の可能性がある
NW.jsを更新しよう（ただし自己責任で）

問題の原因

初めに言っておくと、文字が正常に描画されない正確な原因はわかりません。というのも、おそらくこの問題の原因箇所はツクールやプラグインの開発者が直接確認するのが難しい基盤に近い部分にあるためです。

まず、この不具合はプラグインを一切導入していない初期プロジェクトでも発生するため、プラグインが原因ではありません（もちろん類似の現象を引き起こす別の不具合だった場合にはその限りではありませんが……）。また、文字の一部のみが欠けることから、文字描画処理自体を実装していないコアスクリプトやPixiJSのようなライブラリ（プログラムの部品）が原因とも考えづらいです。そうなると、原因はこれらを動かしている、もっと基盤に近い技術にあることになります。

ツクールMZのゲーム部分にはWeb関連技術が用いられていますが、その際デスクトップアプリとしてWeb関連技術を動かすのにNW.jsというOSS（オープンソースソフトウェア。雑に理解するなら「自由に使える無料のソフトウェア」）を利用しています。また、NW.jsはその内部でChromiumというOSSを利用していて、Web関連技術の実装は基本的にすべてこの中に含まれています。ちなみに、Chromiumはその名前から推測できる通り、Google Chromeが内部で利用しているもので、Microsoft EdgeやOperaなど他のブラウザでも利用されています。

さて、件の文字描画処理ですが、これもWeb関連技術の一部なのでChromium内にその実装があると思われます（正確にはさらに内部のSkiaやANGLEなどかもしれませんがとりあえず置いときます）。最新のツクールMZ（v1.8.1）に含まれるNW.jsのバージョンは0.48.4で、それに含まれるChromiumのバージョンは85.0.4183.121ですが、実際にChromium 85前後でいくつか文字描画に関する問題が報告されているようです。2020年頃にリリースされたバージョンなので、もしこれらと同一の原因であったならChromiumをより新しいものに更新すれば、修正されていることが期待できそうです。

といっても、Chromiumを直接更新することはできません。そのため、NW.jsを新しいものへと更新することで、内部のChromiumを新しいものへと更新する必要があります。

本来はNW.jsについてもツクールMZを更新することで更新されていくはずだったのですが、ツクールはサポート切れの旧いOSに対応するためにNW.jsの更新を止めるというよくわからない判断をしたため、v1.6.1以降、NW.jsの新しい版が提供されなくなってしまいました（NW.jsが内部で利用しているNode.jsというOSSがサポートの切れたOSへの対応を打ち切ったことにより、更新するとそれらのOSで動作しなくなってしまうため。そもそもサポート切れのOSを使うこと自体がセキュリティリスクで推奨されないのでNode.jsの対応の方が普通です）。今後もNW.jsが更新されることはないと思われるため、NW.jsの更新は各自で行う必要があります。

対処方法

前述の通り正確な原因は不明なため確実な方法ではありませんが、現状最も期待できる対処方法はNW.jsの更新で、実際に改善の報告がいくつかあります。

NW.jsの更新方法については、すでにいくつか解説があるようなので省略します。というか、NW.jsが更新されないせいで最近のmacOSでゲームが正常に動作しないことがあるらしく、公式ブログにその対応のための記事があります。Mac用の解説ですが、ダウンロードファイルとインストールフォルダの場所や構造が少し異なるだけで、Windowsでもそれほど変わらないはずです。

更新にあたっては注意点がいくつか。

まず、公式ブログの記事にもありますが、更新は自己責任です。いちおう大部分の後方互換性はあるはずなので、基本的には更新しても問題なく動作するはずなのですが、複雑なソフトウェアなので想定通りにいかないこともしばしばです。別の問題を引き起こす可能性があるということを頭に入れた上で、何か問題が起きた時に元に戻せるようにしておきましょう。

次に、テスト環境で使用されるNW.jsとデプロイメント時の出力に含まれるNW.jsが同じものとは限りません（特に開発環境とは異なる実行環境向けに出力した場合）。自分の環境では問題が解消されたのに、ユーザーからは問題が報告されたという場合には、配布ゲーム中のNW.jsのバージョンがきちんと更新されているかどうかを確認しましょう。

また、ツクールMZを更新すると、更新したNW.jsのバージョンが元に戻ってしまう可能性があります。ツクールMZの更新後に問題が再発した場合には、NW.jsのバージョンが変化していないかどうかを確認しましょう。

最後に、前述の通りNW.jsを更新すると旧いOSでは動作しなくなるため、通常のツクールMZとは動作要件が変わります。ゲームの動作要件に「ツクールMZの動作する環境」とか書くと嘘つくことになるので注意しましょう。

実行中のNW.jsやらのバージョンを表示するプラグインを置いておくので、正しく更新されたかどうかの確認にご利用ください。

その他の情報

環境依存で、Windows 11のラップトップPCでよく発生するとの噂。ミニPCでも発生しているので、IntelのiGPUによるGPUアクセラレーション周りの問題の可能性あり
MPP_MessageEXを導入すると改善されるとの噂。実際に入れてみると確かに発生しなくなったように見えるものの、依然として発生するという報告もあり
- どうもすでに一度表示した（ラスタライズされた？）Canvasに再度描き込んだ場合に発生する様子
- MPP_MessageEXを導入すると、一度新しいCanvasに描き込んだのちに転写するという挙動になるため、そちらに起因している可能性あり
Chromium 85前後でのフォントレンダリング周りの問題

検証への協力のお願い

個人的に少し気になることがあるので、自分の環境で問題が発生しているという方は、添付のプラグインを導入して問題が解消されるかどうかを報告してもらえると嬉しいです。

ついでに、どんな環境で問題が発生しているかのデータも集めたいので、実行環境のOS、CPU、GPUもわかる範囲で併記してもらえると助かります。

なお、プラグインはテスト環境でしか動作しないようにしているので、たとえ問題が解消されたとしてもゲームには組み込まないでください。

pibo · 2025-02-05

私も自身のいくつかの端末で同一問題を確認しています。

根治となるとNW.jsの更新になるのでしょうが動作保証がなくなるという
それなりに大きいデメリットもあるので、
プラグインによる対症療法でも対策できるといいのですが…。

MZで開発されている方は自身の開発環境で問題なかったとしても、
配布して多様な環境下で遊んでもらうことを考えた場合は決して他人ごとではない問題だと思っています。
こうして情報をまとめて頂けたのは本当にありがたいです。

報告の通りやはりラップトップ、タブレットでの発生頻度が高いです。
また、フォントサイズを小さくするほど、フォントカラー変更を行うほど
表示欠けが発生しやすいという実感があります。

MPP_MessageEXの有無の差異はわかりません。
当方のゲームでは当該プラグインを導入しており、
メッセージテキストはほとんどバグが発生せず（フォントを小さくした場合に発生）、
それ以外のUI（メニュー画面で小さく表示してる文字等）の小さなフォントが欠けることが多いです。

追記ー

環境依存で、Windows 11のラップトップPCでよく発生するとの噂。ミニPCでも発生しているので、IntelのiGPUによるGPUアクセラレーション周りの問題の可能性あり

とのことですが、１～2年くらい前にツクール側は一切変更していないにも関わらずintel製内臓gpuのファーム更新以降に突然バグが発生するようになった端末があるので、個人的にはこの線が怪しいと踏んでいます。

fspace · 2025-02-06

情報提供ありがとうございます。

piboの発言:
根治となるとNW.jsの更新になるのでしょうが動作保証がなくなるという
それなりに大きいデメリットもあるので、
プラグインによる対症療法でも対策できるといいのですが…。

最後に書いた検証プラグインの方法が対症療法といえば対症療法なんですが、こちらもパフォーマンスの大幅低下というデカめのデメリットがあるので、安易には使えないんですよね。元々ツクールはスクリプトやプラグインを使ってしまえば動作保証が限定的なのと、互換性にかなり配慮しているWeb周りの更新が問題を起こす可能性もそこまで高くないだろうということで、NW.jsの更新の方を推奨してます。

本当はNW.jsを更新するように（あるいはMZの後継を早く出すように）ツクールに~~圧をかける~~お願いするのが一番いいんでしょうが、NW.jsの更新停止を問題視している人がそこまで多くない印象で、大した勢力にならなさそうなんですよね……。

piboの発言:
MPP_MessageEXの有無の差異はわかりません。
当方のゲームでは当該プラグインを導入しており、
メッセージテキストはほとんどバグが発生せず（フォントを小さくした場合に発生）、
それ以外のUI（メニュー画面で小さく表示してる文字等）の小さなフォントが欠けることが多いです。

MPP_MessageEXはメッセージ部分にしか影響しないはずなので、UI周りには無力ですね。

メッセージ部分に関しては、頻度は減るけど稀に発生するというのが奇妙ですね。原因に対処できているならまったく発生しないはずですし、そうでないなら頻度は減らないはずなので。実装をあまりよく読んでないのでわかりませんが、対処コードを迂回するケースが存在しているか、競合で無効化されるケースが存在するか、その辺りでしょうか。

piboの発言:
１～2年くらい前にツクール側は一切変更していないにも関わらずintel製内臓gpuのファーム更新以降に突然バグが発生するようになった端末があるので、個人的にはこの線が怪しいと踏んでいます。

他の方の話も聞いていると、やはりGPUアクセラレーション周りの問題の可能性は高そうですね。対象がIntel製のiGPUというのも確度高めです。Windows 11が関係しているかどうかは謎ですが。

pibo · 2025-02-07

最後に書いた検証プラグインの方法が対症療法といえば対症療法なんですが、こちらもパフォーマンスの大幅低下というデカめのデメリットがあるので、安易には使えないんですよね。元々ツクールはスクリプトやプラグインを使ってしまえば動作保証が限定的なのと、互換性にかなり配慮しているWeb周りの更新が問題を起こす可能性もそこまで高くないだろうということで、NW.jsの更新の方を推奨してます。

万一でも未知の不具合が発生しかねないリスクと、直ちに進行不可になるわけではない不具合の解消を天秤にかけてどちらをとるか、
この辺のプライオリティは制作している作品の配布形態や規模感で結構変わってきそうではありますね。

私の作品なんかはフリー配布でプレイヤーもそんないないので仮にNW.js更新で未知の不具合を踏んだとしても気楽なものですが、
販売したりたくさんのプレイヤーがいる開発者の方の場合だと購入者に対する責任と保証がありますので、
公式の動作保証を外れて万一でも未知の不具合が紛れ込むリスクを受け入れなければいけないのは少し胃の痛い決断になりそうです。

ところでスレッドの本筋と逸れてしまい恐縮なのですが、MPP_MessageEXってパフォーマンスには結構影響出ますか？
あくまで私の場合ですがfpsが気になる局面は入力に対して密なフィードバックが求められる移動時のカクつきがほとんどで、
実践的にはあってもなくてもパフォーマンスに影響を感じたことがないプラグインだったので気になりました。

快適に遊べるスペックの下限はなるべく広くとりたいなぁと考えているので、導入可否の参考までに
ゲーム解像度、ざっくりと端末スペック、プラグインの有無で影響が出たと感じたシーンを教えて頂けると大変助かります…。

utunnels · 2025-02-07

これはパフォーマンスに大きな影響を与えますか？
プラグインはgetImageDataを一度しか使いませんし、いずれにせよこの方法はColorManager.textColorでも使われます。

fspace · 2025-02-07

piboの発言:
万一でも未知の不具合が発生しかねないリスクと、直ちに進行不可になるわけではない不具合の解消を天秤にかけてどちらをとるか、
この辺のプライオリティは制作している作品の配布形態や規模感で結構変わってきそうではありますね。

私の作品なんかはフリー配布でプレイヤーもそんないないので仮にNW.js更新で未知の不具合を踏んだとしても気楽なものですが、
販売したりたくさんのプレイヤーがいる開発者の方の場合だと購入者に対する責任と保証がありますので、
公式の動作保証を外れて万一でも未知の不具合が紛れ込むリスクを受け入れなければいけないのは少し胃の痛い決断になりそうです。

そうですね。ただ未知の不具合や動作保証外に関してはスクリプトやプラグインの導入でも同じなので、元々これらを受け入れているならそこまで恐れ過ぎる必要もないのかなと思います。

piboの発言:
ところでスレッドの本筋と逸れてしまい恐縮なのですが、MPP_MessageEXってパフォーマンスには結構影響出ますか？
あくまで私の場合ですがfpsが気になる局面は入力に対して密なフィードバックが求められる移動時のカクつきがほとんどで、
実践的にはあってもなくてもパフォーマンスに影響を感じたことがないプラグインだったので気になりました。

まず、誤解のないようにしておくと、前回パフォーマンス低下の欠点があるといったのは最初の投稿に添付しているFONT_RENDERING_WORKAROUND_TESTのことで、MPP_MessageEXのことではありません。

MPP_MessageEXのパフォーマンスに関しては、標準の挙動と比べるといくらか低下するとは思いますが、即座に問題視するほどではないんじゃないかという感じです。一度別の場所に描いてから転写する都合上、単純に転写の手間が増えるのと、一文字ずつバラバラに描くことでGPUへの命令送信の最適化が阻害される可能性があるので、その分時間はかかると思われます。一方で、対象がメッセージ部分に限定されているので、空間的に描画文字数は制限されますし、毎フレーム全体を再描画するようなことも起きづらく、致命的なほど負荷が増幅される状況にはなりづらいと考えられます。

なので、実際に影響が観測されてから考えればいいくらいのパフォーマンス低下かなという感想です。

piboの発言:
快適に遊べるスペックの下限はなるべく広くとりたいなぁと考えているので、導入可否の参考までに
ゲーム解像度、ざっくりと端末スペック、プラグインの有無で影響が出たと感じたシーンを教えて頂けると大変助かります…。

自分はプラグインの開発者であって、ツクールでゲーム制作をしているわけではないので、「入れてみたらゲームが遅くなった」みたいなことではないです。「仕組み上こうなるから時間がかかるだろうな」という予想ですね。

utunnelsの発言:
これはパフォーマンスに大きな影響を与えますか？
プラグインはgetImageDataを一度しか使いませんし、いずれにせよこの方法はColorManager.textColorでも使われます。

はい、プラグインが想定通りに機能しているならばパフォーマンスが低下します。

そもそもこのプラグインは、GPUアクセラレーションによる描画にバグがあるという仮定のもと、GPUアクセラレーションを無効化してそれを回避するものです。GPUアクセラレーションの無効化のためにはgetContextのwillReadFrequentlyオプションがありますが、これが実装されたのはChromium 99からなので、ツクールMZに含まれるNW.jsでは使えません。そこで、代わりにgetImageDataを使用しています。

コンテキストに対してgetImageDataを呼び出すと、ヒューリスティクスとして、そのコンテキストに対するGPUアクセラレーションを無効化するそうです（ソースコードを確認したわけではないので、正確な条件かどうかはわかりませんが……）。これはGPUでレンダリングをすると、getImageDataの呼び出し時にCPUへの書き戻しが必要になってしまい効率が悪いためです。

プラグインでは文字を描画するすべてのコンテキストに対して高々一回getImageDataを呼び出します。上記の想定通りに機能しているならば、そのコンテキストに対してはGPUアクセラレーションが無効化されるはずで、以降の描画の最適化がなされなくなるためパフォーマンスが低下します。

ColorManager.textColorの場合は読み込み専用で、ウィンドウスキンに対してしか呼び出されないので、この問題は起きません。

utunnels · 2025-02-08

なるほど、説明ありがとう。
willReadFrequentlyを試してみようと思ったのですが、うまくいかないことがわかりました。
でも幸いなことに、このゲームは毎フレームテキストを描画しないので、パフォーマンスの低下は一時的なものだ。

また、Bitmap.drawTextは十分速いので、この差は大したことではない。

pibo · 2025-02-08

fspaceさん

パフォーマンスに関する話は添付の対策プラグインのことだったんですね。
完全に読み違えていました…。失礼しました。
またMPP_MessageEXのパフォーマンスに関する知見を頂きありがとうございます。大変参考になります。

そういえば、去年初めてこのバグに遭遇したときに
問題の切り分けのためにラップトップ以外でバグを再現できないか検証していたのですが、
第9世代corei5、gtx1660のwin11デスクトップPCでも再現性があったことを思い出しました。

問題ない端末でも無理やりバグを再現する方法として一応共有しておきます。

・フォントサイズ、または画面内に表示されてる文字数とバグ発生には相関関係がある。
大体22ポイント以上だと発生率は０ですが、メッセージ内で制御文字\fs[]を使い19、18と小さくするにつれバグ発生率が上がる。
・フォントカラーの変更/c[]、メッセージ内で使用しているカラー数もおそらく関係する。
・最初は問題なく表示されても同じメッセージを何回か表示すると崩れるといった不規則性がある。

平たく言うと、文字を小さくして色を沢山変えて長文メッセージを何度も表示してるとたまに文字がブロック状に欠けるって感じです。
グラボ付きのデスクトップでも一応再現はできるけど、バグ発生までの閾値が高いから意図的に発生させない限りはまず遭遇せず。
端末スペックとバグ発生の閾値は比例しているような印象を受けました。参考までに。

utunnels · 2025-02-08

何年も前のデスクトップPCを使っていて、i5-8400とgtx1060とwin11だ。
今のところ、あなたの方法では問題を再現できないようです。
可能性が低すぎるのかもしれない。

fspace · 2025-02-10

utunnelsの発言:
でも幸いなことに、このゲームは毎フレームテキストを描画しないので、パフォーマンスの低下は一時的なものだ。

そうですね。コアスクリプトでは表示前に一回だけ描画するケースが多いので、ゲーム進行が困難なほどパフォーマンスが低下するケースは多くないかもしれません。

しかし、長大なリストを高速にスクロールする場合など、再描画が連続で発生するケースもありますし、プラグインを導入すれば問題となるケースは無数に増えますので、万人に（特に専門知識をもたない人に）勧められる方法ではないですね。

utunnelsの発言:
また、Bitmap.drawTextは十分速いので、この差は大したことではない。

画像の結果については、計測方法に問題があります。

一般に、キャンバスの2Dコンテキストの描画メソッドは、バッファに描画命令を追加するだけで、実際の描画処理は行いません。そのため、drawText（fillText/strokeText）の実行時間を計っても意味がありません。実際に、ツクールMZのNW.js(v0.48.4)でdrawTextの実行時間を計測すると、getImageDataの呼び出しの有無では実行時間は変わりません。ツクールMVのNW.js(v0.29.0)では実行時間に少し差が生じますが、それが本当に描画処理によって生じた差なのかどうかは不明です。

また、同一の文字（または文字列）を繰り返し描画する場合、以前の描画内容のキャッシュが使われている可能性があります。その場合、描画は単なる画素の転写で済むため、本来の文字描画よりもはるかに高速になります。そのため、文字描画の平均処理時間を求めたいのであれば、毎回ランダムに生成された異なる文字で構成された文字列を描画しなければなりません。（ただし、いくらか実験してみたところ、含まれる文字の種類が多いと、getImageDataを呼び出さなくてもGPUアクセラレーションが無効化されてしまうようです。）

他にも、同じコンテキストに対して連続して描画メソッドを呼び出すと、それらの描画内容間で最適化が行われてしまうことがあるため（わかりやすいのは、適当な描画メソッドを呼んだ後にclearRect(0,0,canvas.width,canvas.height)を呼ぶケースで、クリア前の描画がすべてスキップされます）、描画メソッドごとの速さを計る場合にはすべて異なるコンテキスト（キャンバス）に描いた方が正確です。また、対象のキャンバスがユーザーに対して表示されない場合、そもそも描画自体が行われないこともあります。

描画処理はかなり高度に最適化されているので、内部処理を知らずに一般化した計測コードを書いても役に立つ結果は得られないと思います。

piboの発言:
平たく言うと、文字を小さくして色を沢山変えて長文メッセージを何度も表示してるとたまに文字がブロック状に欠けるって感じです。
グラボ付きのデスクトップでも一応再現はできるけど、バグ発生までの閾値が高いから意図的に発生させない限りはまず遭遇せず。
端末スペックとバグ発生の閾値は比例しているような印象を受けました。参考までに。

テクスチャ絡みの同期の問題のようにも見えるので、すべての環境で発生する可能性はあるけど、構造的あるいはスペック的な理由で、一部のGPUにおいてのみ発生しやすい、というのはありえない話とまでは言えませんね。

ただもうこの辺りはソースコードでも読まない限りは判断できませんし、原因がわかってもプラグインから修正できる箇所ではないので、対処方法は変わりそうにないですね。

utunnels · 2025-02-10

その通りだよ、fspaceさん。
しかし、フォントサイズとテキストをランダムにすると、その差はさらに小さくなります。
実際、MVはMZより少し速い。
これは幸いにも最近のwebkitのバージョンで修正されました。

古いCPUを使用してテスト：
Intel(R) Core(TM) i3-4160 CPU @ 3.60GHz

話が逸れて申し訳ない。
テストは厳密には行われていない。興味本位なんだ。
MVのテスト中にウィンドウズのシステムフォントを使ったのが間違いだった。
実際、MZより速くはない。カスタムフォントの方が少し遅いようだ。

utunnels · 2025-03-22

こんにちは、fspaceさん。
お久しぶりです。あなたがまだ新しい情報に興味を持っているかどうか分かりません。
私は非常に小さな図形を描くことによって、同様の効果を生み出したことがあります。
私が使っているコードはこれです。

JavaScript:

function drawTest(x, y, scale, fix){
  var bitmap = new Bitmap(400,300);
  var ctx = bitmap.context;

  if(fix) ctx.getImageData(0,0,1,1);

  ctx.save();
  ctx.fillStyle = 'black';
  ctx.fillRect(0,0,bitmap.width, bitmap.height);

  ctx.beginPath()

  ctx.scale(scale,scale);

  //O
  ctx.moveTo(7,54);
  ctx.lineTo(9,54);
  ctx.lineTo(9,55);
  ctx.lineTo(6,55);
  ctx.lineTo(6,54);
  ctx.lineTo(7,54);
  ctx.moveTo(10,54);
  ctx.lineTo(9,54);
  ctx.lineTo(9,49);
  ctx.lineTo(10,49);
  ctx.lineTo(10,54);
  ctx.moveTo(6,53);
  ctx.lineTo(6,54);
  ctx.lineTo(5,54);
  ctx.lineTo(5,49);
  ctx.lineTo(6,49);
  ctx.lineTo(6,53);
  ctx.moveTo(9,48);
  ctx.lineTo(9,49);
  ctx.lineTo(6,49);
  ctx.lineTo(6,48);
  ctx.lineTo(9,48);

  ctx.translate(18,0);
  //F
  ctx.moveTo(6,55);
  ctx.lineTo(5,55);
  ctx.lineTo(5,48);
  ctx.lineTo(10,48);
  ctx.lineTo(10,49);
  ctx.lineTo(6,49);
  ctx.lineTo(6,51);
  ctx.lineTo(9,51);
  ctx.lineTo(9,52);
  ctx.lineTo(6,52);
  ctx.lineTo(6,55);

  ctx.fillStyle = 'white';
  ctx.fill();
  ctx.restore();
  var sprite = new Sprite(bitmap);
  sprite.x = x;
  sprite.y = y;
  SceneManager._scene.addChild(sprite);
}

drawTest(0,0,1,false);
drawTest(400,0,1,true);
drawTest(0,300,2,false);
drawTest(400,300,2,true);

これがその結果のスクリーンショットである。
最初の画像では、一番左の長方形が欠けているのがわかるだろう。
その右の画像はgetImageDataを使用しており、正しいことがわかります。
他の2つの画像は形が大きく、正しく表示されています。

ウィンドウズ10デスクトップ
Intel(R) Core(TM) i3-4160 CPU
NW.js v0.48.4（MZ）

その他のテスト
これらのテキストは同様の方法で表示される。
ご覧のように、同じテキストが同じ結果をもたらします。
興味深いのは、単独で表示した場合、「O」の文字の下の長方形が欠けていることだ。

fspace · 2025-03-23

報告ありがとうございます。

私の環境でも再現しましたが、テキストの問題とは別の問題かなと思います。

コード中の数値について下記の通り変更してみたところ、欠けていた部分がグラデーション状に変化しました。これはテキストでは見られなかった特徴です。

JavaScript:

ctx.moveTo(6, 53);
ctx.lineTo(6, /* 54 */ 55);
ctx.lineTo(5, /* 54 */ 55);
ctx.lineTo(5, 49);
ctx.lineTo(6, 49);
ctx.lineTo(6, 53);

おそらくパスの内外判定にバグがあり、塗りつぶされるべきピクセルが外側と判定されてしまっているんじゃないかと思います（グラデーションは何らかのアンチエイリアシングの影響かと）。

テキスト描画に限らず、getImageDataはGPU実装からCPU実装へと切り替えると推測されるため、GPUによるテキスト描画の問題に対して機能するのと同様に、GPUによるパス描画の問題の回避にも機能したんじゃないでしょうか。

utunnels · 2025-03-23

なるほどね。面白いですね。
ちなみに、最後の画像のように「O」を十分に描くと、不具合は解消される。
実は、その前に17個の長方形を描くと、不具合もなくなる。位置や大きさは関係ない。例えば、

JavaScript:

ctx.moveTo(-100,-100);
ctx.lineTo(-100,-100);
ctx.lineTo(-100,-100);
ctx.lineTo(-100,-100);
//17回繰り返す

fspace · 2025-03-23

正確な理由はわかりませんが、パスが複雑になることで、getImageDataの呼び出しと同様に、GPUアクセラレーションの適用条件を満たさなくなったのかもしれませんね。CPUのプログラムよりGPUのプログラムの方が制限が多いので。

utunnels · 2025-04-01

追加情報：
willReadFrequentlyが存在する場合、getImageDataはそれを修正できない。
前回確認したところ、nw.js v0.94にはまだこの問題がありました。

ダミーコマンドは問題を解決することができる：
for(var i=0;i<17*4;i++) ctx.moveTo(0,0);ctx.closePath();

残念ながら、テキストの問題は再現できない。

P.S.
Chromium 96(nw v0.59)ではまだこの問題がある。
しかし、Chromium 97(nw v0.60)ではすでに修正されています。

https://chromium.googlesource.com/skia/+/d9a6f66

https://chromium.googlesource.com/chromium/src/+/a1b2c3d

ドッ〇君 · 2025-09-26

最近、Windows11に変えたのですが、おそらくこの問題と同じ現象が発生するようになりました。
まだ正確な原因が不明とのことなので、解決されることを祈っています。

MZのVer.1.9.0で、プロジェクトファイルは新規ではなく、Windows10の頃に作成したファイルです。
プラグインは関係ないとのことなので、その辺のご報告は省きます。

一つのイベントで、だいたい添付画像の数くらいのフォント崩れが発生します。
こちらにありました「検証用プラグイン」を入れて、同じイベントを数回確認したところ、１度も発生しなくなりました。
一応、ご報告ということで、宜しくお願い致します。

fspace · 2026-02-15

今更ながら一応返信を……

utunnelsの発言:
追加情報：
willReadFrequentlyが存在する場合、getImageDataはそれを修正できない。
前回確認したところ、nw.js v0.94にはまだこの問題がありました。

willReadFrequentlyオプションの追加に伴いgetImageDataに関するヒューリスティクスを削除する、という話をどこかで見た気がします。プログラマが明確に意図を伝えられる手段ができたので、誤検出の可能性のあるヒューリスティクスは好ましくないということかと。

ドッ〇君の発言:
最近、Windows11に変えたのですが、おそらくこの問題と同じ現象が発生するようになりました。
まだ正確な原因が不明とのことなので、解決されることを祈っています。

MZのVer.1.9.0で、プロジェクトファイルは新規ではなく、Windows10の頃に作成したファイルです。
プラグインは関係ないとのことなので、その辺のご報告は省きます。

一つのイベントで、だいたい添付画像の数くらいのフォント崩れが発生します。
こちらにありました「検証用プラグイン」を入れて、同じイベントを数回確認したところ、１度も発生しなくなりました。
一応、ご報告ということで、宜しくお願い致します。

ご報告ありがとうございます。

残念ながらこの問題の正確な原因がわかることは今後もないと思いますし、わかってもあまり意味がない可能性が高いです。というのも、おそらく本件の原因はChromium内にあり、最新のChromiumではすでに修正されているからです。単に旧いChromiumを使っているツクールが悪いのです。

加えて、ツクール開発部はNW.jsのアップデートは難しい、つまりChromiumのアップデートもしないと言っているため、今後もツクールMZである限り問題が根本から解決されることはないと思います。コアスクリプトやプラグインからは触れない領域の問題のため、これらでパッチをあてることもできません。現状では自己責任でNW.jsを更新することが唯一の対処法です。

検証用プラグインは問題を修正しているように見えるかもしれませんが、実際には回避しようとしているだけで、常に期待通りに動作する保証はありません。また、回避に伴い別の問題を引き起こすこともあり、実用に足るものではないです。

文字の一部がブロック状に欠ける問題について

ユーザー

TL;DR​

問題の原因​

対処方法​

その他の情報​

検証への協力のお願い​

Attachments

ユーザー

ユーザー

ユーザー

ユーザー

ユーザー

ユーザー

Attachments

ユーザー

fspaceさん​

ユーザー

ユーザー

ユーザー

ユーザー

ユーザー

ユーザー

ユーザー

ユーザー

ユーザー

Attachments

ユーザー

TL;DR

問題の原因

対処方法

その他の情報

検証への協力のお願い

fspaceさん