Windows 10 Pro (1709) + Microsoft Office 2016 でウインドウをドラッグすると酷い遅延が発生する

上にも書いてますが、Surface Pro + MSO2016 でも同じ症状を確認しましたから、これ、もう、うち固有の環境の問題ではないことははっきりしています。

また、Cygwin のインストーラーで Cygwin をインストールしている最中、MSO2016 のウインドウをドラッグしたのと同じようなひどい遅延がマウスポインター単独でも発生しすることを新たに確認しました。

このため、今、一番疑っているのは、先日、報道にあった以下の不具合の影響じゃないかって事です。

「Fall Creators Update」でGetPixel/SetPixel関数が遅くなる問題 ～一部アプリの動作速度に影響

https://forest.watch.impress.co.jp/docs/news/1095865.html

自分のPCにも酷い遅延が生じていて、ずっと試行錯誤しておりました。

上記のGetPixelが遅くなる減少・・・は更新プログラムで解消とありましたが、

この減少は改善されませんでした。

ひとつ気づいたのですが、ゲーミングマウス使用していないですか？

Logicoolのゲーミングマウス使用で、マウスのレポートレートを250にすると、遅延がなくなりました。

レポートレート500でも遅延が発生するが、250以下にすると遅延がなくなります。

通常のマウスではレポートレート100~150程位なので、この遅延が発生しないと思います。

今はLogicoolのゲームソフトウェアでExcel使用時のみレポートレート250で解消しておりますが、

Excel2010、他ソフトではこのようなドラッグ遅延が発生しない為、

Office固有の問題だと認識しております。

一刻も早く改善を望みたいですね。

返信が遅くなり申し訳ありません。
この件について、本日ようやく確認が取れましたので報告致します。

結論から言いますと、お見事です。
うちのケースでも、まさにご指摘のゲーミングマウスにおけるレポートレートがこの現象を発生させるための鍵でした。

まず、うちのマウスですが、
Logicool G300
http://support.logicool.co.jp/ja_jp/product/gaming-mouse-g300/specs
を使っております。
Windows 7 では、問題なかったんですけど、どうもこれが引き金を引いていたようです。

チャタリングで使い物にならなくなったため死蔵していた IMO (Microsoft InteliMouse Optical) を引っ張り出してきて交換してみたところ、劇的に遅延が改善しました。まるで嘘のようです。

ただし、Excel のウインドウは他のウインドウ、例えば Firefox のウインドウ等と比べるとドラッグしたときの動きに若干ガタガタとした感じが発生する場合があり、何かの拍子に若干の遅延が認識される場合もありました。
ひょっとすると、Microsoft Office 2016 ではウインドウの描画に用いている API がこれまでの通常のアプリとは異なるのかもしれません。

試しに Let's note CF-RZ5 にも G300 を繋いで試してみましたが、不思議なことにこちらでは遅延は見られませんでした。しかしタスクマネージャーを眺めて見ると、少し原因に関係しそうなふるまいが見られました。Excel のウインドウをドラッグした際の CPU 負荷が明らかに違うんです。
IMO やタッチパッドを用いてドラッグした場合と G300 でドラッグした場合では、ノートでもデスクトップでも G300 の方が明らかに負荷が大きく現れます。
遅延が発生しているデスクトップでは、ドラッグを続けると、CPU 負荷がどんどん増える傾向が見られて、負荷があるところで頭打ちすると遅延がスッとなくなる現象が見られます。
CF-RZ5 は CPU が Core m5-6Y54 なので相当に非力なのでしょう。Excel のウインドウをドラッグするといきなり CPU 負荷が 100% に達してしまっています。それが原因で遅延の発生が確認できてない可能性がありそうです。

さて、G300 はプロファイルを 3 つ持てるのですが、上記のサポートページの「はじめに」にある「入門ガイド」を見ると、標準では、MMO (赤)、FPS (緑)、Productivity (青) の 3 種類の目的で設定されており、レポートレートはそれぞれ 500、1,000、500 レポート/秒に設定されていると説明されていました。

