Header/footer scroll resets itself upon many actions #28298

New Issue

Chris Want · 2011-08-18T23:54:57+02:00

Chris Want commented

2011-08-18 23:54:57 +02:00

%%%I'm taking a lot of screen shots these days, and
after scrolling the header of a space to the way I
want it, I take my screen shot, and then I discover
that the header scroll has been reset to zero.
If I save my blend file, the header scroll resets to
zero. If I move the Blender window, the scroll resets
to zero.

Thanks,
Chris
%%%

%%%I'm taking a lot of screen shots these days, and after scrolling the header of a space to the way I want it, I take my screen shot, and then I discover that the header scroll has been reset to zero. If I save my blend file, the header scroll resets to zero. If I move the Blender window, the scroll resets to zero. Thanks, Chris %%%

Chris Want commented

2011-08-18 23:54:57 +02:00

Changed status to: 'Open'

Ton Roosendaal commented

2011-08-21 11:31:22 +02:00

%%%needs small tweak in re-calculate of header view...%%%

Anthony Edlin commented

2012-01-29 22:13:12 +01:00

%%%I've added a patch to the patch tracker that fixes this bug.

http://projects.blender.org/tracker/index.php?func=detail&aid=30023&group_id=9&atid=127%%%

%%%I've added a patch to the patch tracker that fixes this bug. http://projects.blender.org/tracker/index.php?func=detail&aid=30023&group_id=9&atid=127%%%

Lukas Tönne commented

2012-01-31 11:07:23 +01:00

%%%Doing a full reinit (clearing V2D_IS_INITIALISED) was added for by Ton a reason in r37206, to make sure dpi changes work correctly. So simply removing this is not a good idea. Also it only solves part of the problem, by avoiding reinit on move and resize of the main window.

It looks like the root of the problem is that when initializing the View2D tot rect size, it uses the initial area width. The actual, full width of the header is only known when the layout is resolved. So in that reinit the cur rect size is clamped to the visible area, which also resets any possible scrolling. This could be solved by somewhat releasing the strict scrolling requirements in headers.

However, in most of the cases described above (screenshots, saving to new file) what happens is that the active (mouse-over) area is made full screen, which temporarily enlarges the tot rect size. That in turn also resets the scrolling. So in order to really resolve this issue reliably this behavior of using the active area for file selection dialogs would need to be changed as well. I doubt that making such major design changes for this minor inconvenience would be a good idea.%%%

%%%Doing a full reinit (clearing V2D_IS_INITIALISED) was added for by Ton a reason in r37206, to make sure dpi changes work correctly. So simply removing this is not a good idea. Also it only solves part of the problem, by avoiding reinit on move and resize of the main window. It looks like the root of the problem is that when initializing the View2D tot rect size, it uses the initial area width. The actual, full width of the header is only known when the layout is resolved. So in that reinit the cur rect size is clamped to the visible area, which also resets any possible scrolling. This could be solved by somewhat releasing the strict scrolling requirements in headers. However, in most of the cases described above (screenshots, saving to new file) what happens is that the active (mouse-over) area is made full screen, which temporarily enlarges the tot rect size. That in turn also resets the scrolling. So in order to really resolve this issue reliably this behavior of using the active area for file selection dialogs would need to be changed as well. I doubt that making such major design changes for this minor inconvenience would be a good idea.%%%

Anthony Edlin commented

2012-04-03 21:38:25 +02:00

%%%You are correct it only solves part of the problem, it doesn't solve resetting on fullscreen, saving to new file, etc. All this patch really does is allow the dpi changing to work without haveing to clear V2D_IS_INITIALIZED. I don't agree that you can't just remove doing a full reinit, especially when you write a patch that fixes the reason for doing the reset. When Ton first did the dpi changes he actually reset every region not just headers, and all regions were resetting alot (on region resize, etc). Then he removed resetting on non-header regions because it wasn't needed.

