Area splits resizing issue when resizing window by small increments #19691

New Issue

Damien Plisson · 2009-10-20T10:24:04+02:00

Damien Plisson commented

2009-10-20 10:24:04 +02:00

%%%This issue happens when you resize the window by very small
increments (e.g. <5 pixels)

When you reduce the size of the window, all areas reduce their
size to, but it doesn't seem to be proportional though. Like
the right column (the one with the properties and outliner spaces
on 2.5 default view) is reduced more than the ones more on the
left.

It becomes weird when you increase the size (width in this example)
by small increments : the right column width continues to decrease
!

This looks like a rounding issue in the screen subdivision system that uses integer coords for split (from Ton's note).
One solution might be to maintain spaces relative size values
independent of window/resolution size, like a percentage, for
easing this spaces size computation after window resize, or using floats instead of integers?

This bug is a show stopper for the "live resize" feature,
that is having window contents redrawn continuously while the
user is changing its size.
(This feature is the one that makes lots of window size changes
by small steps)

This bug already existed in 2.4x releases.

Anyway, the "live resize" is a nice to have feature, so a fix for this bug is not of high priority%%%

%%%This issue happens when you resize the window by very small increments (e.g. <5 pixels) When you reduce the size of the window, all areas reduce their size to, but it doesn't seem to be proportional though. Like the right column (the one with the properties and outliner spaces on 2.5 default view) is reduced more than the ones more on the left. It becomes weird when you increase the size (width in this example) by small increments : the right column width continues to decrease ! This looks like a rounding issue in the screen subdivision system that uses integer coords for split (from Ton's note). One solution might be to maintain spaces relative size values independent of window/resolution size, like a percentage, for easing this spaces size computation after window resize, or using floats instead of integers? This bug is a show stopper for the "live resize" feature, that is having window contents redrawn continuously while the user is changing its size. (This feature is the one that makes lots of window size changes by small steps) This bug already existed in 2.4x releases. Anyway, the "live resize" is a nice to have feature, so a fix for this bug is not of high priority%%%

Damien Plisson commented

2009-10-20 10:24:04 +02:00

Changed status to: 'Open'