Hi Brian,
Thank you so much for your time and help along, up to this point, the code make
much more sense to me.However, I have a few more questions here, hope that you
will be able to help me out.
I am wondering
Where the aa_general_rgba_line() and aa_rgba_line() functions defined?When and
where the functions in s_aalinetemp.h and s_aaline.c are called/used?Are the
draw_line, draw_triangle, draw_point functions in OSMesa some how connected
with src/mesa/main/line.c or point.c?Is it possible to take out some required
functions for example aa_rgba_line(), gl_context, etc. and compile it on my
system so that I can draw a line into the framebuffer? (Or since there are too
many functions linked together, you would not recommend me to do that?)
Thanks
Andy.
> Date: Mon, 15 Jul 2013 08:24:58 -0600
> From: bri...@vmware.com
> To: lilap...@hotmail.com
> CC: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] OSMesa Help
>
> On 07/14/2013 09:34 PM, Andy Li wrote:
> > Hi,
> >
> > I have some questions on the OSMesa code.
> > As you suggested, I have continue looking into the swrast code.
> > However, I have trouble figuring out how the code works exactly.
> > Now I am now only focusing on the functions which draw lines.
> > As I look into s_lines.c, I saw the _swrast_choose_line().
> > And depends on different cases, it will call
> >
> > _swrast_choose_aa_line_function(ctx)
> > or
> > USE(general_line)
> > or
> > USE(rgba_line)
> > or
> > USE(simple_no_z_rgba_line)
> > etc.
> >
> > The first thing I did is looking into the
> > _swrast_choose_aa_line_function() and it direct me to s_aaline.c
> > In that file, I saw the struct of LineInfo and other computation
> > functions for plane.
> > Then I looked at the _swrast_choose_aa_line_function()
> >
> > and when I saw the code:
> > swrast->Line = aa_general_rgba_line;
> > and
> > swrast->Line = aa_rgba_line;
> >
> > I am not sure what do they mean. And I won't be able to continue finding
> > useful info.
>
> aa_rgba_line() drawns a "simple" RGBA antialiased line while
> aa_general_rgba_line() also computes texture coords, fog coord, etc.
>
>
>
> > I think the main problem I am having is I am not sure what are the steps
> > OSMesa have to take in order to draw a line into the frame buffer.
> > Would you be able to explain a bit on that? (what are the steps OSMesa
> > have to take in order to draw a line into the frame buffer?)
> > Does drawing a line involve computing the plane?
>
> AA lines are drawn by drawing a quadrilateral and computing pixel
> coverage involves computing plane equations.
>
> > What do s_aaline.c and s_aalinetemp.h actually mean?
>
> the "temp" files contain template code that's re-used multiple times in
> the .c file.
>
>
> > What is USE(general_line) ? Where is USE() define?
>
> grep "define USE" src/mesa/swrast/*.[ch]
>
>
> > What is swrast->Line = aa_general_rgba_line;?
>
> swrast->Line is a function pointer that points to the current line
> drawing function. The function is chosen by examining current GL
> rasterization state.
>
>
> > Would you suggest any debugging tool for me so that I can trace which
> > functions are called while the program is running?
> > For example I have the code below:
> > glBegin(GL_LINES);
> > glVertex3f(0.0, 0.0, 0.0);
> > glVertex3f(15, 0, 0);
> > glEnd();
> > Is there any debugging tool which can trace glVertex3f back in the
> > library and see how OSMesa works?
> > I have tried using gdb, however, it would only by-pass the call the go
> > to the next command.
>
> You'll need to build mesa for debugging (CFLAGS="-g -O0"
> --enable-debug). But I don't really have time to explain all the
> nuances of debugging/tracing in Mesa. I'm not sure that'd really help
> you anyway.
>
> In general, when you drawing points/lines/triangles the s_points.c or
> s_lines.c or s_triangle.c code winds up calling _swrast_write_rgba()
> span. This function does Z testing, texturing, stippling, etc before
> calling a "put_pixels" or "put_row" function. Those functions call a
> "pack" function to pack an array of RGBA ubyte/float values into the
> framebuffer. Packing involves converting a canonical RGBA format into a
> specific pixel format, like RGBA8888, or RGB565, etc. The color buffer
> address, stride, etc. is obtained earlier through a call to
> ctx->Driver.MapRenderbuffer(). In the case of OSMesa, the color buffer
> is ordinary malloc'd memory that the user allocated.
>
> -Brian
>
>
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
