Originally, there were multiple implementations of GlCalculatorHelperImpl, depending on the platform and underlying GL APIs. These have all been refactored into other components, and the remaining code in this class is unified and much reduced in size. We can get rid of this implementation detail now.
PiperOrigin-RevId: 488813220
This was only documented via examples (e.g. ViewProvider<GlTextureView>), but it's better to explain it properly in the header where the base case is defined.
PiperOrigin-RevId: 488813144
This gives a basic explanation of the role of storages and views, and provides some details on how to implement a new storage type.
PiperOrigin-RevId: 488812807
This means that, if an iOS application sends in a GlTextureBuffer but expects a CVPixelBufferRef as output, everything will work even if the graph just forwards the same input. Also, access by Metal calculators will also work transparently.
PiperOrigin-RevId: 488812748
First crack at hooking up pools with the GpuBufferStorage system. Will most likely be superseded later, but for now this works with minimal code impact: just overwrite the factory for a storage type with one that uses the pool.
PiperOrigin-RevId: 488783854
Passing MultiPool options to the base pool factories means that we don't have to specialize which options we pass to them.
PiperOrigin-RevId: 488782861
This may not fit exactly in a pool class, but it makes it easy for the multi-pool to find the appropriate method by depending only on the type of the base pool. For the CVPixelBuffer case, the buffer type is CFHolder<CVPixelBufferRef>, and it seems even less appropriate to specialize that template to add such a method there. An alternative would be to allow defining a creation function separately.
PiperOrigin-RevId: 488782054
