Re: Automatic virtualisation (was Developing controls based on Canvas?)

[Jonathan Giles]

I think it would be feasible to develop some form of automatic 
virtualisation API, but I don't think it needs to be an API that ships 
with JavaFX. A generic implementation would probably need to abstract 
out three details:


1) The 'cell factory' (in the lingo of existing controls) to generate 
nodes on demand (in other words, a node factory)
2) A means of specifying when a node should be 'removed' from the 
scenegraph (and added back to the pile of available nodes that can be 
reused)
3) The actual layout of all nodes that are currently part of the 
visualisation


I don't think there is any escaping detail #2 above, unless you want to 
do a very simplistic 'if (nodeX < 0 || nodeY < 0 || nodeX > w || nodeY > 
h)'. Perhaps that would be fine in some simplistic cases, but if you're 
working in a zooming case I imagine you might want to prune the 
scenegraph in situations where nodes are technically within bounds but 
are no longer entirely relevant to the view.


This is essentially all that happens in the VirtualFlow code used in a 
number of UI controls. Could this VirtualFlow code be rewritten to be 
based on top of a more abstract virtualisation engine? Surebut it 
probably won't be :-)


Hope that helps.

-- Jonathan

On 9/08/2013 9:38 a.m., Felix Bembrick wrote:
With all this talk of node virtualisation, I am wondering how feasible 
it would to build some kind of "automatic virtualiser" such that you 
pass it your real-world model and then it automagically works out the 
actual nodes and pools required and manages them seamlessly to 
maximise rendering performance and responsiveness?  That is, it 
determines how many nodes will be visible at any one time and just 
manages all that stuff for you completely under the hood.


Maybe Jonanthan you have come some way to building such a beast with 
your work on bidirectional virtualisation in FX 8 TableView or other 
controls?


Felix


On 9 August 2013 07:31, Felix Bembrick > wrote:


T
hanks Jonathan.

I'll have to check out the virtualisation that you refer to that's
going on in JavaFX8 with TableView., it sounds very interesting.

I am not saying that controls such as what I am proposing are
*impossible* to implement using a scenegraph; it just seems
natural to implement them in a more procedural/programmatic way
but this could very possibly just be because I do not have a full
grasp of the capabilities of the scenegraph and what can be
achieved by manipulating it.  To me it seems that the costs of
repeatedly creating nodes (or hopefully reusing them), potentially
restructuring the hierarchy of nodes in the scenegraph and
adjusting each node's properties to enable a truly dynamic control
would logically be much greater than just cycling through a render
loop and rendering each graphic element in its correct location
but, again, you seem very confident that these costs are not
significant enough to prevent such a control performing well.

In the end if I can get away with a scenegraph representation of
this control and that massaging said scenegraph is performant
enough then I am in a happy place.  I have already observed that
some nice stuff can happen just by playing around the scenegraph
so it is quite possible that I am worrying about performance and
memory issues that will never actually eventuate in practice.

Felix


On 9 August 2013 07:16, Jonathan Giles mailto:jonathan.gi...@oracle.com>> wrote:

Felix,

As you are restricted in what you can say, that also restricts
how I can help. However, your example of a spreadsheet not
being a control that can be implemented in a scenegraph-based
manner suggests that you might want to re-evaluate your
assumptions. A spreadsheet would be able to be implemented in
a scenegraph approach quite nicely - the TableView control
comes quite close to that already (especially in JavaFX 8.0
where it can virtualise in both vertical and horizontal
directions). In fact, I know of at least two spreadsheet
implementations that already exist in JavaFX based on a
scenegraph approach.

As I've said elsewhere, the issues you are facing are because
of merging two approaches (retained and immediate modes) into
one control. What you are hoping to do is have your cake and
eat it too, which unfortunately I don't think will end up too
well for you :-) My advice is to recheck your assumptions -
the scenegraph approach, in my opinion, should suit your
requirements far more than an immediate mode approach (given
that your requirement is to reuse existing scenegraph-based
controls).

I'm not sure why you think controls must be defined in a
static, structured way. You could put all nodes of a control
into a single 

Automatic virtualisation (was Developing controls based on Canvas?)

[Felix Bembrick]

