You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some widgets, like rtk.Entry and rtk.Viewport, create their own backing stores. As Reaper has a fairly low limit on the number of available image buffers (1024), this restricts the number of those widgets that can be created.
The idea is to create a class that works along side rtk.Image to create rtk-internal buffers. REAPER images can be 8192x8192 in size, and with 1024 of them, that's quite a lot of image buffer space to work with. We just need to be cleverer about allocation.
The buffer pool class should:
dynamically allocate REAPER buffers (using rtk.Image) with the full 8192x8192 resolution as needed
provide an API to allocate rtk buffers (sub regions from the REAPER buffer), bin-packing across available REAPER buffers based on the requested geometry. The subregion would use rtk.Image:viewport()
maintain a refcount for each REAPER buffer
support Lua GC to automatically release subregions and decref the REAPER buffer
free REAPER buffers when no more refs exist
The text was updated successfully, but these errors were encountered:
Some widgets, like rtk.Entry and rtk.Viewport, create their own backing stores. As Reaper has a fairly low limit on the number of available image buffers (1024), this restricts the number of those widgets that can be created.
The idea is to create a class that works along side rtk.Image to create rtk-internal buffers. REAPER images can be 8192x8192 in size, and with 1024 of them, that's quite a lot of image buffer space to work with. We just need to be cleverer about allocation.
The buffer pool class should:
The text was updated successfully, but these errors were encountered: