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
I have some feelings about what seem to be arbitrary and restrictive rules that limit the creativity you can have with a Tidbyt device, and was hoping you would consider relaxing some of these:
Image size limits
The 190k (ish) file size limit on anything uploaded directly to a device with pixlet push has too great an impact on the kind of animation you can do. The way WebP compression works, you might be able to fit a 200+ frame animation using just black and monochromatic pixels, while only permitting 50 frames if you chose to use a large palette, complex motion, fine detail etc. I understand the desire to limit apps to at most 15 seconds to allow frequent cycling, but capping this with an arbitrary file size limit, rather than a real time limit, isn't the way. It discourages cool use-cases like full-motion video, generative art, etc. that is less efficient in terms of compression. I propose inspecting the WebP headers and multiply its Frame Duration by the number of frames in the file to determine and constrain the length of an image this way.
1-second app execution limit
For similar reasons, the limitation on app execution time is pretty restrictive. I understand the cost of server compute is directly related to how long it takes to execute these apps, but 1 second is quite short. In addition, this is a subjective metric that depends on the machine it runs on, making it both painful for developers with fast machines who receive false positives from pixlet check. as well as just being a bummer in general.
The text was updated successfully, but these errors were encountered:
I have some feelings about what seem to be arbitrary and restrictive rules that limit the creativity you can have with a Tidbyt device, and was hoping you would consider relaxing some of these:
Image size limits
The 190k (ish) file size limit on anything uploaded directly to a device with
pixlet push
has too great an impact on the kind of animation you can do. The way WebP compression works, you might be able to fit a 200+ frame animation using just black and monochromatic pixels, while only permitting 50 frames if you chose to use a large palette, complex motion, fine detail etc. I understand the desire to limit apps to at most 15 seconds to allow frequent cycling, but capping this with an arbitrary file size limit, rather than a real time limit, isn't the way. It discourages cool use-cases like full-motion video, generative art, etc. that is less efficient in terms of compression. I propose inspecting the WebP headers and multiply itsFrame Duration
by the number of frames in the file to determine and constrain the length of an image this way.1-second app execution limit
For similar reasons, the limitation on app execution time is pretty restrictive. I understand the cost of server compute is directly related to how long it takes to execute these apps, but 1 second is quite short. In addition, this is a subjective metric that depends on the machine it runs on, making it both painful for developers with fast machines who receive false positives from
pixlet check
. as well as just being a bummer in general.The text was updated successfully, but these errors were encountered: