See IMAGE_DECODE_SPEED_PNG. I believe we've hit this before, and it may be back because of the text "Click on a bar to resize the yAxis size". Perhaps it is time to abbreviate these numbers. I can't read "723444992", so the scale at the bottom is useless as soon as the values there exceed ~10000. Can we please render it as "723K"?
Increased the x-axis labels space. As for the abbreviate labels, "723444992" could be "723444k" or "723M", right? Are these labels unique or do we sometimes could get two "723M"?
(In reply to Paulo Pires from comment #1) > Increased the x-axis labels space. > As for the abbreviate labels, "723444992" could be "723444k" or "723M", > right? I think 723M (i.e., displaying three sig-figs) beats "723444k". > Are these labels unique or do we sometimes could get two "723M"? I feel like this is something you ought to be able to check. It's not going to be a problem on linear histograms (you'd need more than 1000 buckets), but it could conceivably be a problem on exponential histograms. We could do some math to find out how many buckets you'd need, but first we'd have to understand exactly how exponential histograms' buckets are distributed. One concern I have about using "K", "M", and "G" is that it'll be confusing with values which are already in milliseconds or kilobytes. For example, image decoding speeds are reported in KB/s. But the bucket labeled "10K" would in fact represent 10MB/s! The solution to this would be to have telemetry understand our units, but I don't know if we want to go there just yet. Maybe if we used engineering notation (e.g. 42 x 10^3), that would be good enough.