| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
These are equivalent anyway, but this avoids include-what-you-use warnings and
makes it clear that there is no GL code in the backend.
|
|
|
|
|
|
|
|
|
|
This is needed for clipping. Unfortunately, the puglEnterContext() and
puglLeaveContext() API was not suitable for this, but this shouldn't matter in
user code because it is only used for setup, and is slated for removal anyway.
Instead, just call the backend functions directly in the implementation.
|
|
Working on Vulkan clarified what has always been slightly smelly about the
design and organization here: not everything that is API specific is really in
a "backend" (a PuglBackend). The concrete example is puglGetProcAddress(),
which only makes sense for GL and is actually implemented in the "backend"
files. Arguably puglGetContext() is also such a thing.
So, rename the headers so they can be the place where API-specific things go in
general, which happens to include a backend most of the time. The stub is a
bit of an exception to this, but whatever. The includes look tidier this way.
In place of the old headers are compatibility stubs that just emit a warning
and include the new version, which will be maintained for a while.
|
|
This was the only use of actual GL in the backend, and I'm relatively sure this
flush is pointless anyway. If, for some bizarre reason, anyone really wants to
run without double buffers, they are always free to flush themselves.
|
|
|
|
Towards having actual trivial backends, but in general allows backends to not
declare functions they don't care about which is nice and already a net
reduction of actual code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Taking a page from C++ convention, where "detail" is for things that should not
be included in user code.
|
