This means that instead of 12 separate allocations we have just one,
allocating everything together in a contiguous piece of memory. That
should be also a bit more cache friendly when accessing the state as
it's not scattered around the memory like crazy.
Because there are no Pointer indirections needed anymore, the State
members are just references now. That resulted in a lot of sweeping
changes around the whole GL library, but they're all trivial, changing
`->` to `.`, mostly.
There's two more nested allocations in the TextureState struct, will
take care of them in a separate commit.
Not sure what I thought here, but using GL_IMPLEMENTATION_COLOR_READ_*
with glGetFramebufferParameteriv() is possible only since GL 4.5
(there's no extension adding it) and there's no equivalent for it in
GLES 3.1. I assumed that since the entry point is defined in 3.1 then it
would also accept the same enum, but apparently not -- and this
inconsistency is not fixed in 3.2 either.
Funnily enough, all drivers I tried (Mesa ES, SwiftShader, ANGLE) were
accepting this. The first driver that complained was ARM Mali on Huawei
P10 and there I assumed a driver bug -- but on the contrary, this is the
only driver following the spec properly :)
Now the glGetFramebufferParameteriv() API (and the DSA equivalent) is
used only on GL 4.5 contexts and up, everywhere else it's done using
the old-style glGetInteger(). I also renamed the implementations to not
misleadingly mention ES 3.1, since it has nothing to do with this. The
code path dispatch code is a bit entangled due to all the workarounds,
hopefully not breaking any behavior that worked before.
Was Magnum::GL::Extensions::GL before and the redundancy was completely
unnecessary. Potential future extensions coming from GLX, EGL or whatnot
will most probably be in the Platform namespace in a completely separate
file, so this is not a problem.
All code internal to the GL library is affected, not much the outside,
as that is handled by the compatibility alias.
This is quite big, so:
* There are new Magnum::PixelFormat and Magnum::CompressedPixelFormat
enums, which contain generic API-independent formats. In particular,
PixelFormat replaces GL::PixelFormat and GL::PixelType with a single
value.
* There's GL::pixelFormat(), GL::pixelType(),
GL::compressedPixelFormat() to convert the generic enums to
GL-specific. The mapping is only in one direction, done with a lookup
table (generic enums are indices to that table).
* GL classes taking the formats directly (such as GL::BufferImage) have
overloads that take both the GL-specific and generic format.
* The generic Image, CompressedImage, ImageView, CompressedImageView,
and Trade::ImageData classes now accept the generic formats
first-class. However, it's also possible to store an
implementation-specific value to cover cases where a generic format
enum doesn't have support for a particular format. This is done by
wrapping the value using pixelFormatWrap() or
compressedPixelFormatWrap(). Particular GPU APIs then assume it's
their implementation-specific value and extract the value back using
pixelFormatUnwrap() or compressedPixelFormatUnwrap(). There's also an
isPixelFormatImplementationSpecific() and
isCompressedPixelFormatImplementationSpecific() that distinguishes
these values.
* Many operations need pixel size and in order to have it even for
implementation-specific formats, a corresponding pixelSize()
overload is found via ADL on construction and the calculated size
stored along the format. Previously the pixel size was only
calculated on demand, but that's not possible now. In case such
overload is not available, it's possible to pass pixel size manually
as well.
* In order to support the GL format+type pair, Image, ImageView and
Trade::ImageData, there's now an additional untyped formatExtra()
field that holds the second value.
* The CompressedPixelStorage class is now unconditionally available on
all targets, including OpenGL ES and WebGL. However, on OpenGL ES the
GL APIs expect that it's all at default values.
I attempted to preserve backwards compatibility as much as possible:
* The PixelFormat and CompressedPixelFormat enum now contains generic
API-independent values. The GL-specific formats are present there,
but marked as deprecated. Use either the generic values or
GL::PixelFormat (togehter with GL::PixelType) and
GL::CompressedPixelFormat instead. There's a lot of ugliness caused
by this, but seems to work well.
* *Image::type() functions are deprecated as they were too
GL-specific. Use formatExtra() and cast it to GL::PixelType instead.
* Image constructors take templated format or format+extra arguments,
so passing GL-specific values to them should still work.
The general part stays in the root namespace, while the GL-specific
stuff goes to the GL namespace. Also all GL-specific documentation was
moved to relevant APIs in the GL namespace. This finally allows me to
build PixelStorage.cpp as part of the root namespace.
The PixelStorage::pixelSize() function and
PixelStorage::dataProperties() taking a pair of GL::PixelFormat /
GL::PixelType enums is deprecated, use GL::pixelSize() and
dataProperties() taking pixel size directly instead. A lot of code is
still using these, including images; the deprecated aliases are inlined
in the header to avoid a compile-time dependency on the GL library.
At the moment just the GL library itself w/o the tests, and without
backwards compatibility aliases. The following types were left in the
root namespace, despite being in the GL/ directory, as they will get
moved back soon:
* Image, CompressedImage and their dimensional typedefs
* ImageView, CompressedImageView and their dimensional typedefs
* PixelStorage
Not PixelFormat etc., that one will stay in the GL namespace and a
completely new PixelFormat enum will be provided in the root namespace.
Minimal updates (just the include guards) so Git is hopefully able to
detect the rename and track the history properly.
Everything except Magnum::GL doesn't compile now.
103% of use cases use the returned value directly without checking, so
we might as well do the check ourselves. Added new function hasCurrent()
and added deprecated backward-compatibility conversion and -> operators.
Wow, that creeped to a lot of places.
Last dinosaur from the pointer age.
Pain and misery. Majority of functionality for 3D compressed images now
suddenly fails the test -- this is either very vaguely specified or I am
very bad at understanding things or there are bugs in my NVidia drivers.
This was awful feature. Kill me now.
Makes it far easier to detect pixel storage misconfigurations and
improperly sized data arrays. Data owning classes (Image,
Trade::ImageData) accept Containers::Array<char> while wrappers
(ImageView, BufferImage) accept Containers::ArrayView<const void>.
ImageView reinterprets the passed array as const char to enable pointer
arithmetic on the data.
The old way (constructor/setData() call accepting void*) is now marked as
deprecated and will be removed in some future release. Because decay of
fixed-size arrays to void* is preferred to calling Containers::ArrayView
constructor, there are two more overloads to have proper handling of
const T(&)[n] and std::nullptr_t arguments.
Currently the TgaImporter and TgaImageConverter fail on images with row
length not aligned to 4, will fix that in followup commits.
Removed *Image::dataSize() and added *Image::dataProperties(), which
returns all properties separately for better introspection. This function
is now just an convenience alias to PixelStorage::dataProperties(), which
takes into account proper alignment and all other storage properties.
Yeah, sorry, I know, the enums are renamed for second or third time in a
row, first they were Image::Format, then ImageFormat, then ColorFormat
and now PixelFormat. But this time it's final and last time they are
renamed and now everything is finally consistent:
* ColorFormat::DepthComponent -- depth is not a color, thus
PixelFormat::DepthComponent makes a lot more sense.
* There will be PixelStorage classes, which will be stored in images
alonside PixelFormat/PixelType enums, making everything nicely
aligned.
* The GL documentation about glTexImage2D() etc. denotes the <format>
and <type> parameters as format and type of *pixel* data, so now we
are _finally_ consistent with the official naming.
I wonder why did I not choose PixelFormat originally. Anyway, the old
<Magnum/ColorFormat.h> header, ColorFormat, ColorType and
CompressedColorFormat types are now aliases to the new ones, are marked
as deprecated and will be removed in some future release (as always, I'm
waiting at least six months before removing the deprecated
functionality).
In OpenGL ES 2.0 there is EXT_draw_buffers, which I overlooked somehow,
so I added it to extension list and included in the implementation. It
combines NV_draw_buffers and NV_fbo_color_attachments, so the
implementation now selects one of the two based on which extension is
supported, preferring the EXT one. Updated the documentation to be
less confusing, fixed extension links. Also the single-output
mapForDraw() is not handled separately on ES anymore and just calls
DrawBuffers implementation with single parameter, resulting in less
generated code.
EXT_draw_buffers can also be called on default framebuffer and
apparently in ES there is no way to map front framebuffer for drawing,
so I removed it from the DefaultFramebuffer::DrawAttachment enum.
This was a leftover from some not-well-thought-out design decision. The
function is now used exclusively for binding for draw, as all
framebuffer reading functions (blit(), read()) are doing the read
binding internally. Moreover it required the user to be extra careful on
ES2, because in many cases there are no separate binding points for
reading and drawing.
The function is now parameter-less and always bind the framebuffer for
drawing. The logic for internal binding was also simplified and on ES2
there are separate implementations for single/separate binding points.
For *Framebuffer::checkStatus() the documentation was updated to explain
the meaning of the parameter on ES2 implementation. Also removed the
need for FramebufferTarget::ReadDraw binding, as it was rather
confusing.
Old *Framebuffer::bind(FramebufferTarget) is now just an alias to the
parameter-less function, ignoring the parameter. Along with
FramebufferTarget::ReadDraw it is marked as deprecated and will be
removed in some future release.
In the future, when I get to implement proper DSA clearing, this won't
change currently bound framebuffer and thus it might be useful to be
able to call bind() right after, e.g.:
framebuffer.clear(FramebufferClear::Color)
.bind(FramebufferTarget::ReadDraw);
Vladimír Vondruš