juhsyの座標を整数値で保持してたデメリットにやっと気がつく。 （誤差が蓄積して拡大回転時に座標がずれてた）

えぇ、1ドット単位のGPSETに相当するアクセスは前述の通りで楽観的に考えてます（細い線は範囲狭いので計算量も配列経由でも少ないかと) 広い範囲ならFILLとcopyが使えるので32画素いっぺんに処理できるところは 使えそうです。まぁ無理だったら2*2の4階調に落とします。

関数は呼び出しコストがかかりますし、れいさんのお陰で1行に収まったので めでたしめでたし。（←実装しろよ

重いかもしれない・・・・あとtouchの座標精度が良くないので 座標の計算どうしようかと言うのはありますね。

内部的には400*240の縦横4倍解像度1200*960の二値画像として記録しておきます。

拡大したときに二値で表示したいのです。

通常解像度において、ドットは直接的には表示に関係してこないので 使わないほうが良かったのかも・・・

あぁ・・・ドットの認識自分間違ってるか・・・

自分の認識では ビットとドットが1:1で対応してて配列1要素に対して 前述画像の配置で並ばせようとしていると思ってください 拡大していない通常の解像度に於いて 4*4ドットで画面の1ピクセルで表示しようとしてます。 画面の1ピクセルに出力する濃度は(実際にはα値を経由しますが) 仮に黒0,0,0だとすると0,0,0から255,255,255まで4*4ドット内のビットが1の個数で決定(つまり0/16～16/16まで17段階)します。

濃度は二値レイヤの出力不透明度のつもりでいいました。 ドットは二値配列の点単位 ピクセルは画面に出力する際の単位として使ってたのですが・・・ 認識これで合ってますかね？

ドット単位の計算することは線を引くとか計算量の少ないものばかりなので 8*4で格納するのと32*1で格納して濃度計算をする場合に配列読み出し4回をしなきゃいけないのとどっちが早いのか自信がなくなってきた・・・・(；´Д｀)

座標計算はれいさんのに倣うなら Array%[((y*w)>>2)+(x>>3)] and 1>>((y%4)>>3)+(x%4)+(floor((x%8)<<2)>>2))とか・・ (可読性が著しく低下した計算(；´Д｀)) (下手なことしないで32*1で良いような気がしてきた)

えー？かけてるような気がする。

え？、その手が使えるのでそれでいいと思いますが。 ４×４ビットのフラグの立った個数で表示濃度を１６段階で表示したらいいと思ったのです、これを32×1ドットで割り当てたら縦方向だと配列要素をまたがる事になり煩雑かなと感じたので。

たしかにビット毎に配列アクセスになるのはありますね、それだけだと遅いかも。 ただ４*4単位にしておけば、おそらく大半のアクセスを占めるであろう全ビット同じの処理を１６or32ドット一括で処理できそうな気がします。他に問題点とかありそうですか？

れいさんのを使用するならドット単位の入出力は座標変換だけですね。これを書かねば。

実数型って64ビット論理演算できましたっけ？ できたら８*８が行けそうな・・・

要素ずらし配列だと、画素の端のピクセルが反対側の端に移動してしまうことが判明。orz 素直にgSaveでずらした配列を取得すりゃよかった。

アプローチとしては要素ずらしを行ったRGB分離配列を#AOPMAD,出力配列,色配列,１/9,出力配列 で各周辺ピクセル毎にループという感じですかね？

＞みなつさん すえさんは前述のオーバーサンプリングでやってますね。 円中心座標からの距離がでるのですからあとは半径比率に応じて円カーブでも三角関数でも指数関数でもベジェ曲線でもお好みで、juhsyは内部的にはただの直線で計算、表示には三角関数つかってます(ブラシのGUIとか)