Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#10670 - The first letter of a scrolling line starts to appear at the end of the line

Attached to Project: Rockbox
Opened by David Thacker (epithetless) - Sunday, 11 October 2009, 10:42 GMT+2
Last edited by Tomer Shalev (tomers) - Monday, 12 October 2009, 18:33 GMT+2
Task Type Bugs
Category User Interface
Status Closed
Assigned To Tomer Shalev (tomers)
Player Type All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

Somewhere between r23021-091009 and r23059-091009 (the narrowest range I am able to investigate via daily builds), scrolling lines of text began to exhibit a bug where a fragment of the line's first letter appears at the end of the line.

For instance, a line will scroll to display text like the following:

A Line of Text is Scrolling in This Example/

...where the "/" at the end is the beginning of the first letter "A".

This behavior is consistent throughout the system, in the menus as well as in the WPS', and it continues to exist as of r23091-091011. My suspicion, from looking at the change log for that period, is that this bug is in some way related to the commits involving RTL implementation, but I unfortunately lack the expertise to confirm that.
This task depends upon

Closed by  Tomer Shalev (tomers)
Monday, 12 October 2009, 18:33 GMT+2
Reason for closing:  Accepted
Additional comments about closing:  Fixed in r23132

Thanks Teruaki Kawashima (teru) for the solution!
Comment by Tomer Shalev (tomers) - Sunday, 11 October 2009, 11:24 GMT+2
It is most probably related to r23021 - "Handle text scrolling in RTL"
Comment by David Thacker (epithetless) - Sunday, 11 October 2009, 11:55 GMT+2
While r23021 had its own issues (i.e. text turning to gibberish characters on the return scroll) that have since been fixed, the text-wrapping bug described above was not yet present in it...so I have to believe a later revision (perhaps even the very next one) is the cause of this particular problem.
Comment by David Thacker (epithetless) - Sunday, 11 October 2009, 12:02 GMT+2
r23022 deals with bi-directional scrolling specifically, and it is during bi-directional scrolling that this bug presents itself...so perhaps that's worth a look?

[r23022: "Fix a bug in a bidirectional text scrolling; s->offset doesn't need to be set when backward scrolling starts. This fixes bidirectional scrolling in
RTL and for certain file-names in LTR."]
Comment by MohamedTarek (mtarek16) - Sunday, 11 October 2009, 13:03 GMT+2
Yes the problem is with 23022. Apparently it happens to certain file names only (at least what I get here) so probably why I missed it.
Comment by MohamedTarek (mtarek16) - Sunday, 11 October 2009, 13:25 GMT+2
Could you try this patch ( reverts r23022) and see if it fixes the problem ?
   text-scrolling.patch (0.6 KiB) 
 firmware/drivers/lcd-bitmap-common.c |    1 +
 1 file changed, 1 insertion(+)

Comment by Teruaki Kawashima (teru) - Sunday, 11 October 2009, 13:58 GMT+2
An idea of fix. this revrets r23021 and r23022, and adds offset handling to depper function.
This should fix the issue but may affect other non-scrolling putses with offset.
It also fixes wrong selecter drawing.
   lcd-bitmap-common.patch (2.7 KiB) 
 firmware/drivers/lcd-bitmap-common.c |   16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

Comment by Tomer Shalev (tomers) - Sunday, 11 October 2009, 22:42 GMT+2
Fix patch. Obviously does not fix this issue yet (RTL mode - Hebrew, file viewer, long English folder name)
   lcd-bitmap-common.patch (2.9 KiB) 
 firmware/drivers/lcd-bitmap-common.c |   20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

Comment by David Thacker (epithetless) - Monday, 12 October 2009, 00:37 GMT+2
Well, I'm now noticing that -- somewhere between r23111-091011 and the current build (r23121-091011) -- the bi-directional text-wrapping bug has been replaced with a different one; on the return scroll, the beginning of a line of text now turns to gibberish characters and then the line jumps back to the end. Incidentally, this same behavior was happening with r23021 (which predates the bi-directional text-wrapping bug).

I assume r23118 ("Revert r23021, since it broke non-RTL scrolling. RTL scrolling still needs fixing") is the culprit? Should I start a separate bug report for this?
Comment by Teruaki Kawashima (teru) - Monday, 12 October 2009, 06:11 GMT+2
woops, sorry. somehow my previous patch doesn't included reverting r23022.
this is correct and updated one. almost equivalent to tomers' one as reverting r23022 is done in r23118.
   lcd-bitmap-common.2.patch (2.9 KiB) 
 firmware/drivers/lcd-bitmap-common.c |   20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

Comment by Michael Chicoine (mc2739) - Monday, 12 October 2009, 16:48 GMT+2
lcd-bitmap-common.2.patch fixes the bi-directional scrolling problem described by David Thacker (introduced in r23118). I have not seen the original problem reported by David, so I can't comment on whether or not it has been fixed.

Loading...