Kang-Che Sung (宋岡哲)

@fasterit Zopfli is an encoder only and it's compatible with any DEFLATE decoder, Zopfli is, as far as I can see, the most aggressive DEFLATE-compatible encoder on the internet. It's...

@anthonyryan1 I played around with the [Efficient Compression Tool](https://github.com/fhanau/Efficient-Compression-Tool) you mentioned, and I was able to squeeze a few more bytes for the htop icon and the screenshot picture. ```...

Why not just pack it yourself?

1. I've done moving the caption to above the unit. It's an easy change. 2. The code for checking `__builtin_clz` in configure is also done. ``` AC_MSG_CHECKING(for __builtin_clz) AC_COMPILE_IFELSE([ AC_LANG_PROGRAM([],...

> > For any reasonable recent compiler the libgcc function will likely be optimized enough (and likely even use SSE2 when the system has it available), thus only the first...

Update: I figured out what to do with the popCount8 problem. Commit amended and rebased. See XUtils.h in commit b160428323c9f649fbaa7d32289b7ef9236d7673 to see what I mean. (Update (v3): 28b0a60521093f889882329081ce683eb36e9629)

> Did some tests with the `prevPowerOfTwo` function on [godbolt](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,selection:(endColumn:4,endLineNumber:19,positionColumn:4,positionLineNumber:19,selectionStartColumn:4,selectionStartLineNumber:19,startColumn:4,startLineNumber:19),source:'%23include+%3Climits.h%3E%0A%0Aunsigned+int+prevPowerOfTwo_Explorer09(unsigned+int+x)+%7B%0A+++for+(unsigned+int+shift+%3D+1%3B+shift+%3C+sizeof(x)+*+CHAR_BIT%3B+shift+%3C%3C%3D+1)+%7B%0A++++++x+%7C%3D+(x+%3E%3E+shift)%3B%0A+++%7D%0A+++return+(x+-+(x+%3E%3E+1))%3B%0A%7D%0A%0Aunsigned+int+prevPowerOfTwo_BenBE(unsigned+int+x)+%7B%0A+++x+%3E%3E%3D+1%3B%0A+++for+(unsigned+int+shift+%3D+1%3B+shift+%3C+sizeof(x)+*+CHAR_BIT%3B+shift+%3C%3C%3D+1)+%7B%0A++++++x+%7C%3D+(x+%3E%3E+shift)%3B%0A+++%7D%0A+++return+x+%2B+1%3B%0A%7D%0A%0Aunsigned+int+prevPowerOfTwo_CLZ(unsigned+int+x)+%7B%0A+++return+1+%3C%3C+(sizeof(x)*8+-+1)+-+__builtin_clz(x)%3B%0A%7D%0A'),l:'5',n:'0',o:'C%2B%2B+source+%231',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:armgtrunk,filters:(b:'0',binary:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'1',intel:'0',libraryCode:'0',trim:'1'),flagsViewOpen:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,libs:!(),options:'-O3',selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'ARM+gcc+trunk+(linux)+(Editor+%231,+Compiler+%231)+C%2B%2B',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4): > Depending on your compiler and architecture and settings any of the three variants at times produces the shortest assembly...

@BenBE > Why write everything onto screen directly instead of using `RichString` as buffers? Advantage would be that you could abuse double-buffering there to shift the graph by two units...

@BenBE The second reason for not using a RichString buffer is the use may change color scheme of htop at runtime, and the RichString buffer is not designed to reflect...

There is one visual problem that I wish to solve after the next rebase. In the screenshot I tried with the test data of 4 items, the value of each...