Skip to content

auto bounds X/Y indepented#77

Open
gravl4 wants to merge 1 commit into
emilk:mainfrom
gravl4:patch-1
Open

auto bounds X/Y indepented#77
gravl4 wants to merge 1 commit into
emilk:mainfrom
gravl4:patch-1

Conversation

@gravl4

@gravl4 gravl4 commented Feb 10, 2025

Copy link
Copy Markdown

X and Y was link in autobound mode.
problem example:
y 1.0 1.0 1.0
x 17777780000 17777880000 17777980000 (as timestamp in us) autobounds Y is 10000000

X and Y was link in aoutobound mode. 
problem example:
y  1.0 1.0 1.0
x 17777780000 17777880000 17777980000 (as timestamp in us)
autobounds Y is 10000000
@oscargus

oscargus commented Mar 3, 2025

Copy link
Copy Markdown
Contributor

I see that the current behavior may not make much sense, but the change is basically introducing dead code.

Look at the first change, it will only happen if bounds.width() <= 0. With your change, you use is_valid_x(), which is
self.is_finite_x() && self.width() > 0.0. Hence, is_valid_x() will never be true in this branch, so it will always take the other branch and set it to 1.

One may argue what the "best" width is to set here though. The current guess is that if width is negative or zero, set it to height (which gives an aspect ratio ~ 1), but there are clearly cases where it is a bad choice. On the other hand, always selecting 1, which is the current approach, may be just as bad in some situations.

@kitizz

kitizz commented Dec 10, 2025

Copy link
Copy Markdown
Contributor

I agree with @oscargus
Auto_bounds doesn't have to be all the things for every person. I think the problem here might better be solved using .auto_bounds([true, false]) and taking manual control over the Y bounds in the app logic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants