Counter Widget Rendering

[eradman]

The Counter visualization is relatively simple, but the method it uses to format text is very imporant since it often a prominent part of a dashboard.

In Redash 10, the counter was scalled using transform() to fit within the height and widge of the visible space. This caused text to wrap even if there was ample free horizontal space. To solve this we merged a change that modifies the font-size base on the clientHeight of the parent container.

This works very well for some use cases, but we need to think more carefully since the counter is used to display different kinds of information:

• Visuallization may contain 1, 2, or 3 lines of text (Label/Value/Target Value)
• Values may be a short number or more descriptive text

Any individual change we make will likely improve the display for some, and worse for others, so there probably isn't a single correct method. Some considerations:

1. Allow user to select scalling method? (width/height/area of parent container)
2. Allow user to bias the scaling method with a "sale factor"
3. Allow user to specify a fixed font size?

We also need to test the rendering using a HiDPI display (window.devicePixelRatio=2)

Below are some screen shots before and after recent commits:

---

Redash 10.1.0:

After commit 2795e1b

After commit 593b6ae

[justinclift]

Well, what is the end result (for users) when it's working optimally?

Maybe something like "2/3 of width and height taken up"?

If we can figure out the goal we're after, we should be able to think that backwards through how to implement it.

[justinclift]

@myonlylonely This discussion will probably be relevant to you. 😄

[myonlylonely]

The text size in the dashboard and embed queries is still very small. no matter on a HiDPI or a non-HiDPI screen.
This is a embed query, The size is not correct on both HiDPI or a non-HiDPI screen. So this problem may not related to HiDPI at all, but something else.

[justinclift]

Is there some way for us to get the available space (vertical, horizontal) inside the widget as a first step?

With that, we could probably then try and figure out how much of that space we want to use (maybe 2/3 or 3/4 of whichever dimension is largest?), then work out how big the font needs to be for that to happen.

Line wrapping and/or line breaks could make for an interesting challenge though.

[eradman]

One of the challenges is this: in some conitions there is no vertical space alotted to the visualization container:

• Tight horizontal width (mobile view)
• Visualization preview
• Embeded query

The chart visualization asserts it's own minimum height:

.chart-visualization-container {
  height: 400px;
  overflow: hidden;
}

In Redash 10 the counter font size was fixed at 80px so that it would make room for itself. Here is what the DOM looks like in mobile view:

If we follow the same pattern for the counter we should set a minimum height and then we can figure out the right math for the font size.

[eradman]

Based on the feedback on #6552 I think the mistake I'm making with font scaling is that the relationship between client height and font size should not be linear.

My first formula:

SELECT least(80, 8 + (size / 8)) AS "fontSize", size AS "clientHeight"
FROM generate_series(0, 800, 20) AS size

But to somewhat mimic what the transform() was accomplishing in Redash 10 it should be a power factor

SELECT 6 + (2.5 * pow(size, 0.5)) AS "fontSize", size AS "clientHeight"
FROM generate_series(1, 800, 20) AS size