アナログデータのリアルタイム描画

フォーラム(掲示板)ルール
フォーラム(掲示板)ルールはこちら  ※コードを貼り付ける場合は [code][/code] で囲って下さい。詳しくはこちら
キョウ太郎

アナログデータのリアルタイム描画

#1

投稿記事 by キョウ太郎 » 6日前

はじめまして。
キョウ太郎です。

現在、C++Builderを使用してアナログデータの収集と波形の描画するアプリを作成しいます。
USBから取得したアナログデータをメモリに書き溜めて
先頭からForm画面に配置したTImageにCanvasで描画するところまではできたのですが、
データの収集速度と描画の速度がどうしても合わなくてリアルタイムとは言えない状態になっています。
(明らかに描画の速度が遅いと思われます。)
やりたいこととしてはスタートボタン押下で、データの取集は開始して別のタスクにて常にデータをメモリに溜め込む(1秒1000サンプル)処理を開始。
その後、別タスクにてメモリに溜まったデータを常に描画する処理を行っています。
この時、描画がカクつかないように描画のループ中に定期的にTImageをUpdate()して画面に反映させています。

描画が早すぎるとデータ収集が追い付かずに描画可能データが無くなりカクついてしまい
遅いとリアルタイムで無くなってしまい困っています。
1秒間のデータをきっちり1秒間で描画出来るようにしたいです。
(現在だと0.8秒くらいなのでドンドン遅れていきます。)

この掲示板や色んなサイトからリフレッシュレートや1秒間に視認できる回数など確認したのですが
これは視認回数Update()の回数で調整するべきなのか?
それとも何らかのタイマー関数を使用して時間を計算して書かせるべきなのでしょうか?

開発環境はWindows7の C++Builder10.2を使用しています。
主にVB、C#、.netでの開発経験はあるのですがC++は初めてで色々と手こずっております。
VisualStudioもあるので、対応方法があればBuilderに限らず教えて頂ければと存じます。

データ収集にはNI社のNI-Daqmxを使用しています。

掲示板に相談するのは初めてなので何か粗相や足りない情報があれば仰ってください。
よろしくお願いいたします。

Math

Re: アナログデータのリアルタイム描画

#2

投稿記事 by Math » 6日前

キョウ太郎さん 全体的話が抽象的過ぎてよく見えないのですが

”USBから取得したアナログデータをメモリに書き溜めて先頭からForm画面に配置したTImageにCanvasで描画するところまでは”

は NI社のソフトウェアのサンプルに山ほどあると思います。

具体的に問題点を絞ってC++Bulderの プログラムを 検証できる形にして 提示頂ければと思います。

(私のPCには C++Bulder10.3 がインストールされています。)

(基本的にはPCのスペックの問題のように思いますが?)

Math

Re: アナログデータのリアルタイム描画

#3

投稿記事 by Math » 6日前

C++Bulder は Delphi のC++版であり C# はDelphi の開発チームがボーランドからMicrosoft に移籍

して開発したものなので 似ています。 C#  はDelphi に 似ている部分が多いのです。

https://ja.wikipedia.org/wiki/%E3%82%A2 ... C%E3%82%B0

VB も アンダース・ヘルスバーグによって C# 風に 2000万行ほどで書き換えられました(VS2015の時)。

Math

Re: アナログデータのリアルタイム描画

#4

投稿記事 by Math » 6日前

C++Buider は C# とは双子のような 関係で RAD のできる 唯一の C++ になっています。

VS のCLI/CLR はもうメンテナンスされてないようで C#に移行しているようです。私は VS のCLI/CLR を勉強
したのですが。

キョウ太郎

Re: アナログデータのリアルタイム描画

#5

投稿記事 by キョウ太郎 » 6日前

Mathさん

ご返信有難うございます。
確かに抽象的過ぎて申し訳ございません。

