Mercurial > hg > Papers > 2020 > riono-thesis
changeset 26:f9c3bb497e9c
update chapter3
| author | riono <e165729@ie.u-ryukyu.ac.jp> |
|---|---|
| date | Sat, 15 Feb 2020 04:51:01 +0900 |
| parents | f98010ed4fa9 |
| children | 3a6c2fd368b4 |
| files | FinalThesis/chapter3.tex FinalThesis/chapter4.tex FinalThesis/fig/TileLoopFlow.graffle FinalThesis/fig/TileLoopFlow.pdf FinalThesis/main.pdf |
| diffstat | 5 files changed, 27 insertions(+), 4 deletions(-) [+] |
line wrap: on
line diff
--- a/FinalThesis/chapter3.tex Sat Feb 15 03:59:21 2020 +0900 +++ b/FinalThesis/chapter3.tex Sat Feb 15 04:51:01 2020 +0900 @@ -72,17 +72,40 @@ \item 行の初めから、行の途中までを構成するRectangle(図\ref{fig:BlockingUpdateRectangle}中 Phase2) \end{itemize} +\newpage \section{TileLoop} -Rectangleの再構成にはTileLoopというループ内で行なっている。TileRoopは64x64の大きさであるtileを1つずつ処理していく。以下の図\ref{fig}にTileRoopのフローチャートを示す。 +Rectangleの再構成、Multicast Packetの構築にはTileLoopというループ内で行なっている。TileRoopは64x64の大きさであるtileを1つずつ処理していく。以下の図\ref{fig:TileLoopFlow}にTileRoopのフローチャートを示す。 -%フローチャート +\begin{figure}[htb] %PDF +\begin{center} +\includegraphics[scale=0.5]{fig/TileLoopFlow.pdf} +\figcaption{TileLoopのフローチャート} +\label{fig:TileLoopFlow} +\end{center} +\end{figure} +TileLoopにはc1Rectと呼ばれるRectangleを持っている。これは読み込んだTile分だけ拡張していくことでRectangleの再構成を行うことができる。Phaseが変わるとこれまでに構成されたc1RectをHeaderに書き出し、c1Rectを初期化する。 + +次に、Packetの構成と各Phaseとの関係性を下記の図\ref{fig:Packet}に示す。 - +\begin{figure}[htb] %PDF +\begin{center} +\includegraphics[scale=0.5]{fig/Blocking.pdf} +\figcaption{RectangleとPacketの構成} +\label{fig:Packet} +\end{center} +\end{figure} +\newpage +PacketにはMassage IDなどが入っているPacket Headerの他に、各RectangleのHeaderであるRectangle Headerが付いている。 +また、Phaseが変わるごとにRectangle を構成し直す必要があるため、各Phaseの終了時には確実にflushをする必要がある。 + +Packetの上限は60KByte取っているがZlibの性質上、パケットの容量を予測して圧縮書き出しすることができず、圧縮時にPacketから溢れてしまう場合がある。そのため、初期上限を42KByteとしてPacketが一杯にになった際に上限を60KByteまで大きくする。 + +圧縮前の1Tileの大きさは最大で16KByteと考えられる。これを圧縮すると3 - 4 KByte程度であるので、その分のマージンを持っておくことで、読み込んだ最後のTileまできちんとPacketに書き込むことができる。 \section{Packet Lost}
--- a/FinalThesis/chapter4.tex Sat Feb 15 03:59:21 2020 +0900 +++ b/FinalThesis/chapter4.tex Sat Feb 15 04:51:01 2020 +0900 @@ -34,6 +34,6 @@ -pオプションが正常作動しなかった原因として、ディスプレイの選択を行なっていなかったことが挙げられる。設計当初の-pオプションはCUIでの動作を想定しており、ディスプレイがない場合もあるという想定だった。 そのため、画面配信用の画面が選択されておらず、画面データがうまく生成されない状況が発生していた。 -これを、確実にGUIでビューワーを表示するという前提でディスプレイ選択を行うことで、正確に画面データの生成を行わせ-pオプションでのデバッグが可能となった。 +これを、確実にGUIでビューワーを表示するという前提でディスプレイ選択を行うことで、正確に画面データの生成を行わせ-pオプションでのデバッグが可能となった。また、自身で画像データの圧縮しMulticast Queueにデータを送っているため、Blockingのルーチンがデバッグ可能となっている。