111–120 of 122 posts
Earlier quoted context omitted.
Interesting, why do video slot machines use APNGs?
I don't know for sure but when I used to repair them you could watch them load up the APNGs on boot. The first time I saw them in the wild was around 2007
Earlier quoted context omitted.
> these days, generating or decoding PNGs is the bottleneck almost nowhere Anecdotal, but I'm familiar with a system which spends ~50% of CPU cycles on PNG encoding (most of which is actually spent in zlib compression). The other approaches I've seen involve creating performance-focused forks of zlib (e.g. zlib-chromium and zlib-cloudflare). This has benefits beyond PNG encode / decode: https://aws.amazon.com/blogs/o…
Why not use fpnge?
Earlier quoted context omitted.
(edit: The answer should logically follow from the following, but as a TL;DR: yes, they must have meant jpeg or similar, although I disagree about it being such a "please don't". Feel free to, they'll take more bytes but it's not like you're losing information in the process, so you can always still switch to jpeg.) Photos have lots of noise anyway, so a good jpeg is not going to be the limiting factor. Due to jpeg b…
> screenshots For browsers, there are extensions that can create SVG screenshots. They work by either copying or inlining CSS into the SVG. They don't work all the time, but worth giving a try first. For Firefox, see https://addons.mozilla.org/en-US/firefox/addon/svg-screensho... , it worked relatively well for me.
The author also wrote the accompanying library, dom-to-svg: https://github.com/felixfbecker/dom-to-svg
It seems to capture the HTML and convert each element to a similar one on SVG. I'm still not sure how it handles raster images (does it just embed them? Vectorize them somehow?) but it's a really cool project. Thanks for sharing!
Earlier quoted context omitted.
Minor nitpick, just for clarity: Vectors aren't really the "ultimate" format, they're just a different format for storing a different kind of information. Vectors are good for things that can be mathematically described/simplified without significant loss of information (such as curves, shapes, some gradients, etc., and compositions of those) Many logos and fonts fall into this category, for example, and some clip-ar…
> Real pixels do hold data, and vectorizing them will typically cause some data loss. Chickens and eggs. If you have vector data already, it's better to distribute the raw vectors than to rasterize them. If you only have raster data, distribute the rasters (where viable) instead of trying to trace them. Lossy operations are lossy. Vectors are largely preferable to rasters, but that doesn't mean you can reproduce them…
Earlier quoted context omitted.
Though doesn't that mean the feature is less likely to be implemented in the first place? Nobody gave a shit about Unicode grapheme clusters until EEMAWDJI came about. Sadly.
What's "EEMAWDJI?" There are no Google search results for that acronym.
Earlier quoted context omitted.
Why not use fpnge?
It's a Java system, so not quite so simple. Maybe it's worthwhile to create some Java bindings? Recent JDKs make it feasible to swap out the underlying zlib implementation, so swapping out zlib-madler with zlib-cloudflare or zlib-ng might provide the best cost/benefit.
Replacing zlib might give you a few percentage points' worth of difference, whilst fpnge would likely be several times faster.
Earlier quoted context omitted.
It's a Java system, so not quite so simple. Maybe it's worthwhile to create some Java bindings? Recent JDKs make it feasible to swap out the underlying zlib implementation, so swapping out zlib-madler with zlib-cloudflare or zlib-ng might provide the best cost/benefit.
Someone made this: https://github.com/manticore-projects/fpng-java Replacing zlib might give you a few percentage points' worth of difference, whilst fpnge would likely be several times faster.
Earlier quoted context omitted.
ok thats pretty wild, you would take the zlib deflate/inflate code, (for example in a library like lodepng) and then like chunk 95% of it in the garbage? so basically every block would just be uncompressed? kind of funny but it would probably work pretty well and your code size could get down way way smaller than the current typical png code. seems like the downside is that this is "worse than nothing" compression, t…
There's no need to take anyone else's code, emitting uncompressed DEFLATE blocks is trivial. I'm not sure what you mean by garbage? > for example 1024x1024x32bit color means 3 megabytes for one image. You do miss something, that's 4 megabytes, plus any header/format overhead - but you'd get similar performance out of any uncompressed format, that's just the tradeoff.