htop
htop copied to clipboard
htop-dev
Allocate GraphData buffer dynamically
I occasionally run htop in a full-screen terminal on a wide monitor, which had been producing a clunkily truncated CPU graph in the header section:
Bumping METER_GRAPHDATA_SIZE up to 1024 resolves the problem.
I'm not sure of it's a good idea to expand METER_GRAPHDATA_SIZE unconditionally in all htop builds.
The better solution would dynamically allocate that memory and resize if necessary.
I'm not sure of it's a good idea to expand METER_GRAPHDATA_SIZE unconditionally in all htop builds.
Just due to the added memory consumption, or for some other reason? It'll increase the values array in the GraphData struct from 2K to 8K, though it's not like there should be lots of instances of that running around (one per active graph-mode meter), so I'd expect the difference to still be in "pocket change" territory for the kinds of systems htop is typically used on.
The better solution would dynamically allocate that memory and resize if necessary.
Ideally, sure, but that would also have to factor in reallocating on SIGWINCH and such; I'll take a glance at what implementing that would involve, but if it ends up taking longer than I have to invest in it in at the moment I'd still be in favor of a simple one-line patch to improve on the status quo...
...okay, the dynamic-allocation approach turned out to be simpler to implement than expected, so I guess we might as well go with that.
@zevweiss I think I'll incorporate your dynamic allocation change to my "colored graph" proposal (#714 ). With the colored graph feature, the GraphData buffer would need to be dynamically allocated anyway. Let's avoid duplicated efforts.