[Mesa-dev] [Bug 30172] GL_EXT_framebuffer_blit function required

[Allen Akin]

Some brief comments from an historical perspective...

On Thu, Sep 16, 2010 at 09:46:49PM -0700, bugzilla-daemon at freedesktop.org wrote:
| https://bugs.freedesktop.org/show_bug.cgi?id=30172
| 
| --- Comment #20 from Luca Barbieri <luca.barbieri at gmail.com> 2010-09-16 21:46:49 PDT ---
| FWIW, here is how to design an extension system which is actually usable...

Designs like this were considered, but rejected for a number of reasons
(some of which may no longer apply).  Here are a few that I remember off
the top of my head.

Exported function tables reduce the ability of the driver to replace the
entire dispatch table with a single pointer change for new state
combinations or rendering modes.  If the app gets a pointer to a
dispatch table and caches it, the only way for the driver to change how
commands are dispatched is to edit the entries in the table, which takes
more memory references and can introduce synchronization issues.  You
also need to prevent compilers from caching the table pointer or
individual entry pointers.

Context-dependent function pointers introduce an entirely new class of
error conditions.  For example, what do you do when a context-specific
command can be invoked on a context whose driver doesn't even have an
entry point for it?  As well, app code needs to invoke different
function pointers for each context it uses, so it needs to know at all
times which context is current or which set of function pointers is
active.  This makes writing general-purpose GL-using libraries much more
awkward.

Structs as part of the interface don't work well for all language
bindings.

Passing GL context pointers to commands means that the commands all have
to be prepared to perform a context switch.  Restricting context changes
to a few coarse-grained commands had performance advantages.

Allen