On Tue, Mar 11, 2003 at 12:33:53AM +0100, Felix Kühling wrote:
> On Mon, 10 Mar 2003 22:23:07 +0000
> José Fonseca <[EMAIL PROTECTED]> wrote:
> [snip]
> > As I said above this can be done in C++, and without damage to
> > efficiency.
> >
> > Imagine you have a TnL abstract class:
> >
> > class TNL {
> > // A OpenGL function
> > virtual void Coord3f(GLfloat x, GLfloat y, GLfloat z) = 0;
> >
> > // Activate
> > virtual void activate() = 0;
> >
> > protected:
> > struct dispatch_table *my_dispatch_table;
> > } ;
> >
> > and then you have two inherited classes for software and hardware
> > rendering:
> >
> > class SoftwareTNL : public TNL {
> > // The software version. Note the _inline_
> > inline void Coord3f(x, y, z) {
> > _mesa_swrast_deal_with_this_vertex(x, y, z);
> > }
> > };
> >
> > class HardwareTNL : public TNL {
> > // The hardware version. Note the _inline_
> > inline void Coord3f(x, y, z) {
> > _add_vertex_to_DMA_buffer(x, y, z);
> > }
> > };
> >
> > and then the C-callable versions for the glapi disptach table:
> >
> > void softwareCoord3f(GLcontext *ctx, GLfloat x, GLfloat y, GLfloat z) {
> > Driver::Context *context = ctx;
> > Driver::SoftwareTNL &tnl = ctx->tnl;
> >
> > // There will be no call as the function will be expanded inline
> > tnl.Coord3F(x, y, z);
> > }
>
> Here you're converting a GLcontext * to a Driver::Context *. Can you do
> that because Mesa::Context has GLcontext as first member? Anyway, if
> that didn't work you could always do some fancy pointer arithmetics with
> the offset of the GLcontext in Driver::Context.
That one was a simplification, and not an exact representation of what
should be done, which is:
Driver::Context *context = (Driver::Context *)ctx->DriverCtx;
That is, the driver private context pointer in GLcontext points to the C++ class for
the driver context.
But I could have chosen to derive Mesa::Context from GLcontext. See for
example the Framebuffer class in http://jrfonseca.dyndns.org/projects/dri/cpp/mesa.hxx
.
I may eventually choose to do the same thing for GLcontext, but it's not
very important right now.
> But then, if the GLcontext is a member (not a pointer) in Mesa::Context,
> then it would have to be created by the constructor of Mesa::Context.
> Just checked in radeonCreateContext, the GLcontext is really created
> there by calling _mesa_create_context. But _mesa_create_context returns
> a pointer to the GLcontext. You would need a _mesa_create_context which
> takes a GLcontext pointer as a parameter.
This is something quite nice about mesa: for some of its structures you
have the choice to dinamically allocate them, or simply initalize, i.e.,
you can choose _mesa_create_context or simply _mesa_initialize_context
which does what you describe.
> Maybe I'm getting lost in details, but IME it's better to stumble sooner
> than later.
Nop. You didn't lost, and the way we do it is not that irrelevent as it
may seem, as the driver will definitely need to access the Mesa's
GLcontext data structure. Composition and/or inheritence is preferable
to pointers since they avoid the extra redirection.
> Disclaimer: I support the idea of a C++ framework for DRI
> driver development. ;-)
:-)
All feedback is welcome, even of "non C++ believers", as long as the
arguments focus specific problems with the C++ approach, and not the
language alone.
José Fonseca
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