With all this talk of node virtualisation, I am wondering how feasible it
would to build some kind of "automatic virtualiser" such that you pass it
your real-world model and then it automagically works out the actual nodes
and pools required and manages them seamlessly to maximise rendering
performance and responsiveness?  That is, it determines how many nodes will
be visible at any one time and just manages all that stuff for you
completely under the hood.

Maybe Jonanthan you have come some way to building such a beast with your
work on bidirectional virtualisation in FX 8 TableView or other controls?

Felix


On 9 August 2013 07:31, Felix Bembrick  wrote:

> T
> hanks Jonathan.
>
> I'll have to check out the virtualisation that you refer to that's going
> on in JavaFX8 with TableView., it sounds very interesting.
>
> I am not saying that controls such as what I am proposing are *impossible*
> to implement using a scenegraph; it just seems natural to implement them in
> a more procedural/programmatic way but this could very possibly just be
> because I do not have a full grasp of the capabilities of the scenegraph
> and what can be achieved by manipulating it.  To me it seems that the costs
> of repeatedly creating nodes (or hopefully reusing them), potentially
> restructuring the hierarchy of nodes in the scenegraph and adjusting each
> node's properties to enable a truly dynamic control would logically be much
> greater than just cycling through a render loop and rendering each graphic
> element in its correct location but, again, you seem very confident that
> these costs are not significant enough to prevent such a control performing
> well.
>
> In the end if I can get away with a scenegraph representation of this
> control and that massaging said scenegraph is performant enough then I am
> in a happy place.  I have already observed that some nice stuff can happen
> just by playing around the scenegraph so it is quite possible that I am
> worrying about performance and memory issues that will never actually
> eventuate in practice.
>
> Felix
>
>
> On 9 August 2013 07:16, Jonathan Giles  wrote:
>
>>  Felix,
>>
>> As you are restricted in what you can say, that also restricts how I can
>> help. However, your example of a spreadsheet not being a control that can
>> be implemented in a scenegraph-based manner suggests that you might want to
>> re-evaluate your assumptions. A spreadsheet would be able to be implemented
>> in a scenegraph approach quite nicely - the TableView control comes quite
>> close to that already (especially in JavaFX 8.0 where it can virtualise in
>> both vertical and horizontal directions). In fact, I know of at least two
>> spreadsheet implementations that already exist in JavaFX based on a
>> scenegraph approach.
>>
>> As I've said elsewhere, the issues you are facing are because of merging
>> two approaches (retained and immediate modes) into one control. What you
>> are hoping to do is have your cake and eat it too, which unfortunately I
>> don't think will end up too well for you :-) My advice is to recheck your
>> assumptions - the scenegraph approach, in my opinion, should suit your
>> requirements far more than an immediate mode approach (given that your
>> requirement is to reuse existing scenegraph-based controls).
>>
>> I'm not sure why you think controls must be defined in a static,
>> structured way. You could put all nodes of a control into a single Pane (or
>> Region, etc) layout and layout all the nodes using absolute positioning.
>> You can be as dynamic as you want to be.
>>
>> Unfortunately, without more information I am really unable to give any
>> further advice, but I wish you good luck in whichever approach you decide
>> to take.
>>
>> -- Jonathan
>>
>> On 9/08/2013 9:02 a.m., Felix Bembrick wrote:
>>
>>  Hi Jonathan,
>>
>>  Thanks for your reply.
>>
>>  I am a little restricted in exactly what I can reveal about my plans
>> for this control but I can say that it is one in which its very appearance
>> could change quite significantly in a dynamic way at runtime.  The control
>> also needs to support panning and zooming in a very performant way.  There
>> will likely be a lot of graphics being draw in a manner which (to me at
>> least) fits the immediate mode of rendering better than a scenegraph
>> because their positions and attributes are most readily defined
>> programmatically rather than declaratively.
>>
>>  Though not directly analogous, consider your typical spreadsheet
>> application like Excel where the user is able to pan to the right
>> effectively without limits and that grid lines are constantly being
>> rendered as the panning takes place.  Given that screens can be very large
>> these days it is conceivable that a complex spreadsheet will be displaying
>> hundreds of lines to define the cells in a grid at any one time and that it
>> is way more concise to programmatically define how this grid is rendered
>> rather than having a scenegraph con