If the buffer is not created with allocateDirect, JNI APIs will return a data pointer of nullptr and a capacity of -1. This can cause a crash when we access it.
Also clean up the code to raise exceptions instead of just logging errors and returning nullptr.
PiperOrigin-RevId: 489751312
This ensures that the callbacks in GlTextureView won't call an expired object, even if user code holds a GlTextureView after releasing the buffer.
Note that GlTextureBuffer is not always held by a shared_ptr, but it always is when GpuBuffer calls GetRead/WriteView on it. An alternative solution would have been to have GpuBuffer pass its shared_ptr<GlTextureBuffer> to the view method, which could have been implemented with some compile-time logic to detect whether the method expects such an argument. However, that doesn't seem necessary.
PiperOrigin-RevId: 489611843
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
