Build a text editor

[Olli]

Okay I can wait a test from a "4K" (135 lines) to know if there is no problem of speed (freeze or other)

Also, two technologic choices :

1) keep the height of each line up to 16 pixels and create the scrolling engine on this base.

2) modify each line height on the fly, depending of the font size of what it is displayed.

It is two methods fully different. I prefer the second one, which is more realistic and whom I already wrote an algo. But in this way, I will loose lots of you, because the algo is very strong. Unable to comment usefully : in this way, lots of schemes to tell the mechanism.

The first one, the problem is the step of 16 pixels : it is not beautiful. And I have no idea about the zoom... However the story of 4K, etc... No performance problem... Sure...

I will wait if anybody looks a performance problem with this small 3rd simulation.

And I will need a convention language to enrich the text, because the RTF language is absolutely not what I prefer. I d like a simpler language, an intuitive thing, which eases the write of a rich text.

Ex :

Code: Select all

//Arial//48//Green//Title of document
//Verdana//12//Black//
Introducing a concept of the headaches in our civilization has ever been considered as a __bold__strategy__ not to understand anything about the importance of all these flu.

[Axolotl]

Hi,
I am not sure if I catched the latest?
Maybe you should add a comment with version (counter) or similar.
So in maximized mode I see 130 lines. 4K-Monitor with 96 dpi (100%).

Observation:
In my opinion, scrolling is quite unacceptable compared to other editors (slow/not smooth).
Maybe the effect is because of the different background colors on every line.
White background is a little better, but still not eye friendly.

BTW: I never worked in maximized mode with my editors.

[Olli]

Interesting !
Howmany does your screen measure physically ?

[Axolotl]

entire (full) screen resolution: 3840 x 2160 Px
Well, you have to substract the taskbar-height and the window title height (maybe thats why onle 130 and a bit of line 131)

[Olli]

I said the adverb 'physically' : howmany inch ? Or howmany meter ?

My biggest screen had a diagonal of 80 meters, low resolution.
I tested a third method I shared 16 years ago. But I observe there is no synchronization link between Windows and the PureBasic program. Result : same effect as a ZX81, white horizontal band in the area which appears.

I think, natively, for the 4K, there are three ways : windowed openGL, windowed screen or full screen. These 3 ways allow the coder to set the synchronization.

If your screen is physically (= the size you can observe even when it is stand off) large, I am not surprised you never use the full screen to edit a text.

I factorized the line height value (actually 16 pixels on the previous source code) onto a variable : this will ease the change of this row height.
For your screen, we have two choices :
1) change the row height and test if a smaller quantity of rows displayed simultaneously on the screen (bigger font size so) restores the smoothness, and grows the displaying speed;
2) prepare a functional bottleneck to change easily the logical device target (windowed text versus accelerated screen).

Thank you for the approach between the page queue and the system task bar : it is a little bit more complex than a simple substraction.
a0) prepare the bottom or the top (depending of the key cursor direction) text line to insure ourselves this text line will be completely displayed (no height troncature). Adding (if from top to bottom) or substracting (if from bottom to top) each row height . Ever calculates, but displays only if it is not the first cycle (toward vertical sync)
a1) get the future row ("FR") height ("FRH") to be displayed, which is actually the first fully hidden row.
a2) Check the vertical overlap ("VOL") between ("delta" difference) the FR Y value and the bottom scope Y value. If delta = 0 then overlap is true. SHIFT = FRH else SHIFT = delta
a3) substract (if from down to up) or add (if from up to down) each row height with the SHIFT variable, displaying each of them, (so : calculates plus displays).(backward vertical sync)
a4) (next scroll cycle) go to a0 while the scrolling is wanted (arrow key, mouse wheel, etc...) .

As you can see, the process has a symetry, depending of the binary direction, so the code will be compacted.

As all these sums (positive or negative) are able to be predicted, all these sums won't be calculated on the fly, but on each scope resizing, or on each font size change.

This is the method #2 (shortly described above in this page). A scrolling of rows whom the heights are not equal not prime between them.

I shared a source code in the trick n tips (Or feature request, I do not remember) section in 2023. It was a blend of the 2 methods (what the row heights are equal or not), but the row heights was prime between them. (= no back zoom compatibility). As there was no opinion, I decided to delete it any days after. The most tooled here have got so this source code : it is very well structured (only one very big structure), but absolutely everything is commented in this big structure, my friends who have a "good automatic memory" !

But no back zoom (to the one-pixel row height preview), and no predictive cache, in this old very good code. So the future source code will be strangely short and complex.

The result for your eyes on 4K will be as bad as actually, but it is not a problem : the functional bottleneck described above will solve this synchro gap.

[Axolotl]

Oh, l see. It is a desktop monitor of 28 inch. Not fancy.
You do not have to think about a solution for me. I wanted to share some of my observations, thats all.

[Olli]

I go forward step by step, not for you, strongly, but for the owner of 4K in general. I find good to receive such remarks. Thanks to you !