High performance text component

[André Thieme]

Am 03.08.2012 05:14, schrieb Richard Bair:

> With a Canvas approach. the way I would have approached it would have
> been to have a canvas the size of the viewport, and then simply use
> it as a place to draw all my text. The ScrollBar associated with it
> would be just sitting there, and I'd use its value as an indication
> of where to start drawing the text.

Thanks for this idea, this might actually work.
I guess sooner or later you may be able to add LCD font smoothing for
Canvas, as well as some way to get layout bounds. I can already get them
by using a Text instance, which is not even on the scenegraph.
By using a Canvas in principle everything is possible. Not only could
I write text on it, but also paint graphics and animations.
Though, for now I am only interested in a rectangular area on which I
can display symbols and words in different colors, fonts and styles.


> The problem with a Canvas that is too big is that it is stored as a
> single texture on the video card and the video card imposes limits.

Could you tell a bit more about those limits?
I would think that a modern video card should be able to store an
image in its ram, and update every single pixel, within 10-100 msecs.
The question of course is how fast the JVM can transport such changes
to the card. My needs are much lower than displaying modern 3D games.
A realized Canvas will need to be changed on the JFX thread, but I still
think this should be in the 50 msecs range (20 FPS), to scroll smoothly
through huge files.


>> 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.
>
> That is true. Up to this point, we would have used Text nodes and
> virtualized / reused them, such that the same Text node can be reused
> for different text as the viewport is scrolled. Much like a ListView
> is virtualized or a TableView. This would keep the node count
> somewhat under control but would have been very complicated.

Good idea too. I could have 20k Text instances and update them as
required. In practice only a few thousand of them should be visible at
the same time on the screen, while the others could be set to invisible.
Only in extreme cases, where people open a file on a huge monitor and
maximize a CodePane, filled with single symbols that all require their
own Text, then all 20k or so instances would have to be on the screen
at the same time.


So, now I have indeed two possible approaches that I could try out.
That should work I guess, and both approaches have their own set of
advantages and disadvantages.
But both of them would require a lot of bookkeeping and manual
management. But doable.


> At the moment Felipe Heidrich is working on a plan for rich text for
> 3.0. He has the lower level underpinnings in place (the Prism text
> layout code is all primed for rich / complex text). I was going to
> meet with him early next week to do some discussions around API and
> how we want to surface this in the public API, so your timing is
> fantastic!
>
> If you are happy to build on top of weekly builds of 3.0 then this
> could be the best solution. It works for us because it means we have
> a real world use case to drive development right off the bat which is
> quite beneficial. However if you have to ship something on a GA
> version of JavaFX, the best you have to work with is Canvas as
> described above or virtualized Text nodes.

I don’t have to deliver something with 2.2.x and thus could indeed wait
for the 3.0 beta version.
The RichText might be in principle what I would be implementing myself
with one of the two above approaches.


Regards,
André