• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category User Interface
  • Assigned To
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by epithetless - 2009-10-11
Last edited by tomers - 2009-10-12

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

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.

Closed by  tomers
2009-10-12 16:33
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Fixed in r23132

Thanks Teruaki Kawashima (teru) for the solution!

It is most probably related to r23021 - “Handle text scrolling in RTL”

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.

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.”]

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.

Could you try this patch ( reverts r23022) and see if it fixes the problem ?

teru commented on 2009-10-11 11:58

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.

Fix patch. Obviously does not fix this issue yet (RTL mode - Hebrew, file viewer, long English folder name)

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?

teru commented on 2009-10-12 04:11

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 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.


Available keyboard shortcuts


Task Details

Task Editing