High performance text component

[Kevin Rushforth]

>
>> 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 Canvas needs to fit within the texture limits of the graphics card. 
Even systems with very large memory have size limits for a single 
texture that are usually in the range of 2K x 2X on the low end up to 8K 
x 8K at the high end, with 4K x 4K being the most common limit for 
desktop graphics systems. So you can't create a single Canvas that is 
10,000 x 10,000 pixels.

-- Kevin


André Thieme wrote:
> 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é