NI社のホームページ等やネット上にも確かにサンプルたくさんあるのですが
どれも1秒間隔とかTimerを使い一定間隔のデータを全て描画処理してから画面に反映させる物ばかりでカクカクとした動きでプロットしていくものばかりでした。

私がやりたい内容としては滑らかにほぼリアルタイムで流れる波形を表示するもので
現在、1秒分のデータ(1000サンプル)をループ処理中に10回に1回程度Update() で画面に反映する事で滑らかに表示させているのですが、この場合ループ処理の重さやUpdate() 回数によって描画速度が変わってしまうのでスペックの問題になってしまうと思うのですが、スペックに関係なく一定の速さで描画する方法を探しております。
(古いOSとかメモリ2Gとか低すぎる環境では多少仕方ないとは思いますが・・・)

例えば、高すぎるスペック動かしたら1秒分の処理が0.5秒で終わり、次のデータが溜まるまで待つとカクカクした描画になってしまうし
低すぎるスペックだと、カクカクしないけど、1秒分のデータ描画するのに1.2秒かかったら毎秒0.2秒ずつ遅れていき10秒後には2秒前のデータを描画している事になってしまうのでそれを避けたいと言う事です。
(現在、これの状態です。)

オシロスコープやPicoスコープの様な製品だとスペックに関係なく時間通り動いていると思うので、恐らく上記での方法は間違っているのかなと思い
どういう仕組みで作れば正解なのかと方法を探しています。


私も最初にVSのC++MFCで試していたのですが
C言語したい触ったことが無かったので理解に苦しんでいたところ、C++Builderに出会ってC#っぽいのと画面デザインの作りやすさに感動しています。

Math

Re: アナログデータのリアルタイム描画

#6

投稿記事 by Math » 6日前

それなら方法がありますが今から出かけるので夕方帰ってからにします。

キョウ太郎

Re: アナログデータのリアルタイム描画

#7

投稿記事 by キョウ太郎 » 6日前

Mathさん

ご確認ありがとうございます。
ご回答お待ちしております。

Math

Re: アナログデータのリアルタイム描画

#8

投稿記事 by Math » 5日前

http://www2.koyoen.birdview.co.jp/~abcx ... X-001-.PNG

今 C++Bulder Windows VCL アプリケーションのサンプルを実行して見ています。

キョウ太郎さん の具体的なコードを見せて下さい。

キョウ太郎
記事: 5
登録日時: 5日前

Re: アナログデータのリアルタイム描画

#9

投稿記事 by キョウ太郎 » 5日前

Mathさん

ご連絡ありがとうございます。

下記のコードはC++Builderのスレッドオブジェクトを追加してThread.cppに記載してます。
メイン処理からデータ取得のタスクを動かした後に「MyThread::Execute()」を実行して
MainFrm内に配置したTImageに対してメイン画面のStopボタンが押されるまで描画しています。

※ 最大8chまで描画可能の予定ですが現在テスト段階なので2chまでしか表示しないようにしています。
 罫線などはメイン側に記載のDrawingArea();で描画させています。
実際の描画画面も見て頂きたかったのですが、
画像ギャラリーのエラーで画像取り込めないので、とりあえずコードのみ記載します。

お手数ですがご確認をよろしくお願い致します。

コード:

