-
-
Notifications
You must be signed in to change notification settings - Fork 405
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic scaling & Graph meter coloring (new) #714
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a quick note:
Please split the new functions for PrevPowerOfTwo and PopCount into their own commit. Also try to utilize configure.ac
to check for them and provide static inline
implementations directly in the header (XUtils.h
or Macros.h
both should work).
There's an example how to check for specific compiler features in configure.ac
to determine whether certain warning flags are supported. You should be able to work based on that example there.
Having the caption above the unit makes more sense IMHO. |
|
k. :)
As inline typically just a hint to the compiler it can still decide to ignore it. Also most recent optimizers do code folding anyway, thus would remove the parts imported from different code units upon linking. Also there's some more magic going on with linkers nowadays, thus I doubt this is a real issue with recent compilers. Compilers can still opt to ignore the inline anytime and will happily do if the code becomes too complex or too wasteful when inlining (unless forced to).
Similar argument with popcount: 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 call to such a function will receive a slowdown. Also most architectures by now have a NB: Modern compilers are usually better in optimizing your code, than you are. Better optimize the algorithm by replacing it with a better one than trying to be smart … |
If I have not read the disassembly of |
2cdcb94
to
60ca4f2
Compare
Did some tests with the Similar effects are likely visible with the |
prevPowerOf2(0) should (in theory) output 0, not 1. |
14e63c2
to
e0b6f94
Compare
@Explorer09 Why write everything onto screen directly instead of using |
It would break dynamic scaling. Look at Load average meter for example, the whole graph needs to be redrawn when the scale (or unit) changes. |
Sure, but those situations can be tracked/detected … |
@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 color scheme changes. Detecting when to clean the buffers like the cases above is too much work, and so I consider it doesn't worth the trouble. |
On the other hand, re-using existing code makes maintaining the code easier once it got merged. And in the current state I'm not too convinced that these 650 LOC of new code are in a state that makes maintaining them easy enough to justify the complexity in this code. Just skimming over I saw several routines, that are justifiably quite long. And I also understand you are hesitant to refactor major parts of that code after that much effort that went in. I had some PRs of mine that needed refactoring and bug fixing for about half a year until I could finally merge them. And even then there were small issues that needed to be addressed. So given the amount of code in this PR it should be one priority to ease maintaining the code and another one to have it working. Even if this sound's like I'm a killjoy here both are requirements to proceed with merging (this) new code. |
cd46429
to
3485b0d
Compare
First of all: Thanks a lot for picking up on this again! The new code works and it gives even more precision. Either way I am happy if the makes its way into master. |
0760ab7
to
24bd56e
Compare
This pull request introduces 2 alerts when merging 24bd56e into ed82ce6 - view on LGTM.com new alerts:
|
aa10e7c
to
17e8f97
Compare
@Explorer09: Here another fixup (for dab72f1): From 861c34bcc64b6462a22aab1680ff8aefcf14863a Mon Sep 17 00:00:00 2001
From: Benny Baumann <[email protected]>
Date: Wed, 3 Apr 2024 20:32:57 +0200
Subject: fixup! Update "total" value for non-percent bar meters
---
Meter.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/Meter.c b/Meter.c
index 5841231f..3cdaa1b5 100644
--- a/Meter.c
+++ b/Meter.c
@@ -203,11 +203,9 @@ ListItem* Meter_toListItem(const Meter* this, bool moving) {
static double Meter_computeSum(const Meter* this) {
double sum = sumPositiveValues(this->values, this->curItems);
- // Prevent rounding to infinity in IEEE 754
- if (sum > DBL_MAX)
- return DBL_MAX;
- return sum;
+ // Prevent rounding to infinity in IEEE 754
+ return sum > DBL_MAX ? DBL_MAX : sum;
}
/* ---------- TextMeterMode ---------- */
--
2.43.0
|
Extra comment lines and vertical spacing look okay to me. But I am not a fan of extra braces and indents.
I wrote the return lines separately in the hopes for a more visible commenting, but anyway, I can apply this. (It would be simpler to write |
You could skip those extra indents, but this would require
Fine too. |
0fb53b5
to
82d9cfb
Compare
52f4633
to
6c72f74
Compare
823ddfd
to
726b774
Compare
726b774
to
d5babe3
Compare
@Explorer09 FYI, will likely do #1387 before this one. |
84b4956
to
1e07509
Compare
1e07509
to
954080b
Compare
This property distinguishes meters that have a (relatively) fixed "total" value and meters that do not have a definite maximum value. The former meters would be drawn as a "100% stacked bar" or "graph", and the latter would have their "total" values updated automatically in bar meter mode. This commit is a prerequisite for the "Graph meter dynamic scaling and coloring" feature. Signed-off-by: Kang-Che Sung <[email protected]>
If "isPercentChart" of a meter is false, update its "total" value automatically. The "total" value should be finite in order to ensure the division works. The newly introduced Meter_computeSum() function will be reused by the "Graph meter dynamic scaling and coloring" feature. Signed-off-by: Kang-Che Sung <[email protected]>
This is a prerequisite for the "Graph meter dynamic scaling and coloring" feature. powerOf2Floor() will utilize __builtin_clz() or stdc_bit_floor_ui() (__builtin_clz() is preferred) if either is supported. popCount8() will utilize ARM NEON instructions and x86 POPCNT instruction if the machine supports either of them. I am not adopting the C23 standard interface stdc_count_ones_uc() yet, as I am not sure C libraries would implement it as fast as our version. Signed-off-by: Kang-Che Sung <[email protected]>
Rewrite the entire graph meter drawing code to support dynamic scaling and colors. Dynamic scaling is used for meter classes with "isPercentChart" set to false. The "total" of a graph meter will align to a power of 2 to ease the management of internal data structures. The colors of a graph are based on the percentages of item values of the meter. The rounding differences of each terminal character are addressed through the different numbers of braille dots. Due to low resolution of the character terminal, the rasterized colors may not look nice, but better than nothing. :) The code is designed with the anticipation that the graph height may be changeable at runtime. However no UI or option has been implemented for that yet. The graph height has a limit of 8191 (terminal rows). Signed-off-by: Kang-Che Sung <[email protected]>
Specifically 'PIXPERROW_*' and 'GraphMeterMode_dots*' constants. They were commented out rather than removed in the previous commit (for ease of code reviewing). Now this commit removes the constant defines for good.
954080b
to
5989bad
Compare
This pull request implements dynamic scaling support and a "stacked" color for Graph meters. In addition, the Bar meter drawing routine is slightly improved for dynamically expanding the "total" value when needed.
This code would replace the current, one-color graph drawing algorithm so that all Graph meters are drawn with colors.
The data structures and algorithms for the color graphs and dynamically scaling are brand new, totally reworked from #129 and the colors are intended to represent the meter data as close as possible. It still uses braille dots to display the graph, but they now have finer details (I think).
Caveats
double
(floating point) data type. It now stores the precomputed colors and braille dots instead, and the data are specific to a graph height setting.CRT.h
would become unused.Technical details
The following are potential features that can be implemented after this pull request, but I doubt if they are good ideas or if I have the ability to implement them:
%
,32K
,16M
, etc.), separate from the caption color. I was considering making the text blue to separate it from the cyan text of the caption.htoprc
file to specify the graph height. The settings UI would be the next step to implement.|#*@$%&
) can be reused for this.