-
Notifications
You must be signed in to change notification settings - Fork 122
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
Improve texture coloring on bar/area #1202
Comments
# [34.0.0](v33.2.4...v34.0.0) (2021-08-16) ### Code Refactoring * **cartesian:** cartesian rendering iteration ([#1286](#1286)) ([b2ae4f7](b2ae4f7)), closes [#1202](#1202) ### BREAKING CHANGES * **cartesian:** - `TextStyle.fontStyle` is no longer a `string`, it's the more specific `FontStyle` - For symmetry, `fontStyle` in word cloud is also switching from `string` to `FontStyle` - Certain text configurations included both `fill` and `textColor` for the text color; `fill` got removed, because `textColor` is part of the public `Font` type, and because `textColor` has clearer meaning than `fill`. Yet, some of the code used the `fill` property and/or made the `fill` property also mandatory. So, userland code needs to remove some `fill` property, and might need to ensure that the correct value is going into `textColor` - `getRadians` got unpublished - No attempt to draw a rect border if there's not enough width/height for at least the specified border width (ie. width/height being at least twice the border width)
🎉 This issue has been resolved in version 34.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
While this issue auto-closed due to mention of the partial solution brought by #1286 there is still much opportunity to refine the size responsiveness of pattern fill, referenced in the further improvements meta issue #1303. Once work continues, this issue can be reopened or a new one can be created. I've some preference for the latter, as, during the review process, we discussed specific approaches toward future improvements, such as options for integral (full, unclipped) tile counts for consistent aesthetic of the bar thickness coverage, and roughly constant ratios (eg. approx. tile pixel size) to go with it; and the attention we need to give to negative bars |
I think the idea of this issue was to make the patterns independent such that changing the size doesn't shift the values, as if it is masking a picture in the background, but that each follows their respective bar. |
Is your feature request related to a problem? Please describe.
A texture or a pattern should always start from the same point on the geometry.
When resizing, the texture/pattern should not move around.
Describe the solution you'd like
The texture should probably always start from the baseline, or anyway always start at the same point in the geometry.
In this case, for example, the dot pattern on every bar starts at a different x position. This can reduce the readability because the pattern effect introduces artifacts on how the bars are rendered.
We can also discuss if the texture should use:
Describe alternatives you've considered
n/a
Additional context
Needs as follow up of #1138
Kibana Cross Issues
Not yet used in Kibana
The text was updated successfully, but these errors were encountered: