On 7 May 2012 13:28, Anuj Phogat <span dir="ltr">&lt;<a href="mailto:anuj.phogat@gmail.com" target="_blank">anuj.phogat@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, May 7, 2012 at 11:53 AM, Paul Berry &lt;<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On 4 May 2012 15:02, Anuj Phogat &lt;<a href="mailto:anuj.phogat@gmail.com">anuj.phogat@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; This patch splits accuracy.cpp in to three files: common.h, common.cpp<br>
&gt;&gt; and accuracy.c.<br>
&gt;&gt;<br>
&gt;&gt; common.cpp defines the functions which can be utilized to develop new<br>
&gt;&gt; multisample test cases. Functions can be utilized to:<br>
&gt;&gt;  - Draw a test image to default framebuffer.<br>
&gt;&gt;  - Initialize a FBO with specified samples count.<br>
&gt;&gt;  - Draw a test image to FBO.<br>
&gt;&gt;  - Draw a reference image.<br>
&gt;&gt;  - Verify the accuracy of multisample antialiasing in FBO.<br>
&gt;&gt;<br>
&gt;&gt; Signed-off-by: Anuj Phogat &lt;<a href="mailto:anuj.phogat@gmail.com">anuj.phogat@gmail.com</a>&gt;<br>
&gt;<br>
&gt;<br>
&gt; It seems like you&#39;ve gone to a bunch of effort to provide a C interface (rather than a C++ interface) between the accuracy test and common.cpp, so that the accuracy test can be written in straight C.  Can you comment on the benefits of this?<br>

</div>I provided the C interface in sync with my plans to develop new<br>
multisample test cases using C. There are no specific benefits of this<br>
choice.<br>
<div class="im"><br>
&gt;   I see two downsides: a. it forces us to introduce extra wrapper functions that manipulate global state, and that doesn&#39;t seem desirable.  b. if we later decide to add a test that re-uses part of the common structure but not all of it (e.g. by adding a new TestPattern-derived class), we won&#39;t be able to do so easily.<br>

&gt;<br>
</div>I agree. That would require some extra efforts.<br>
<div class="im"><br>
&gt; Unless there&#39;s something I&#39;m missing, I would prefer if we took an approach like this to sharing code:<br>
&gt;<br>
&gt; - Move the class declarations from accuracy.cpp into common.h.<br>
&gt; - Move the member function implementations from accuracy.cpp into common.cpp.<br>
&gt; - Leave the global variable Test *test = NULL; in accuracy.cpp, so that the global state is confined to the individual test file, and isn&#39;t part of the interface between accuracy and common.<br>
&gt; - Leave accuracy.cpp as a C++ program.<br>
&gt;<br>
</div>I initially re factored using a similar approach. But later thoughts<br>
of providing a &quot;C&quot; interface overwhelmed me.<br>
I am fine with your suggestion and comfortable developing new tests in C++.<br>
<div class="im"><br>
&gt; If you&#39;re interested, I&#39;d be willing to take a stab at this approach and send it to the list.<br>
&gt;<br>
</div>Can you modify few member functions as per testing requirements of<br>
turn-on-off.c ([PATCH] Add test to turn on/off MSAA in a FBO) ?<br>
e.g define test_fbo, provide an option of rendering test image to<br>
default fb, using render buffer as color attachment for 0 sample<br>
count,  re initializing test_fbo with specified sample_count.<br>
I am fine with making above listed changes to re factored<br>
accuracy.cpp, if you face any issues understanding exact requirements.<br></blockquote><div><br>Ok, thanks.  Since I objected to your refactor, I feel like it&#39;s only fair for me to put together an alternative.  I&#39;ll get my proposal out to the list as soon as I can.<br>
</div></div>