レポートレートは Logicool Game Software で変更する以外に方法がないようなので、これを機会に、上記サポートページの「ダウンロード」から拾って来て入れてみました。
設定可能な値は 125、250、500、1,000 の 4 種類で、このうちいずれかの値を各プロファイルに一つだけ登録できます。

うちで問題が発生しているデスクトプ PC の環境では 1,000、500 はもちろん 250 ではまだ顕著な遅延が解消できず 125 まで下げるとようやく遅延が解消できました。

Surface Pro のタッチパネルもひょっとすると、レポートレートが通常のマウスよりも高いのかもしれませんね。

大変、有益な情報をありがとうございました。

さて、マウスのレポートレートがこの問題を引き起こしていることは分かりましたが、この問題の本質は、ウインドウの再描画処理におけるイベントの消化方法、つまりはキューに入っているイベントを一つ残らず処理している事に原因があることは明らかです。
Cygwin のインストール時に、ウインドウの描画ではなく、マウスカーソルの移動自体にも遅延が見られましたので、こちらにも合わせて問題がありそうです。

本フォーラムでサポート業務をされている Microsoft の方は、是非ともこの情報を開発チームに取り次いで頂きたいと思います。
Microsoft の開発チームの方々におかれましては、この情報を参考に、原因の調査と不具合の修正に取り組んで頂けますと助かります。

以上、よろしくお願い致します。

ここは要望などを受け付けるサイトではありませんので、投稿によって何かしてもらえることはありません。

Windows 10 のフィードバックは下記を参考にしてください。こちらは開発部署に直接届くと思います。

https://support.microsoft.com/ja-jp/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app

ありがとうございます。

既に「フィードバックHub」には今回の投稿以前の段階で、こちらのスレッドを報告済みですよ。

• 特定のアプリケーションにおいて、ウインドウをドラッグすると描画に極めてに重大な遅延が生じる

しかし何も音沙汰がありません。開発チームの目に触れているのかどうかさえ怪しいものです。

自社の看板商品である Surface Pro でも発生する問題であると報告しているにも関わらずですよ。

しかも、UWP アプリである「フィードバック Hub」のみからしか投稿も閲覧も出来ない閉じたシステムですし、一応各フィードバックの右上にある「共有」からURLは得られるもの、それも「フィードバック Hub」で開くためのリンクに過ぎず、通常のブラウザはもちろん Google や Bing 等の検索からも隔絶した極めて閉鎖的かつ非効率な報告システムであると断ぜざるを得ません。

はじめから「フィードバックHub」だけで済ませていたら、本件において極めて重要な意味を持つであろう Applemoca  さんからのコメントも、得られていたかどうか怪しい物です。

開発チームやサポートチームとしての優先順位があるのは充分に理解しますが、はっきり言って、あれが末端ユーザーの不具合を解決するために役に立つとは到底思えないですね。

検索出来ないのが深刻なセキュリティホールの報告があった場合に備えての安全措置だと好意的に解釈したとしても、「フィードバック Hub」アプリからは検索できるんですから通常のwebから隔絶させる意味が全く分かりません。

他にも、「フィードバックHub」は1000文字制限があったりと、あれは到底まともに不具合を報告できるようなシステムではないと思います。

しかし、少なくともここは、多くの人の目に触れ、検索にも引っかかると共に、Microsoft Suppot と肩書付きでコメントしてくださる Microsoft のスタッフの方がいらっしゃるわけです。その点で言えば、ここは「フィードバックHub」の100倍、いや1000倍くらいマシでしょう。しかし、仮にも Microsoft の中の方なわけですから、ここまで詳細に不具合の状況と原因が特定できた案件については、エスカレーションして頂けても罰は当たらないと思うんですね。Microsoft のバッジは飾りで付けてるわけじゃないんですから、そこいらのパソコンに詳しいお兄ちゃんの「こうすればうまく解決できるかもしれませんよ」的な不確かなアドバイスではなく「こんな不具合があって、原因はこういうことだとほぼ確定したようですよ」と開発に取り次いでくれることを期待することがそんなに悪いことでしょうか？

