I'm going to draw as many lines that will fit in the textbox then offset the array by the number of lines required. Doing this would mean I can't have smooth scrolling.
Both approaches I mentioned should perfectly allow smooth scrolling, provided the scrolling overhead isn't so large that it slows down FPS below room_speed.
The "visible text on surface, draw entire surface" approach (the original approach) adds a small extra overhead to scrolling, but makes for shorter redrawing overall.
The "entire text on surface, draw part of surface" approach has nearly no scrolling overhead, but can be heavier when you need to redraw a surface because it stopped existing.
As I see it, the overhead of redrawing visible text on scrolling should be so negligible that "visible text on surface, draw entire surface" won't significantly affect FPS, especially if you limit it to visible lines only.
For example, if you know that each line height is 16px, the visible text area height is 80px and that you have a scrolling offset of 38px, then:
- the first line you want to draw is
max(0, floor(38px / 16px)) = max(0, 2) = 2nd line
(with 0th and 1st lines not drawn)
- the last line you want to draw is
min(max_lines - 1, ceil((38px + 80px) / 16px) = min(max_lines - 1, ceil(118px / 16px)) = min(max_lines - 1, 8)
This should make the drawing optimised to the point where you won't need to worry about redrawing cost, making the scrolling smooth.
Can I ask when you code something do you just code exactly what you need no more, no less or do you use some foresight about features that you don't need now but may in the future.
I usually try to apply some minimum amount of foresight. Obviously, I try to code no less than what I need, but I may end up writing a more general code that's able to do more than what I immediately need.
I generally don't write
extra code for features not needed at the moment, but rather try to write code that'll make adding these extra features easier. On the other hand, I generally try to write the original code in a parameterised way (e.g. using "visible_lines" parameter, or maybe calculating min and max line based on line height and visible area height), as opposed to putting 5s everywhere because I expect no more than 5 lines at the moment.
See also:
Inventor's paradox.
Don't know what exactly do you mean by "features that you don't need now but may in the future". Is it about the horizontal scrolling?
Personally, I wouldn't add the extra code to handle horizontal scrolling unless I
knew I need it, on the grounds that:
- I could easily adapt a properly written vertical-scrolling-only code to horizontal scrolling
- I will likely avoid the need for horizontal scrolling by design, because trying to see/read a whole that's both horizontally and vertically scrolled is extra annoying, as opposed to seeing a whole that needs vertical scrolling only
- simply put: just because I'm able to write horizontal scrolling doesn't mean I have to
Mind, I refer to horizontal scrolling in text boxes specifically, and text is generally better wrapped than horizontally scrolled. Note that text is usually
linear in nature as well, i.e. you read a single sequence of words in a specific order, instead of jumping sideways. Then again, you have something like source code which benefits from no word-wrapping, but even then the code is easier to read when your lines are broken down in a way that no horizontal scrolling is needed.
If I was working with something like a level map instead, I would allow horizontal and vertical scrolling alike, because there's no reason to arbitrarily limit one or other dimension of a
grid-like entity like level map.