現在、C++Builderを使用してアナログデータの収集と波形の描画するアプリを作成しいます。USBから取得したアナログデータをメモリに書き溜めて先頭からForm画面に配置したTImageにCanvasで描画するところまではできたのですが、データの収集速度と描画の速度がどうしても合わなくてリアルタイムとは言えない状態になっています。(明らかに描画の速度が遅いと思われます。)やりたいこととしてはスタートボタン押下で、データの取集は開始して別のタスクにて常にデータをメモリに溜め込む(1秒1000サンプル)処理を開始。その後、別タスクにてメモリに溜まったデータを常に描画する処理を行っています。この時、描画がカクつかないように描画のループ中に定期的にTImageをUpdate()して画面に反映させています。描画が早すぎるとデータ収集が追い付かずに描画可能データが無くなりカクついてしまい遅いとリアルタイムで無くなってしまい困っています。1秒間のデータをきっちり1秒間で描画出来るようにしたいです。(現在だと0.8秒くらいなのでドンドン遅れていきます。C++Builder10.2を使用しています。VB、C#、.netでの開発経験はあるのですがC++は初めてで色々と手こずっております。VisualStudioもあるので、対応方法があればBuilderに限らず教えて頂ければと存じます。データ収集にはNI社のNI-Daqmxを使用しています。掲示板に相談するのは初めてなので何か粗相や足りない情報があれば仰ってください。NI社のソフトウェアのサンプルに山ほどあると思います。提示頂ければと思います。インストールされています。似ている部分が多いのです。2000万行ほどで書き換えられました(VS2015の時)。C#に移行しているようです。1年前Mathさんご返信有難うございます。確かに抽象的過ぎて申し訳ございません。NI社のホームページ等やネット上にも確かにサンプルたくさんあるのですがどれも1秒間隔とかTimerを使い一定間隔のデータを全て描画処理してから画面に反映させる物ばかりでカクカクとした動きでプロットしていくものばかりでした。回数によって描画速度が変わってしまうのでスペックの問題になってしまうと思うのですが、スペックに関係なく一定の速さで描画する方法を探しております。(古いOSとかメモリ2Gとか低すぎる環境では多少仕方ないとは思いますが・・・)例えば、高すぎるスペック動かしたら1秒分の処理が0.5秒で終わり、次のデータが溜まるまで待つとカクカクした描画になってしまうし低すぎるスペックだと、カクカクしないけど、1秒分のデータ描画するのに1.2秒かかったら毎秒0.2秒ずつ遅れていき10秒後には2秒前のデータを描画している事になってしまうのでそれを避けたいと言う事です。(現在、これの状態です。)オシロスコープやPicoスコープの様な製品だとスペックに関係なく時間通り動いていると思うので、恐らく上記での方法は間違っているのかなと思いどういう仕組みで作れば正解なのかと方法を探しています。私も最初にVSのC++MFCで試していたのですがC言語したい触ったことが無かったので理解に苦しんでいたところ、C++Builderに出会ってC#っぽいのと画面デザインの作りやすさに感動しています。1年前それなら方法がありますが今から出かけるので夕方帰ってからにします。1年前Mathさんご確認ありがとうございます。ご回答お待ちしております。アプリケーションのサンプルを実行して見ています。具体的なコードを見せて下さい。1年前Mathさんご連絡ありがとうございます。下記のコードはC++Builderのスレッドオブジェクトを追加してThread.cppに記載してます。メイン処理からデータ取得のタスクを動かした後に「MyThread::Execute()」を実行してMainFrm内に配置したTImageに対してメイン画面のStopボタンが押されるまで描画しています。最大8chまで描画可能の予定ですが現在テスト段階なので2chまでしか表示しないようにしています。罫線などはメイン側に記載のDrawingArea();で描画させています。画像ギャラリーのエラーで画像取り込めないので、とりあえずコードのみ記載します。お手数ですがご確認をよろしくお願い致します。右端まで行ったら次ページとして先頭にカーソルを戻す。縦横の罫線を再描画する。メソッド経由で行わなければならない。1年前ダブルバファリングをしてflipするタイミングを固定値に制御(fps)すればよいと思ったのですがここで答えるような問題ではなくNI社に聞けば直ぐにわかると思いますよ。問題だけどこのような専門的な内容はここでは不向きだと思いますよ。1年前Mathさんご確認ありがとうございました。NI社の方にも質問はしているのですがあそこの場合、開発言語を知っている方が少なく、言語の技術的な質問の場合、殆ど解決できず最終的にLabViewを進められると言う悲しい事になるのであまり期待していません。アニメーションとかバッファリングも調べては見たのですが、やはりそれだけで解決できなそうですね。今は高精度タイマ(QueryPerformanceFrequency)とか使って何とかできないか考えているのですがいい案が浮かんでこなくて投稿してみました><初投稿なので無反応だったらどうしようと思っていましたので、回答していただけでも嬉しかったのでありがとうございます。何かいい案が浮かびましたら教えて頂けると幸いです。1年前そうでしたか、了解です。1年前オフトピックわたしの得意分野かと思ったのですが、回答するのが憚られる流れですな。最近ここに来るの不定期だし、Builder使ったことないので具体的な回答はできそうにないし。1年前あ、違ったいい方法があったら教えてあげてください。このかたはBuilderでなくてもVisualStudioでもいいそうなので。1年前キョウ太郎さんISLeさんはゲームのプログラムのプロでFPS制御には詳しいかたなので問題点をなんでも聞いて見てください。1年前ISLeさんコメントありがとうございます。基本はVisualStudioを使って開発をしていますし今回の問題は考え方の問題なのかと思っているので。言語の縛りなく教えて頂けると助かります。いま問題視しているのは描画の速度と実時間の誤差をなるべくスペックに左右されないで動かす方法です。前に書いた内容と同じですが************************************例えば、高すぎるスペック動かしたら1秒分の処理が0.5秒で終わり、次のデータが溜まるまで待つとカクカクした描画になってしまうし低すぎるスペックだと、カクカクしないけど、1秒分のデータ描画するのに1.2秒かかったら毎秒0.2秒ずつ遅れていき10秒後には2秒前のデータを描画している事になってしまうのでそれを避けたいと言う事です。(現在、これの状態です。何か方法あれば、些細なことでも良いのでご指南頂けると幸いです。Mathさん気づくの遅くなり申し訳ございません。コメントありがとうございました。1年前usaoさんご確認ありがとうございます。(1)描画が測定より早い場合に,毎測定ごとにデータ描画して更新するよりも「カクカク」しない描画の仕方って何だろう?⇒データ取得のタスク開始→描画処理のタスクを開始するの順に別々のタスクを順番に開始するので取得データと描画開始までのタイムラグがあるのはいいのですがこのEXEを動かす端末によって描画時の速度が変わってしまうのを防ぎたいです。メモリ16GBこの環境だと恐らく描画が早すぎて(1秒分のデータを描くのに0.9秒位)で処理されてしまう為、次の描画データが溜まるまで描画処理が止まってしまう現象が起きています。(2)表示が遅れる場合:⇒こちらはデータ取得では特に遅延無いので、描画のループ処理で上記のスペック差での問題があると思っています。画面に表示するタイミングを人が認識できる速度で画面更新しているつもりですがこの画面更新回数で描画速度が変化しているので、この回数を端末のスペック毎に動的に出来れば良いのか?もしくは根本的にこのようなアプリを作る場合の作法が違うのか?と言うところで悩んでおります。タスクマネージャーのCPU使用率の様に1秒間隔で画面更新するなら問題なく作れるのですが(人が認識できるレベルで)流れるような常に描画されるようなプログラムを目指しております。1年前(1)1秒分のデータ(1000サンプル分)をループ中に10回に1回画面に反映させています。待機するとカクカクするかと考えていましたが、描画が早い場合には画面反映させるタイミングを計算して調整すればイケるかもですね。(2)表示は回数増やしても対応できているっぽいので恐らく描画処理の速度によるものだと思っています。確かに描画が遅いのなら処理効率を上げるか処理数を減らすしかないですよね。間引くのは最後の手段に考えているのでまずは(1)と処理効率を精査してみます。1年前わたしなら・データ受信処理は、データの受信だけして描画に必要なデータを溜めておく・描画処理は、タイマーイベントで定期的に呼び出し、(タイマーの間隔は信用できないので)実際の経過時間を取得して描画範囲を求め、描画というふうにします。描画に時間が掛かれば、1回あたりの描画範囲が広がるわけです。ウィンドウズはリアルタイムOSではないので、常に一定の間隔とか、ちょうどぴったりとかはできません。できるだけ近づけることはできます。デスクトップを操作したりとか、バックグラウンドで何か処理が動いたりとかで、プログラムの動作にかかる負荷が変わることがあります。タイミングは実行中も常に変動するものとして考える必要があります。1年前usaoさんISLeさんコメントありがとうございます。確かに同じ端末でも裏で何か動いていれば負荷も変わってくるから一定時間で動作させるっていうのは無理がありますね。自己満かもですが、端末枚の設定調整とか付加してみて経過時間を取得しながら描画速度の調整して実時間に近づける方向で考えてみたいと思います。良い感じにできたら改めて報告させて頂きます。10ではデスクトップの描画の仕組みが違います。新しいOSほど最適化が進んで自動的に無駄が省かれるようになっていきます。1000サンプリングを10回に1回描画というと100Hz(fps)なので、モニタの周波数が60Hzであれば、モニタに映らないフレームがあります。10は、映らないフレームをデスクトップに反映することをしません。したら、それが描画速度の差に表れているのかもしれません。10で同様の動作になるかもしれません。アプリケーション側でどうにかして処理を一定間隔にしようというのは、いくら考えても無理です。やろうとすれば対象のプログラムを動かす環境すべてに対して個々の対応が必要となります。それくらいなら、頑張ればなんとかなるかもしれません。それだけでなく、そのプログラムを動かす環境が、未来で変化することも想定しなくてはいけません。Windows10でデスクトップ描画の最適化が行われたように、OSアップグレードで変わるかもしれませんし、モニタなど周辺機器の換装で変わるかもしれません。わたしには、未来を見通す力がないので、現状できることを精一杯頑張っています。1.の呼び出しタイミングは指定した通りにはいかないので、改めて現在時刻を取得して変化分を処理するというのがわたしの方針です。自分(アプリ)が時間を決めて相手(システム)に押し付けるのではなく、あくまで相手の都合に合わせ、そこで何が自分にできるかを考える、というものです。この方針であれば、Windows95の時代に作ったプログラムでも、いまだ環境に影響されず、どんどん速くなったりどんどん遅くなったりすることもなく、滑らかに動きます。オマケとして、環境が良くなると、自動的により滑らかに動くようになったりします。選択肢もありではないでしょうか。高度な技術にも対応できます。C#に吸収されたような感じです。1年前ISLeさん確認遅くなり申し訳ございません。現在、データの受信部を含め全体を見直しています。調べた結果、確かに一定間隔で処理を呼出&微調整が現実的に思いました。分かりやすい内容でご教授頂きありがとうございます。MathさんDirectXはC#でこの対応をしていた時に描画が重く感じられた為、除外してしまってました。(今考えるとC#が原因でした。)OpenGLは使ったことなかったので勉強してみます。データをやり取りしながら描画するサンプルも作りりました。DirectXをベースにしていて表示が綺麗ですね。あ、C#は除外でしたか。DxLibから始めたほうがいいです。ここhttps://dixq.net/g/の内容は数日でマスターできるでしょう。ビルド&RUNができる。DXライブラリーを開発・管理されている方の掲示板がありますかなり専門的な質問に丁寧に答えてくださいます。https://dxlib.xsrv.jp/dxinfo.htmlにDXライブラリの主な特徴を以下に記します。これは大抵の同種のライブラリでも同じだと思います。WindowsAPI云々などとは99%無縁の環境でゲームプログラムが出来ます。)』といったものを意識せずにプログラムを組むことができます。このライブラリで通用する率が高いということです。知識と技能を再構築しなくてはならなくなるという事態に陥ります。1年前[参考]必要があってDXライブラリーを使ったプログラムをTEXTファイル形式で行えるように設定してみました。デバッグ用などに生成する方法を記す。