// マルチスレッド中の描画処理
void __fastcall MyThread::UpdateDrawing()
{
    Application->ProcessMessages();

	// 描画領域のY軸幅を計算
	haba = DrawHeightY2 / 20;
	haba = haba *10;        //小数点切り捨てられてるので戻さないと罫線とずれる
 // 	MainFrame->TImgBG->Canvas->Pen->Color = clRed;


	Ypoint0 = (DrawHeightY + haba);
	Xpoint0 = DrawLeftX;
	x = 0;

	haba = DrawLeftX2 - DrawLeftX;
	// 描画領域のX軸幅を計算
	ms = haba / 10000;
	// ten = 0;

	// データ取得
	// 共有メモリ(メモリマップトファイル)を開く
	HANDLE hMapping = OpenFileMapping(FILE_MAP_READ, FALSE, L"NI-Data_test");
	if ( hMapping == NULL ) {
		ShowMessage("共有メモリが見つかりません");
		return;
	}
	// マッピング開始
	char *dat = (char *)MapViewOfFile(hMapping,
					FILE_MAP_READ,	// 読込モード
					0,
					0,
					0);		// 上限まで読込
	if ( dat == NULL ) {
		ShowMessage("共有メモリのデータがありません");
		return;
	}

	// データ読込
	AnsiString ebuff = AnsiString(dat);

	// マッピング解除
	UnmapViewOfFile(dat);

	//int cnt = 1;

	//int gou2 = 1000 * Tspan;
	int gou2 = 1000 * MainFrame->Tspan * MainFrame->pages;

	//gou = 0;

	 //カンマ区切りの文字列
	//結果格納用のTStringListを用意
	TStringList* splittedResult = new TStringList();
	//CommaTextプロパティにセット
	splittedResult->CommaText = ebuff;


	for(int i= DataCnt; i < splittedResult->Count-1; i++)
	{
		switch(chCnt)
		{
		  case 1:
			x2 = x2 + ms;

			// ten1_1 = (array[DataCnt].ToDouble() * -10.0 )  * MainFrame->correctValue;
			ten1_1 = (splittedResult->Strings[DataCnt].ToDouble() * -10.0 )  * MainFrame->correctValue;
			MainFrame->TImgBG->Canvas->Pen->Color = clRed;
			// TImgBG->Canvas->MoveTo(Xpoint0 + x, Ypoint0 + (ten1 * Vspan));
			MainFrame->TImgBG->Canvas->MoveTo(Xpoint0 + X_time, Ypoint0 + (ten1 * MainFrame->V_valueUP));
			MainFrame->TImgBG->Canvas->LineTo(Xpoint0 + x2*(10.0/MainFrame->Tspan), Ypoint0 + (ten1_1 * MainFrame->V_valueUP));
			chCnt = 2;

			ten1 = ten1_1;
			break;
		  case 2:
			// ten2_1 = (array[DataCnt].ToDouble() * -10.0 )  * MainFrame->correctValue;
			ten2_1 = (splittedResult->Strings[DataCnt].ToDouble() * -10.0 )  * MainFrame->correctValue;
			MainFrame->TImgBG->Canvas->Pen->Color = TColor("$001763FF");
			// TImgBG->Canvas->MoveTo(Xpoint0 + x, Ypoint0 + (ten2 * Vspan));
			MainFrame->TImgBG->Canvas->MoveTo(Xpoint0 + X_time, Ypoint0 + (ten2 * MainFrame->V_valueUP));
			MainFrame->TImgBG->Canvas->LineTo(Xpoint0 + x2*(10.0/MainFrame->Tspan), Ypoint0 + (ten2_1 * MainFrame->V_valueUP));
			chCnt = 1;

			ten2 = ten2_1;
            gou = gou + ms;
			//x = x2*(10.0/Tspan);
			X_time = x2*(10.0/MainFrame->Tspan);


			//  右端まで行ったら次ページとして先頭にカーソルを戻す。
			if ((MainFrame->TImgBG->Width) < gou * (10 / MainFrame->Tspan) )
			{

                Sleep(50);
				MainFrame->pages = MainFrame->pages + 1;
				gou = 0;
				X_time = 1;
				x2 = 1;
				// 縦横の罫線を再描画する。
				MainFrame->TImgBG->Picture = NULL;
				MainFrame->DrawingArea();
			}

			break;
		  case 3:
  //			ten3_1 = array[DataCnt].ToDouble() * -10.0 ;
			MainFrame->TImgBG->Canvas->Pen->Color = TColor("$$00800040");;
			// TImgBG->Canvas->MoveTo(Xpoint0 + x, Ypoint0 + (ten3 * Vspan));
			MainFrame->TImgBG->Canvas->MoveTo(Xpoint0 + X_time, Ypoint0 + (ten3 * MainFrame->Vspan));
			MainFrame->TImgBG->Canvas->LineTo(Xpoint0 + x2*(10.0/MainFrame->Tspan), Ypoint0 + (ten3_1 * MainFrame->Vspan));
			chCnt = 4;

			ten3 = ten3_1;
			break;
		  case 4:
  //			ten4_1 = array[DataCnt].ToDouble() * -10.0 ;
			MainFrame->TImgBG->Canvas->Pen->Color = TColor("$clBlue");;
			// TImgBG->Canvas->MoveTo(Xpoint0 + x, Ypoint0 + (ten4 * Vspan));
			MainFrame->TImgBG->Canvas->MoveTo(Xpoint0 + X_time, Ypoint0 + (ten4 * MainFrame->Vspan));
			MainFrame->TImgBG->Canvas->LineTo(Xpoint0 + x2*(10.0/MainFrame->Tspan), Ypoint0 + (ten4_1 * MainFrame->Vspan));
			chCnt = 5;

			ten4 = ten4_1;
			break;
		  case 5:
  //			ten5_1 = array[DataCnt].ToDouble() * -10.0 ;
			MainFrame->TImgBG->Canvas->Pen->Color = TColor("$$00FF8000");;
			// TImgBG->Canvas->MoveTo(Xpoint0 + x, Ypoint0 + (ten5 * Vspan));
			MainFrame->TImgBG->Canvas->MoveTo(Xpoint0 + X_time, Ypoint0 + (ten5 * MainFrame->Vspan));
			MainFrame->TImgBG->Canvas->LineTo(Xpoint0 + x2*(10.0/MainFrame->Tspan), Ypoint0 + (ten5_1 * MainFrame->Vspan));
			chCnt = 6;

			ten5 = ten5_1;
			break;
		  case 6:
  //			ten6_1 = array[DataCnt].ToDouble() * -10.0 ;
			MainFrame->TImgBG->Canvas->Pen->Color = TColor("$$00408000");;
			// TImgBG->Canvas->MoveTo(Xpoint0 + x, Ypoint0 + (ten6 * Vspan));
			MainFrame->TImgBG->Canvas->MoveTo(Xpoint0 + X_time, Ypoint0 + (ten6 * MainFrame->Vspan));
			MainFrame->TImgBG->Canvas->LineTo(Xpoint0 + x2*(10.0/MainFrame->Tspan), Ypoint0 + (ten6_1 * MainFrame->Vspan));
			chCnt = 7;

			ten6 = ten6_1;
			break;
		  case 7:
  //			ten7_1 = array[DataCnt].ToDouble() * -10.0 ;
			MainFrame->TImgBG->Canvas->Pen->Color = TColor("$$0040FF00");;
			// TImgBG->Canvas->MoveTo(Xpoint0 + x, Ypoint0 + (ten7 * Vspan));
			MainFrame->TImgBG->Canvas->MoveTo(Xpoint0 + X_time, Ypoint0 + (ten7 * MainFrame->Vspan));
			MainFrame->TImgBG->Canvas->LineTo(Xpoint0 + x2*(10.0/MainFrame->Tspan), Ypoint0 + (ten7_1 * MainFrame->Vspan));
			chCnt = 8;

			ten7 = ten7_1;
			break;
		  case 8:
  //			ten8_1 = array[DataCnt].ToDouble() * -10.0 ;
			MainFrame->TImgBG->Canvas->Pen->Color = TColor("$clOlive");;
		   //	TImgBG->Canvas->MoveTo(Xpoint0 + x, Ypoint0 + (ten8 * Vspan));
			MainFrame->TImgBG->Canvas->MoveTo(Xpoint0 + X_time, Ypoint0 + (ten8 * MainFrame->Vspan));
			MainFrame->TImgBG->Canvas->LineTo(Xpoint0 + x2*(10.0/MainFrame->Tspan), Ypoint0 + (ten8_1 * MainFrame->Vspan));
			chCnt = 1;

			ten8 = ten8_1;
			gou = gou + ms;
			//x = x2*(10.0/Tspan);
			X_time = x2*(10.0/MainFrame->Tspan);
			break;
		  default:
			chCnt = 1;
			break;
		}

		if((i % 10) == 0)
		{
			MainFrame->TImgBG->Update();
			MainFrame->TImgWave->Left = Xpoint0 + x2*(10.0/MainFrame->Tspan);
			MainFrame->TImgWave->Update();
			if (Terminated)
			break;
		}
		DataCnt += 1;

		if (Terminated)
			break;
	}
}
//---------------------------------------------------------------------------
void __fastcall MyThread::Execute()
{
	gou;
	haba;			                               			// 描画領域のXY幅
	DrawLeftX = 0;                                          // 描画領域左端
	DrawLeftX2 = MainFrame->TImgBG->Width;                	// 描画領域右端
	DrawHeightY = 0;                     					// 描画領域上端
	DrawHeightY2 = MainFrame->TImgBG->Height;				// 描画領域下端

	Ypoint0;
	Xpoint0;


	//---- ここにスレッド コードを記述します ----
	while(1)
	{
		// VCLコンポーネントに対する操作は、Synchronize() メソッド経由で行わなければならない。
		Synchronize(&UpdateDrawing);
		// Queue(&UpdateDrawing);
			// Sleep(10);

		if (Terminated)
			break;
			// return;

	}
}

Math

Re: アナログデータのリアルタイム描画

#10

投稿記事 by Math » 5日前

ダブルバファリングをしてflipするタイミングを固定値に制御(fps)すればよいと思ったのですが

ここで答えるような問題ではなくNI社に聞けば直ぐにわかると思いますよ。

今の時代大抵のことはすでに他人がやっていてそれを ”どこに聞くか分かっているか” が問題だけどこのような専門的な内容はここでは不向きだと思いますよ。悪しからず。

キョウ太郎
記事: 5
登録日時: 5日前

Re: アナログデータのリアルタイム描画

#11

投稿記事 by キョウ太郎 » 5日前

Mathさん

ご確認ありがとうございました。

NI社の方にも質問はしているのですが
あそこの場合、開発言語を知っている方が少なく、言語の技術的な質問の場合、殆ど解決できず最終的にLabViewを進められると言う悲しい事になるのであまり期待していません。

アニメーションとかバッファリングも調べては見たのですが、やはりそれだけで解決できなそうですね。
今は高精度タイマ(QueryPerformanceFrequency)とか使って何とかできないか考えているのですが
いい案が浮かんでこなくて投稿してみました><

初投稿なので無反応だったらどうしようと思っていましたので、回答していただけでも嬉しかったのでありがとうございます。
もし、何かいい案が浮かびましたら教えて頂けると幸いです。

Math

Re: アナログデータのリアルタイム描画

#12

投稿記事 by Math » 5日前

そうでしたか、了解です。

God Bless You.

ISLe
記事: 2627
登録日時: 8年前
連絡を取る:

Re: アナログデータのリアルタイム描画

#13

投稿記事 by ISLe » 2日前

オフトピック
わたしの得意分野かと思ったのですが、回答するのが憚られる流れですな。
最近ここに来るの不定期だし、Builder使ったことないので具体的な回答はできそうにないし。

Math

Re: アナログデータのリアルタイム描画

#14

投稿記事 by Math » 2日前

うわ~!残念。遅かりし由良・・・

Math

Re: アナログデータのリアルタイム描画

#15

投稿記事 by Math » 2日前

あ、違った
いい方法があったら教えてあげてください。
このかたはBuilderでなくてもVisualStudioでもいいそうなので。

Math

Re: アナログデータのリアルタイム描画

#16

投稿記事 by Math » 2日前

キョウ太郎さんISLeさんはゲームのプログラムのプロでFPS制御には詳しいかたなので問題点をなんでも聞いて見てください。

キョウ太郎
記事: 5
登録日時: 5日前

Re: アナログデータのリアルタイム描画

#17

投稿記事 by キョウ太郎 » 1日前

