Performant Controls (hijacking Re: Developing controls based on Canvas?)

[John Smith]

> . . . imagine you had to build a visualisation of the same data but in a diagram, maybe something like http://www.novell.com/communities/files/img/groupwise_8_protocol_flow_diagram_v1.3.jpgbut
with x100 nodes, with zooming and panning - could you outline a general strategy?

I'd use some like yworks yfiles for this, it seems pretty similar =>
http://www.yworks.com/en/products_yfiles_practicalinfo_gallery.html  (this page is a very nice example of a showcase by the way :-)

Sebastian Rheinnecker from yworks created a prototype of their tool in JavaFX.
He has posted on this list before, so you can find his email in the archives if you want to ask questions about it.
The yworks stuff is a very nice graphing system that scales to very large graphs and is implemented in lots of different technologies, so perhaps a good contact point if they are willing to discuss implementation details.

There is also the primarily JavaFX based Dex Data Explorer which also seems pretty similar (albeit using a polyglot programming approach) =>
http://www.javainc.com/projects/dex/

-----Original Message-----
From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Zwolenski
Sent: Monday, August 05, 2013 5:39 PM
To: Jonathan Giles
Cc: openjfx-dev at openjdk.java.net List
Subject: Performant Controls (hijacking Re: Developing controls based on Canvas?)

Sneaking in here, as you've given an opening with "if implemented wisely, there is very little that a scenegraph-based approach can't do". The question I've been asking for a while is what does "implemented wisely"
look like in JFX.

This has come up in the performance conversations, the game conversations, the CAD conversations, and many other places. No one seems to have an answer, but you're building extremely complex stuff on a regular basis - what's your tips?

When you say you only have "20 visible nodes" out of 1000's in general are the other nodes:
a) in the scenegraph and set to not visible
b) in memory but not in the scenegraph - added/removed when scrolled into view and out of view
c) not in memory, created, added and then removed, destroyed when scrolled into view and out of view
d) something else?

I know Table uses a rubber stamp approach, where it re-uses cell views where possible, but let's say every row in my 100,000 row Table was uniquely rendered using a different cell. What would happen under the covers?

How do you work out the scroll range as well? Each cell can be a unique height right? How do you know the extents of the vertical scrolling without instantiating and rendering everything? Is this what you do? What if a cell is changing size (has a collapsable pane in it, etc) - what happens to the vertical scroll range?

Do any of the controls have zooming on them? Have you had to deal with this and have you got a strategy for handling this with respect to scroll bounds, working out which nodes are in view, scaling fonts, etc? Could you hazard a guess at what you would do if you had to implement zooming on a Table for example?

Maybe the Table is lucky with its restrictive grid like layout but imagine you had to build a visualisation of the same data but in a diagram, maybe something like http://www.novell.com/communities/files/img/groupwise_8_protocol_flow_diagram_v1.3.jpgbut
with x100 nodes, with zooming and panning - could you outline a general strategy?





On Tue, Aug 6, 2013 at 10:10 AM, Jonathan Giles
<jonathan.giles at oracle.com>wrote:

> I think it would pay to take a step back and understand why you think 
> a 'traditional' scenegraph-based (or retained mode) control is not 
> sufficient for your needs?
> Unfortunately you've not detailed your use case, so it is hard to give 
> any specific advice. Are you able to give any details about what it is 
> you're trying to build and why you think the normal approach to 
> building controls is not sufficient?
>
> We've built some fairly complex controls using this approach, and if 
> implemented wisely, there is very little that a scenegraph-based 
> approach can't do. Specifically, do you think your control will render 
> all of the 'thousands of nodes' at once, or will many of these nodes 
> be off screen or otherwise not visible at any one time? For things 
> like the TableView we only render the nodes that are visible. This 
> means that regardless of whether there are 100 or 1,000,000 rows of 
> data, we only have visual nodes for the 20 visible rows, for example. 
> Keeping your scenegraph as minimal as possible is always a very wise idea, if performance is a concern.
>
> As you note, the other problem is that you will run into issues if you 
> want to mix canvas rendering with the scenegraph-based controls like 
> Button. The best you're likely to achieve (having not tried it 
> personally) is to position the control on top of the canvas, rather 
> than attempting to render the control inside the canvas (and having to 
> then deal with event handling, etc). This will likely prove to be 
> finicky, and more cumbersome than simply using an entirely 
> canvas-based or entirely scenegraph-based approach.
>
> -- Jonathan
>
>
> On 5/08/2013 10:11 p.m., Felix Bembrick wrote:
>
>> I am investigating the feasibility of developing a JavaFX 8 control 
>> based on Canvas.  I have chosen Canvas as the base class as this 
>> control is of a very dynamic nature and would not be easy to 
>> implement with a retained mode style ancestor (at least as far as I 
>> can tell).
>>
>> So is this feasible?  While I can readily see how to render the 
>> visual aspects of the control, I am not sure how to best "embed" 
>> other controls within it should that become necessary (and almost certainly will).
>>
>> For example, how would I go about embedding a Button within my control?
>>  It
>> looks to me like I would need to create an actual Button node 
>> somewhere else in the scenegraph and then perhaps render it within my 
>> control using
>> gc.drawImage() passing in a snapshot of the Button node.  That's OK 
>> but then I have to somehow handle events and I am not sure how best 
>> to do that.
>>
>> Another issue I see is that there seems to be no way to apply effects 
>> to individual graphic elements within the Canvas as the applyEffect() 
>> method applies to the entire Canvas.
>>
>> Finally, a significant obstacle is this issue:
>>
>> https://javafx-jira.kenai.com/**browse/RT-23822<https://javafx-jira.k
>> enai.com/browse/RT-23822>
>>
>> This issue relates to the lack of support for LCD font smoothing 
>> within Canvas.  This may not sound that serious but the difference 
>> between LCD font-smoothed text in other controls and the grey-scale 
>> text in Canvas is so distinct on my current machine that a control 
>> based on Canvas would really stick out like a sore thumb and appear 
>> significantly less appealing than a "standard" control.
>>
>> So, am I wasting my time?
>> Are there any other issues I am likely to face?
>> Are there other ways to develop dynamic controls which may involve 
>> thousands of nodes (such as lines, curves etc.)?
>>
>> Thanks,
>>
>> Felix
>>
>
>