Bugzilla – Bug 15557
Scrolling issue: line is horizontally split in two, not scrolling in sync
Last modified: 2010-04-08 17:27:01 UTC
When a showBriefly popup is shown, and an element which is only partly hidden by the popup starts scrolling, only the visible part will scroll. The hidden part will start scrolling as soon as the popup is closed. But as the lower part already has scrolled a bit, the line is horizontally split in two. I can only reproduce this in one particular menu: Deezer Search. Maybe it's related to its using icons, and long, scrolling text. - select an item which is slightly below the center of the screen - press & hold -> add to playlist - showBriefly telling you about the add action will be shown - if the element starts scrolling and is partly hidden by the popup you'll see that only part of it is scrolling - as the popup disappears the remainder start scrolling too, but with an offset of a few pixels
Created attachment 6474 [details] split line
I am the wrong person to address this bug
== Auto-comment from SVN commit #8589 to the jive repo by fmueller == == https://svn.slimdevices.com/jive?view=revision&revision=8589 == Bug: 15557 Description: Fix horizontal scrolling issue when menu widgets (labels) are not snapped to grid (smooth scroll on Fab4)
== Auto-comment from SVN commit #8590 to the jive repo by fmueller == == https://svn.slimdevices.com/jive?view=revision&revision=8590 == Bug: 15557 Description: Fix horizontal scrolling issue when menu widgets (labels) are not snapped to grid (smooth scroll on Fab4)
== Auto-comment from SVN commit #8591 to the jive repo by fmueller == == https://svn.slimdevices.com/jive?view=revision&revision=8591 == Bug: 15557 Description: Fix horizontal scrolling issue when menu widgets (labels) are not snapped to grid (smooth scroll on Fab4)
I'm afraid this bug is not limited to animated text in menus. Its any redrawing of widgets which are part of a menu. For example if something updates the icon then this also only updates partially if the scrollOffset is non zero. I think we need a solution which handles the generic case of widget asking to be redrawn within a menu - will think about it...
Created attachment 6576 [details] Demo of redraw problem for icon updates Attached shows the problem with icons - it should change the whole icon to a new colour 3 times a second, but only partially updates the icon if the menu is scrolled to be part way beteen two snapped positions.
Created attachment 6577 [details] broken label animation in group widget of title I've been working on bug 12013, which is adding a button treatment to title text in SlimBrowse menus that have context menus, and have seen what appears to be a similar issue. If this is the same problem, after I check in this code today it will be a one line change in SlimBrowser to reproduce, as I'm working around the issue by turning the widget's animation off. If it's not the same problem, sorry for the noise here :)
Created attachment 6578 [details] Proposed patch Felix: Attached is a proposed alternative to the previous patches for this bug. The problem comes from widgets asking for the wrong region of the screen to be redrawn if they are inside a menu which is using smooth scrolling. (as smooth scrolling doesn't move the widget positions, it applies an offset at draw time) The patch aims to detect when a widget is asking for the wrong region to be drawn and to adjust it by the current smooth scrolling position. As this creates more work to do at redraw time, I've added more state into the widgets within a menu so that the additional work is minimised and also avoided doing this on non touch devices. Does this fix the known problem cases for you - looks to pass my tests.
Ben - I'm not convinced that's the same bug. However you may want to apply the jive_framework.c part of my patch and set it to enabled. This will draw a box around the dirty area of the screen. Does the dirty area clip the text? (dirty area is the bit which gets updated on the screen, if its in the wrong place then the screen doesn't get updated)
Ben - I can reproduce your problem and I think its differnt. Its definately the dirty region of the screen being set wrong though (if you compile in my debug code you see a box round the bit which moves) Will look at the cause...
== Auto-comment from SVN commit #8602 to the jive repo by fmueller == == https://svn.slimdevices.com/jive?view=revision&revision=8602 == Bug: 15557 Description: Remove not so clever fix.
== Auto-comment from SVN commit #8603 to the jive repo by fmueller == == https://svn.slimdevices.com/jive?view=revision&revision=8603 == Bug: 15557 Description: Much better fix for the split scrolling issue (actually fixing the dirty area). Thanks Adrian.
(In reply to comment #9) > Created an attachment (id=6578) [details] > Proposed patch > > Felix: Attached is a proposed alternative to the previous patches for this bug. > > The problem comes from widgets asking for the wrong region of the screen to be > redrawn if they are inside a menu which is using smooth scrolling. (as smooth > scrolling doesn't move the widget positions, it applies an offset at draw time) > > The patch aims to detect when a widget is asking for the wrong region to be > drawn and to adjust it by the current smooth scrolling position. As this > creates more work to do at redraw time, I've added more state into the widgets > within a menu so that the additional work is minimised and also avoided doing > this on non touch devices. > > Does this fix the known problem cases for you - looks to pass my tests. Hello Adrian I've verified your patch on desktop SP and Touch itself and it looks good also with the original Deezer test case Michael reported. Thank you very much for your time and your patch. Felix
Adrian and Ben have talked about a similar issue, but Ben will open a new bug for it.
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release. If you are still seeing this issue, please let us know!