ISLeさん

コメントありがとうございます。
今回はC++Builderで作成中ではありますが、
基本はVisualStudioを使って開発をしていますし
今回の問題は考え方の問題なのかと思っているので。
言語の縛りなく教えて頂けると助かります。

いま問題視しているのは描画の速度と実時間の誤差をなるべくスペックに左右されないで動かす方法です。
前に書いた内容と同じですが
************************************
例えば、高すぎるスペック動かしたら1秒分の処理が0.5秒で終わり、次のデータが溜まるまで待つとカクカクした描画になってしまうし
低すぎるスペックだと、カクカクしないけど、1秒分のデータ描画するのに1.2秒かかったら毎秒0.2秒ずつ遅れていき10秒後には2秒前のデータを描画している事になってしまうのでそれを避けたいと言う事です。
(現在、これの状態です。)
************************************

以上

何か方法あれば、些細なことでも良いのでご指南頂けると幸いです。

Mathさん
気づくの遅くなり申し訳ございません。
コメントありがとうございました。
添付ファイル
波形描画.png

アバター
usao
記事: 1492
登録日時: 5年前

Re: アナログデータのリアルタイム描画

#18

投稿記事 by usao » 1日前

(1)
描画が測定より早い場合に,毎測定ごとにデータ描画して更新するよりも「カクカク」しない描画の仕方って何だろう?

(2)表示が遅れる場合:
まず,(何らかの画像バッファへの?)「描画」が遅いのか,
それとも,描画したものを「表示」するのが遅いのか,どちらなのか?

「描画」が圧倒的に遅いという場合,
どんどん遅れていくのを避けるには
データをてきとーに間引いて描画する的な措置しか思いつかない.

「描画」の速度が問題なのではなく「表示の更新」側が足引っ張るようなら,
「たまったデータを全描画したら→更新」にすれば良い(データ測定が等速ならば,表示遅延が一定になる)ように思うけども.

キョウ太郎
記事: 5
登録日時: 5日前

Re: アナログデータのリアルタイム描画

#19

投稿記事 by キョウ太郎 » 23時間前

usaoさん

ご確認ありがとうございます。

(1)描画が測定より早い場合に,毎測定ごとにデータ描画して更新するよりも「カクカク」しない描画の仕方って何だろう?
⇒データ取得のタスク開始→描画処理のタスクを開始するの順に別々のタスクを順番に開始するので
取得データと描画開始までのタイムラグがあるのはいいのですが
このEXEを動かす端末によって描画時の速度が変わってしまうのを防ぎたいです。
[私の開発環境]
Windows7 64bit Core i7-4710MQ 2.50GHz メモリ8GB
この開発環境だと1秒分のデータを描くのに1.01秒位の速度で描画される為、波形描画が止まることなく流れるように表示できるのですが

[別環境の端末]
Windows10 64bit Core i7-7700HQ 2.80GHz メモリ16GB
この環境だと恐らく描画が早すぎて(1秒分のデータを描くのに0.9秒位)で処理されてしまう為、次の描画データが溜まるまで描画処理が止まってしまう現象が起きています。


(2)表示が遅れる場合:
⇒こちらはデータ取得では特に遅延無いので、描画のループ処理で上記のスペック差での問題があると思っています。
画面に表示するタイミングを人が認識できる速度で画面更新しているつもりですが
この画面更新回数で描画速度が変化しているので、この回数を端末のスペック毎に動的に出来れば良いのか?もしくは根本的にこのようなアプリを作る場合の作法が違うのか?と言うところで悩んでおります。

タスクマネージャーのCPU使用率の様に1秒間隔で画面更新するなら問題なく作れるのですが
(人が認識できるレベルで)流れるような常に描画されるようなプログラムを目指しております。

アバター
usao
記事: 1492
登録日時: 5年前

Re: アナログデータのリアルタイム描画

#20

投稿記事 by usao » 22時間前

(1)側に関して:
> 1秒分のデータ
ってのを何回に分けて描画&表示 しているのかわからないけども,
測定周期よりも早くできちゃうのが困る場合には,
都度(測定周期 - かかった時間)だけ描画&表示の進行を待ってやればよいのでは.

(2)側に関して:
> 作法
なんてものがあるのかすら知りませんが,
 【測定者】→(測定データ)→【描画者】→(描画結果)→【表示者】
という3者の間で速度差をどう吸収するか?って話ですよね?

・【描画者】が遅い場合は,前記した通り,描画データを間引くしかないかなー,と思います.
・【表示者】が遅い場合は,【表示者】がビジーな間は【描画者】は同じ画像バッファに描画を続け,【表示者】の手が空いたタイミングで渡してやるような感じにすればどうでしょう?
 あるいは【描画者】から送られてくる結果がほっとくと「溜まる」状況なのだとして,【表示者】は最新の物だけを表示すれば(表示できなかった古いのは無視して捨てれば)OKとか.
オフトピック
200msに一回程度の更新で,その更新間隔も数十msくらいの幅でばらついても
「流れるように」見えちゃう人なので,これ系で表示のクオリティにはあまりこだわったことないです.
「データがどんどん溜まるかもしれない(=メモリが際限なくやばい)」側は問題視するけど.

キョウ太郎
記事: 5
登録日時: 5日前

Re: アナログデータのリアルタイム描画

#21

投稿記事 by キョウ太郎 » 5時間前

(1)
1秒分のデータ(1000サンプル分)をループ中に10回に1回画面に反映させています。
待機するとカクカクするかと考えていましたが、描画が早い場合には画面反映させるタイミングを計算して調整すればイケるかもですね。試してみます。

(2)
表示は回数増やしても対応できているっぽいので恐らく描画処理の速度によるものだと思っています。
確かに描画が遅いのなら処理効率を上げるか処理数を減らすしかないですよね。。。
なるべく間引くのは最後の手段に考えているのでまずは(1)と処理効率を精査してみます。

仮に間引く場合ですが、その端末で処理が「遅い」か「早い」かって
実際に描画処理を走らせる前に判別する方法ってありますか?
描画処理中に毎回確認していると、それこそ処理が重くなってしまう気がするので
起動時とかの準備中に検証用データを裏で処理させて確認するとかでしょうか?

アバター
usao
記事: 1492
登録日時: 5年前

Re: アナログデータのリアルタイム描画

#22

投稿記事 by usao » 2時間前

> 仮に間引く場合ですが、その端末で処理が「遅い」か「早い」かって
> 実際に描画処理を走らせる前に判別する方法ってありますか?

わかりません.
ただ,
> 準備中に検証用データを裏で処理させて
…的な処理だと,その検証結果と実処理との間にどれだけ差があるのかわからないので(それこそ環境次第な部分もある?)どうなのかなぁ,とか…?

「処理の最初の時点からいきなりうまい具合に動かないと話にならない!」という厳しい(?)話でないならば
実処理中にかかった時間でも計測して動作中に適宜調整される仕組みとかにしてもいいと思うけど…
オフトピック
(この話題の解決策としてはずれているからofftopic)
【調整が効く諸々を「設定値」として外出しして「いい感じに調整してどうぞ」で逃げる】という選択肢.

こういうのは,「このくらいならOK感」みたいな感覚が人によって違ったりするし,
頑張って仕込んだ自動調整機能が未知のいかなる環境でも常に「妥当に」動くか?とか考えるとうんざりしそうだし.
(例えば,めちゃくちゃ遅い環境で動かしたら「データが間引かれ過ぎて,全く表示の用を成さないぞ!!」とか)

返信

“C言語何でも質問掲示板” へ戻る