Cyphall

Same problem here. With this example: ``` D: └───testlib └───src └───testlib └───test.cpp └───test.h ``` test.h: ```cpp #pragma once void Test(); ``` test.cpp: ```cpp #include "testlib/test.h" void Test() { } ```...

OpenTK version 4.0.0-pre9.1 Enum `GetPName` (used with `GL.GetInteger`) is missing: - `ShaderStorageBufferBinding` Enum `InternalFormat` is missing: - `Rgb32f` - `DepthComponent24`

Function `GLFW.SetInputMode` is missing an enum for mode `GLFW_RAW_MOUSE_MOTION`. [Doc reference](https://www.glfw.org/docs/3.3/group__input.html#gaa92336e173da9c8834558b54ee80563b) We could rename the enum `StickyAttributes` to something more generic to handle all modes that can take either `true`...

That might be a great idea. I developped a small tool a few years ago that basically runs all the png files in a folder through google's [ZopfliPNG](https://github.com/google/zopfli). When running...

There are still some questions to be answered before going further: 1. Do we need to keep metadata? Most of it is pointless information, but some metadata like sRGB profile...

> The rgb data for alpha 0 pixels breaks some textures (fast leaves is the only example i can think of, but still), so I'd keep it to be safe...

Alright, so we keep all pixel data. > 1. Do we need to keep metadata? > Most of it is pointless information, but some metadata like sRGB profile (if used)...

I set up my tool to keep all the chunks that might change the final render : - cHRM - gAMA - pHYs - iCCP - sRGB - oFFs -...

A workaround is to create two image views from your framebuffer image, one with a linear format and the other with an sRGB format, and to render/sample from the right...

Same problem for me as I'm on a very tight VRAM budget for gaming (two 4K screens plugged into a 8GB GPU) so any VRAM saving is welcome