返信

> ご無沙汰しております、ご確認いただきありがとうございます。 > ハイスペックマシンですね。これじゃスペックのせいにできません… (w > > いただいた情報をもとに検証してみましたところ、自動マーカーがオンのときに何らかのタイミングで描画が非常に遅くなる場合があることが確認できました。 > > 調査してみましたところ、以下のことがわかりました。 > > まず、1 つめ。 > ---- > カスタムフォントを使用していると、DirectWrite の描画速度は通常より遅いです。 > ---- > > そして 2 つめ。 > ---- > 自動マーカー機能がオンになっている場合、キャレットが移動するたびに画面に表示されている全行が再描画されてしまうため描画速度が遅いです。それにカスタムフォントの遅さが加わるのでさらに遅くなります。 > > 自動マーカーの [カーソル位置の単語を取得する] オプションがオンの場合は全行を再描画してマーカーを表示する必要がありますが、これがオフの場合でも全行の再描画が発動していました。 > > この部分につきましては [カーソル位置の単語を取得する] オプションがオフの場合は、通常のキャレット移動のたびに全行を再描画する必要はないと思いますので若干速度改善の余地はありそうです。 > ---- > > 状況によっては非常に遅くなることがあるという現象についてですが、これは DirectWrite の仕様によるものなので内部までは知りようがありませんが、下記のような場合に発生することがあるようです。 > > Windows では通常、 Windows Font Cache というサービスが動作しており、これはシステムキャッシュとユーザーごとのキャッシュを管理しています。 > > アプリケーションが DirectWrite の API を呼び出すときに Font Cache サービスはユーザごとのキャッシュを読み込むのですが、この時に 0.5 秒間待機 (以下、この時間切れを "タイムアウト" と呼びます) しますが、タイムアウトした場合はキャッシュを使うのを諦めて、直接フォントを読みに行くため動作速度が遅くなるそうです。 > > [KB2505438 より] > https://support.microsoft.com/ja-jp/help/2505438/slow-performance-in-applications-that-use-the-directwrite-api-on-a-com > > ここからは推測ですが… > > 通常、DirectWrite でテキストを描画するにあたって、フォントを読み込む際、最初にフォントの一覧 (フォントコレクション) を使って書式の情報を作成しますが、普通はここでシステムフォントコレクションを使用するので短時間で済みます。 > > カスタムフォントを使用した場合、ここの処理でカスタムフォントコレクションを使用するため、処理に時間がかかり 0.5 秒のタイムアウト時間を超えてしまい、キャッシュが使用されない状態になっているように思います。 > > バックグラウンドで動作しているプロセスの影響も受けますので、CPU の負荷状況によってタイムアウトが発生している可能性もあります。 > > アプリケーション側からこのタイムアウト時間を制御する方法や、Font Cache サービスを制御する方法などはないようです。 > > そういうわけでアプリケーション側でできる対応としては…。 > > (1) Font Cache サービスに頼らず、自前でキャッシュする仕組みを設ける > > 正確なことはわかりませんが Chrome ではそんなことしているような情報が… > https://www.chromium.org/developers/design-documents/directwrite-font-cache > > (2) フォントキャッシュが使われない場合でも高速に動作するように、そもそも根本的な動作速度を改善する > > 現在の Mery は GDI (DirectWrite オフ) が標準となっており、GDI と DirectWrite を共存 (適宜、切り替えて描画) させていますが、この GDI ←→ DirectWrite の切り替えが動作速度のボトルネックになっています。 > > 根本的な動作速度を改善する場合、GDI を捨てて完全に DirectWrite に移行することで大幅な速度の改善が見込めます。 > > が、XP ～ 10 まで対応、国産の昔ながらの機能を継承したテキストエディタという性質上、ビットマップフォントを切り捨てることもできず、DirectWrite だとバグのあるフォントもあったりして、完全に DirectWrite に移行するのは現状では困難です。 > > 技術的に興味深いのは (1) の作戦ですが、世界の Google 先生の技術を私が再現できる自信はありません…。 > > GDI と DirectWrite のプログラムを完全に分離して、DirectWrite 専用で動作する仕組みを構築できれば高速化できるはずなので、やるとしたら (2) の方法になると思いますが、描画ロジックの全体的な作り直しとなりますので対応には非常に時間がかかります。 > > ご不便をおかけして申し訳ございませんが、将来的に改善したい事項ということで課題とさせていただければと思います。

マークダウンを有効にする