At this point in time it can be assumed that 90% of everything on the internet is a lie.
French nuclear electricity is cheap because the government subsidizes it to keep it afloat. And because continental European electricity is generally expensive. It probably wouldn't survive in a free market.
For example, you can say, take a true-color animated WebP, quantize it to 64 colors max, but make sure the first 16 colors is the same as the default VGA palette, then save the result as an animated GIF.
There's no point in example images, because the power of this tool is, you have full control on specifying how the conversion should be done. Just quantize to 256 individual colors? Sure. Convert to web-safe palette? Got you covered. Limit the colors to 8 for each 4 x 4 pixel blocks? Smooth sailing.
Full disclosure: it generates much better results than Imagemagick "png8:", and it handles animated PNGs too.
The readme is nice. My suggestion is to write a blog post that includes the two examples in the readme and the example you posted in your comment, and perhaps one or two more (let's say 5 or 6 in total). And post the blog article. I feel if it includes a few use cases and images, it would get more traction.
Thank you for your kind advice. But the thing is, I'm not a blogger guy, I've never ever written any blog in my life. If you take a look at my repos, you'll see my focus is on writing code.
Also I honestly don't know what to write.
I've always though that speeding up page load by shrinking images into indexed images is a common knowledge (smaller page = faster page), never occurred to me this needs explaining. I mean, there are already lots of tools for that (tinypng dot com, ImageMagick, pngquant, etc.), it's just neither can handle APNGs, much less animated WebP, so here's paltool to save the day.
As for the algorithms, all I've used (weighted color distance and median cut) has a loooong literature, explaining these much better than I could. I did not invent any of it, these are standard image processing algorithms, although I've used some tricks for better performance and some heuristics to increase output quality.
You say ttf and otf are the same, but that's not true, one utilizes quadratic curves, the other cubic curves. Also one is patented, the other isn't (most notably its bytecode vm).
Also, you say curve and spline is the same. They are not. Spline is a series of curves where you don't store the starting points, because those are the same as previous curve's ending points. So a spline requires less space to store than a list of the same curves, hope this makes sense to you.
I've also implemented a very fast font renderer, which supports bitmap, pixmap, quadratic and cubic curves, even mixed. I took a different path though: I've designed a very efficient font format, and provided a tool to convert ttf, otf, ps, etc. fonts into that format. This way the computational heavy parts are done beforehand, and the renderer can be small and fast (it's just a single header library, with source of 32k).
Using GPU for rasterizing is a good idea, but my font renderer is extremely portable so it's deliberately dependency-free and uses CPU integer arithmetic only. So it had a different design goal than yours, but still, it might be useful to study and it might give you ideas on further optimizations.
Good point. I should clean up the references between splines and curves to be more explicit. However, I think perhaps the oft and ttf point isn't relevant since I specifically say they are almost the same, and the specific details are exactly relevant so I left them out to avoid confusion.
Cool library and CPU integer arithmetic only is interesting.
> Warning: This overwrites data starting at sector 64! Use a dedicated blank USB.
This would be much more usable if you'd put a file system on the USB stick with a sufficiently large, empty, bianco file.
Note, you don't need to implement a file system driver. Just create it with a big enough file and use that file's starting sector instead of 64. You could even update the file's size with the data written (just one more sector write, and again, you don't need to interpret the file system, just patch one integer in a sector).
I'd recommend ext2 (FAT is not good, because it limits files to 2G, and exFAT is in patent hell). Create with mkfs.ext, add a large file with dd, then save the data as a bunch of "db" lines into your asm source. You'd then assemble the file system along with stage1/2 without the need to interpret what you're writing.
Oh, one more thing: some BIOS checks the first bytes of the boot sector as well (not just the last two bytes), so you should start your boot sector with a short jmp and a nop. Also it's not guaranteed that direction flag is cleared, add a cld after cli.
To get some ideas, here's a boot sector that loads an EFI PE/COFF executable from a FAT file system (without interpreting the fs), sets up long mode and executes it:
(Notes: written for the flatassembler, which uses a very very similar Intel syntax like nasm, and the 2nd stage EFI executable is written in C very carefully so it doesn't matter if it's loaded by this boot sector on BIOS or by the UEFI firmware, the same binary just works everywhere.)
As for developing EFI apps, I don't use EDK2, because it's messy and bloated, instead I've written my own UEFI SDK: https://gitlab.com/bztsrc/posix-uefi it's much easier to use, you might find it useful too.
Thanks for the incredibly constructive feedback! This is extremely helpful.
The jmp short + nop header and adding the cld instruction are excellent points. I will add those to the bootloader right away to ensure better BIOS compatibility and stability.
The pre-allocated dummy file trick on ext2 is a brilliant way to have a mountable filesystem without the overhead of writing a filesystem driver in Assembly. That solves the "overwriting arbitrary data" issue elegantly.
I will definitely look into posix-uefi. EDK2's bloat and memory footprint were my main concerns for the UEFI port, so a lightweight SDK is exactly what I need.
P.S. I use a translator to write this because I don't speak English. I really appreciate you taking the time to share these technical pointers!
The skrellm is a single process stack of system monitors which supports applying themes to match its appearance to your window manager, Gtk, or any other theme. It displays these system resource monitors on your desktop.
It is a minimal, multiplatform rewrite of gkrellm, because my distro dropped glib2 and gtk2 support, so I can't compile gkrellm any more (gtk3 rewrite is just a myth, couldn't find it on the official site), and none of the panels my DE has was as sophisticated as I'm used to with gkrellm.
I've checked multiload-ng (doesn't compile) and Conky (too bloated and doesn't compile either, couldn't set up its build env so many dependencies) which didn't work, so I had to implement my own truly lightweight version.
SKrellM is free and Open Source, licensed under GPLv3+, less than 400K single portable binary, hope you like it!
Do you have any source? I'm not french and all I can hear from the news is that France's nuclear electricity is cheap, for example:
https://thenextweb.com/news/france-energy-advantage-ai-data-...
Now I'm curious what the truth is. Are these articles just fake-news trying to ride the AI wave? (not suggesting, just asking)
reply