- When not on simulator, we pass nullptr instead of a do-nothing callback.
- The callback is no longer a method, but a function. Only the CVPixelBuffer is captured.
PiperOrigin-RevId: 490380248
A framebuffer object is often needed to render to a texture or read data from it. Currently we create one in each GlCalculatorHelper, but that is redundant (we only need one per context, and multiple calculators can share the same context). Other times, the code that needs to use this doesn't own a helper. For both reasons, this should be attached to the context.
We could just make this a member of GlContext since it's so common. However, I figured we might as well use the attachment system.
PiperOrigin-RevId: 490160214
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
