Details
Diff Detail
- Repository
- rB Blender
- Branch
- arcpatch-D4054 (branched from master)
- Build Status
Buildable 3228 Build 3228: arc lint + arc unit
Event Timeline
@Amit Sari (Hamitos): I added a revision here for your diff.
@Campbell Barton (campbellbarton) or @Brecht Van Lommel (brecht): Can you check if this is ok?
Am not keen on looping over all lines for every redraw just to show horizontal scroll. Could this be limited to only looping over lines being displayed?
Hmm you're right.
However I think looping over visible lines only will cause weird behavior e.g. Jumping left horizontally when scrolling away from the longest line.
I added longest_line_length to the drawcache instead.
I tried updating this diff but it kept forcing me to create a new revision.
The updated result of "git diff" is attached.
Added longest line length to the drawcache so we don't need to loop over all lines every draw call.
This patch measures length in bytes which doesn't work properly w/ multi-byte characters, try paste this into the text editor for eg:
λλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλ
We could apply the patch with this as a known limitation, or calculate the length with BLF_width which is much more expensive (don't think it's worth it).
Using multi byte characters allows you to scroll too far, not stopping you from seeing all the text.
So i'm fine with it being a known limitation (Freedom?).
Looked into this and it looks like it can be implemented without per-redraw overhead, suggest to support multi-byte/column characters like this:
- BLI_str_utf8_char_width_safe can generate the number of characters.
- This can be cached in TextLine.cache_column_len (rename existing blen which isn't used).
- Lazy initialize it when looping over the lines, eg: check TextLine.cache_column_len == 0 and the string isn't empty, then initialize it.
- Any edits to the string set the TextLine.cache_column_len to zero.