6 ms·
We started using OpenGL in 2011. Our CPU-based image filters used to take 4+ seconds with pixel-by-pixel manipulation, and now can render 30+ times per second.
by mikeyk 10y ago
We started using OpenGL in 2011. Our CPU-based image filters used to take 4+ seconds with pixel-by-pixel manipulation, and now can render 30+ times per second.
If you have some sample images where the current image pipeline is going wrong let me know and we can look into improving.
- osi 10y agoI think that's back when Gotham died :/ http://randsinrepose.com/archives/rip-gotham/ http://randsinrepose.com/archives/rip-gotham/
- nrjdhsbsid 10y agoInstead of fixing the horrible JPEG encoding can you please add support for webp? It's quite a bit smaller and well supported with polyfills since it's just a single vp8 frame
- tossedaway334 10y agopolyfills in general are a really awful user experience. They are typically pushed by people who use the latest chrome, so they have an excuse not to care about other browsers. Their preformance, and usability is almost invariably terrible.
- dbbk 10y agoYou don't need a polyfill to deploy Webp. Chrome automatically sends webp in the Accept headers for images, so on the CDN level you could implement some logic to seamlessly swap in Webp images for the browsers that support it. Imgix does this for instance.
- deleted 10y ago[deleted]
- DinosaurArms 10y agoI also went through that process with my app Picfx. Using OpenGL for filters is much quicker, the only downside I've found is being limited by the texture size, I did set up a way to process images in tiles but ultimately decided to just limit images to the texture size. Great info on the colour space, I'm sure it will be useful.