タイトルを見て「何を言っているのだ」という方が大多数だと思うので、
サンプルプログラムをお見せしつつ、何がしたいのかを書いていこうと思います。
但し、メモリ書き換えが行われるようなプログラムなので、
危険性を認識した上で実行するようにお願いします。
(主にソースコードを自分で読む等)
サンプルプログラム：
https://drive.google.com/open?id=0B3Iyqr1DZrPqUl9uLW1YeVRKT28&authuser=0
HSPでグラフィックを描いているときに、ふと思ったのです。
「ドロワータスクを計算タスクと分けたい」と。
普通に使っていれば、グラフィックを描画中は計算はできませんし、逆もしかりです。
ですが、計算が多すぎればコマ落ちしますし、グラフィックが重すぎると計算が満足にできません。
HSPはマルチスレッドプログラミングは事実上できないといえるので、普通の手段ではこの状態は回避できません
(いや、そりゃアルゴリズムで何とかするのが上策でしょうけど)
さて、このサンプルプログラムは、「グラフィック描画部分」と「計算部分」の分離のサンプルです。
サンプルプログラムのファイルには
get(グラフィック受信側)<-gen(グラフィック発生器)の構造として大量の実行ファイルができていますが、
shared系以外はgenを起動する事はできません。
1. Shared系:(SharedGGet <- SharedGGen)
メモリ共有型で作ったサンプルです。
http://chokuto.ifdef.jp/advanced/sharedmem.htmlを参考に作ったものです。
長所：
Get側主体でVRAMデータをコピーするので他より安全
短所：
メモリ間コピーの回数が1回増えるので他より遅い
Get側の手間が増える(メモリ間コピー1回分)
2. 無印系：(GGet <- GGen)
メモリ干渉型(他プロセスメモリ書き換え型)で作ったサンプルです。
http://peryaudo.hatenablog.com/entry/20100516/1273998518を参考に作ったものです。
長所：
Gen側からGet側へ送りつけることができるので、redrawだけで表示が可能
短所：
Gen側がデータの送信を間違えると最悪ブルースクリーンを起こす
3. 応用例：(GGetXsamples <- GGenAmano, GGenDiamond, GGenShirano, GGenVerge)
d3moduleのサンプル4つの表示を一つの画面にまとめた形で表示させるプログラムです。
d3moduleのサンプルは一つ一つが非常に重いので、Core i3以上推奨です。
使い道の例として提示しています。
・既知の問題と今後の展望
フレーム同期をしているわけではないので、ちらつく可能性がある。
gcopy/gzoomが意外と重い。
マウス・キーボード入力が渡せない→対応する予定
きちんとライブラリ化→対応する予定
メモリ書き換えを用いたマルチプロセスグラフィック