そこいらのパソコンに詳しいお兄ちゃんではできないこと、すなわち、Microsoft の中の人として開発部隊に必要な情報を効率的に届けることこそが、このコミュニティーにおいて我々一般のユーザーが成し得ない、彼らがだけが成し得る極めて価値のあるサポート行動であると信じて止まないわけですが、私は何か間違ったことを言っていますでしょうか？

補足しておきますが、Google の短縮 URL サービスを使って、このスレッドを報告しているので、「フィードバックHub」への報告が閲覧された結果、このスレッドが参照されたかどうかは、アクセス統計として見えるんですけど、その結果が 3 click なのですから、まぁ、見られてるとは思えないです。これは私が自分でクリックした分でしょ？

優先順位の問題で対応してもらえないのは仕方がないとしても、せめて BTS(But Tracking System)には登録してチケットくらいは切ってくださいと、言い換えると、そういうバグがあるということくらいは認識してくださいと思うわけです。しかし「フィードバックHub」への報告ではそれもままならない状況と言えるわけですよ。まるで役に立ちません。

コミュニティの規約に触れているわけではないので、ここに書くのは自由ですが、

上で書いた通りここに書いても開発者は外部サイトまで見ないし、意味ないってことでしょう。

そもそも日本で開発してないですからね。英語で書いた方が確率は上がるのと、あとは投票数次第かと。

このスレッドみても、同じことが知りたいは 5 しかないので影響度は少ないと判断されても仕方ないです。

影響度の高い問題が起きれば軽く 1000 は超えますし。

だからこそ、Microsoft Support の方を名指してお願いしているんじゃないですか。

彼らはここをかなり高い確率で見てくださってますし、2ch や Yahoo! 知恵袋でも聞ける話を公式の立場でされるためにここを見ておられるわけではないはずなのですが？

にも関わらず、ここで Microsoft Support の方にお願いする事がそんなにも意味のない事だとおっしゃるのであれば、それはここに Microsoft Support の方がいる事そのものが無駄だと言っているに等しいのではありませんか？

英語で報告する事自体の意義には賛同しますが、そもそも「フィードバックHub」は日本語版で英語使わせる気があるようにも思えないですけどね。

「フィードバックHub」で「delay」とか「drag」とか単語レベルで検索した場合ですら1件すら引っかからないですもの。日本語なら引っかかるのに。

そのくせなぜか「フィードバックHub」の「ホーム」にだけは英文のお知らせが並ぶというコレジャナイ感。

UWP アプリで URL すら表示されませんから外面の挙動からは全く見当もつきませんが、これ下手をすると英語版と日本語版でデータのストア先が違ってる可能性すらあって、日本語版から英語で書いたとしても本社開発スタッフの目に留まる望みはないと思います。

> それはここに Microsoft Support の方がいる事そのものが無駄だと言っているに等しいのではありませんか？

サポートエンジニアや（英語版以外だとほぼ居ないけど）開発チームの人がフォーラムを見るのはなにも質問に回答するだけでなく、どのようの傾向の質問が多いのか、どのような解決策が求められているのはを把握するだけでも十分に意味はありますよ。

そういう情報取集は価値があるでしょうが、個々の質問に対応するのは彼らの fee からしたら見合わない作業なのでしょう。

どうしても Microsoft のエンジニアに対応してもらいたければ、有償サポート（個人向けではなく企業向け）を利用してください。また日本語のフォーラムより英語版のフォーラムの方が、開発チームのエンジニアなどに目に留まったり、コメントを付けたりされる場合がありますのでご参考まで。