High performance text component

[Joseph Andresen]

Hey Andre!

This sounds pretty exciting!

There are many mechanisms in place for drawing text efficiently. 

I would encourage you to concentrate on what text is on the screen at any given moment. If a list view has a million items and you can only see 10 at one time, it has virtual items that are filled as needed.

I see your text editor being organized the same way. There are only a given amount of lines per "file view", and your task would be to manipulate the text on these lines. I am not so sure I would use canvas for this particular part of the problem.

Perhaps some of our text guys have some thoughts.

Good luck!

-Joe



On Aug 2, 2012, at 7:52 PM, André Thieme <a.thieme at freenet.de> wrote:

> I would like to develop an editor component, think of NetBeans/Eclipse.
> There should be a surface on which one can display sharp LCD text. Lots
> of text. Users may wish to open 40 MB .csv files, perhaps on top of 200
> opened code files, of which some may contain 8k LOC.
> 
> 
> So far I have thought about different strategies:
> 
> 1) A Group filled with javafx.scene.control.Label or
> javafx.scene.text.Text instances. This makes it very easy to detect
> where exactly a user clicked. It allows for giving each word or even
> symbol its own color, font, style, etc.
> 
> This is obviously a difficult approach. The corresponding scenegraph
> might contain hundreds of thousands of nodes and won’t perform well.
> 
> 2) WebViews.
> Those allow us also to colorize and style each word or symbol. But I do
> not know yet, how much control it will give me. Can I overlay words with
> my own graphics? For example, I may want to draw a pulsing elipse around
> a specific word, to draw the attention of the end user to it. I would
> have to know the exact coordinates of each single words. The bounds so
> to speak, baseline, etc.
> 
> Also: how well do WebViews scale if I have 200+ of them in a ScrollPane?
> 
> 3) Canvas + fillText
> I tried this one, and it is pretty performant. On my laptop I can write
> 15k words on a big Canvas in only 30 msecs. Unfortunately Canvas can at
> the moment only use “Gray” as Font smoothing style, not “LCD”. But while
> this may come in future versions it has two other limitations:
> it does not deliver boundaries information when fillText is called. So I
> was forced, in my experiments, to first setText a Text component, get
> its layout bounds, and then calculate the coordinates for fillText.
> The second limitation is the most difficult one: a Canvas is limited to
> 8192x8192 pixels resolution. With a small font this would be good for
> about 700 LOC.
> So, the Canvas that I would need should allow 1mio x 1mio resolution.
> An alternative technique would be to have hundreds of smaller Canvas’,
> in Google Maps style, and put them together somehow.
> 
> 
> All those alternatives don’t look really usable for me.
> One thing that would be interesting is to have access to low-level
> functions of the JFX API. How does a javafx.scene.text.Text instance
> paint its LCD text on the screen?
> In principle what I would need is an infinite surface on which I can
> write and manipulate text with maximum speed, without adding nodes to
> the scenegraph. Modern video cards can run 3d games with way over 60 FPS
> and render complex scenarios with light. It should be possible to
> display text that is at least as fast (I know that JFX caps at 60 FPS,
> but that is fine). So when I have a massive 30 MB file with hundreds of
> thousands of lines of text, all colored and styled depending on the
> file type (Java code, Python code, etc), and this should scroll and
> resize very fluid.
> 
> If the JFX team wanted to write the editor component for Eclipse 5,
> how would you approach that? Most likely not by using one of the three
> strategies that I layed out above.
> 
> Do you have any inputs for me?
> 
> 
> Sunny greetings,
> André