The problem with header regions was that when you changed the dpi it changed the size of the region and the size of the cur rect without changing the size of the tot rect. This would work if the height was increased, but if the height was decreased it would always adjust the cur rect upwards (note this is ok for other regions because they use V2D_ALIGN_NO_POS_Y). The header draw code would begin, and once you called UI_view2d_view_ortho and initialized the blocks any later changes to cur or tot don't matter because you saved the projection matrix into the blocks.

There are several ways to fix this, I chose to simply adjust the cur rect downwards if the area uses V2D_ALIGN_NO_NEG_Y as it seemed the least intrusive. Clearing V2D_IS_INITIALIZED is basically an indirect and confusing way of just calling UI_view2d_totRect_set, so you could just directly call it someplace before the header drawing code begins for the same effect. You could also change the way blocks are drawn so you could initialize them, resolve the layout, adjust them if needed, then finally draw them after you set the tot rect for the view (this is actually the approach used by Bastien Montagne in a patch to fix this other bug: http://projects.blender.org/tracker/index.php?func=detail&aid=24343&group_id=9&atid=498)%%%

%%%You are correct it only solves part of the problem, it doesn't solve resetting on fullscreen, saving to new file, etc. All this patch really does is allow the dpi changing to work without haveing to clear V2D_IS_INITIALIZED. I don't agree that you can't just remove doing a full reinit, especially when you write a patch that fixes the reason for doing the reset. When Ton first did the dpi changes he actually reset every region not just headers, and all regions were resetting alot (on region resize, etc). Then he removed resetting on non-header regions because it wasn't needed. The problem with header regions was that when you changed the dpi it changed the size of the region and the size of the cur rect without changing the size of the tot rect. This would work if the height was increased, but if the height was decreased it would always adjust the cur rect upwards (note this is ok for other regions because they use V2D_ALIGN_NO_POS_Y). The header draw code would begin, and once you called UI_view2d_view_ortho and initialized the blocks any later changes to cur or tot don't matter because you saved the projection matrix into the blocks. There are several ways to fix this, I chose to simply adjust the cur rect downwards if the area uses V2D_ALIGN_NO_NEG_Y as it seemed the least intrusive. Clearing V2D_IS_INITIALIZED is basically an indirect and confusing way of just calling UI_view2d_totRect_set, so you could just directly call it someplace before the header drawing code begins for the same effect. You could also change the way blocks are drawn so you could initialize them, resolve the layout, adjust them if needed, then finally draw them after you set the tot rect for the view (this is actually the approach used by Bastien Montagne in a patch to fix this other bug: http://projects.blender.org/tracker/index.php?func=detail&aid=24343&group_id=9&atid=498)%%%

Ton Roosendaal commented

2012-10-25 14:53:33 +02:00

%%%Hi Anthony,

Sorry for ignoring this so long, I've been busy with a movie in the mean time :)

The patch in the tracker works fine for DPI changes, and code is much nicer, so I will add that.
However, the header scroll still resets on switching screens or using a fileselector - but only if you make that area 'full screen', which is correct for code (same area gets full and refreshes view).

This view2d code is flawed still. We ported too many things over from 2.4 in order to get things work quickly - resulting in code we can't manage well.

I hope you're still around, we can use people who like to dig in this part of our messy code :)%%%

%%%Hi Anthony, Sorry for ignoring this so long, I've been busy with a movie in the mean time :) The patch in the tracker works fine for DPI changes, and code is much nicer, so I will add that. However, the header scroll still resets on switching screens or using a fileselector - but only if you make that area 'full screen', which is correct for code (same area gets full and refreshes view). This view2d code is flawed still. We ported too many things over from 2.4 in order to get things work quickly - resulting in code we can't manage well. I hope you're still around, we can use people who like to dig in this part of our messy code :)%%%

Ton Roosendaal commented

2012-10-25 14:53:33 +02:00

Changed status from 'Open' to: 'Resolved'

Ton Roosendaal closed this issue

2012-10-25 14:53:33 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Header/footer scroll resets itself upon many actions #28298