-
Notifications
You must be signed in to change notification settings - Fork 360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Line numbers improvements #2090
Conversation
…rmance improvements.
IMO lets just merge this soon. We can do performance experiments and make simplifying changes in follow up PRs if necessary. The split into a contained class makes this very clean and easy to do (thanks @guang-lin 👍 ) |
Your opinions are also reasonable. If there is anything inappropriate, you can adjust it. Additionally, it was your suggestions that led to significant improvements in these codes, with many ideas that I had not anticipated. I have gained a lot, thank you @harshad1 . |
CharSequence deleted = s.subSequence(start, start + count); | ||
matcher = pattern.matcher(deleted); | ||
while (matcher.find()) { | ||
_maxNumber--; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we are going to keep this I suggest
_maxLineNumber += TextViewUtils.countChar(s, start, start + count, '\n')
_maxLineNumber -= TextViewUtils.countChar(s, start, start + count, '\n')
Simpler, faster, avoids need for creating a matcher and subsequence etc etc.
No need to even do the if (before == 0 && count > 0)
if we do this
_paint.setTextSize(textSize); | ||
} | ||
|
||
public int getNumberDigits(int number) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Min(Integer.toString(number), 5)
?
} | ||
|
||
public void setTextSize(float textSize) { | ||
if (_lastTextSize != _paint.getTextSize()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checking inequality has no value here.
// Draw the line numbers | ||
_paint.setColor(Color.GRAY); | ||
final int size = _lineIndex.size(); | ||
for (int i = 0; i < size; i++) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I had 2 loops with an ArrayList is because the first loop computes both the maxLineNumber and the number y positions.
If we are going to compute max line number in a text watcher, then this loop can be combined with the first one and we can eliminate the need for the ArrayList and _startNumber etc etc
I agree with your opinions. |
Can I do anything to help get this merged |
I made some adjustments based on your suggestions, and I will submit later. |
app/src/main/java/net/gsantner/markor/frontend/textview/HighlightingEditor.java
Show resolved
Hide resolved
I am trying to do some performance profiling and here is what I see: On a smaller file the total time to onDraw (including super) takes ~3000us of which the line numbers part takes ~500us
Ignore this, I accidentally tested the wrong branch :( |
I tried this on my rewrite too. It works with the large file and here are the numbers:
all numbers are in microseconds and are for a file with 10440 lines and 601017 characters |
After more testing, and looking at the current code. I think this is ready to merge. IMO we should still investigate ways of making line numbers much faster (there is still some lag with very large files). But it is good enough to merge now |
I agree, at least it is fine now, and there may not be significant improvements in the short term. |
Putting this down here for future reference. One idea is to maintain the newline indices. Possibly by subclassing the DynamicLayout class This way we would not have to do change tracking in the editor itself and would not have to iterate from the top to find current line numbers |
One other thought (for this pr, not the future). Currently we redraw if the visible rect goes out of the last drawn area (3x current height). We should instead redraw if we go 50% (say) from last drawn area. The current system will not redraw until we are outside the drawn area. We should instead redraw slightly before we are outside the drawn area. Easiest way to do this is make the last drawn rect 25% smaller than the actually drawn area. |
Ia there a viable open todo here which would be a reason to not merge it? I would like to merge everything to master and make sure that other PRs/improvements not get into huge rework needs due the amount of changes :D. Regarding performance, sure good to improve but at the end the feature is disabled by default anyway - so shouldn't hurt people unless they active enable this :-). |
The other PRs/improvements should all be included, these changes are based on the last commits of other PRs/improvements. |
Thanks everybody, I merged everything to master now |
@gsantner @guanglinn This PR appears to have broken image rendering in view mode. Still investigating |
I tried just now, it's true, but it works well in my develop branch. I will help investigate it. |
I believe I have solved the issue. Look at latest commit in |
(1) avoid unnecessary loops;
(2) avoid unnecessary parameter updates.
based on #2088, #2062