JDK-8099429 : Optimize 3D picking
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: fx1.3
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2009-07-30
  • Updated: 2015-06-16
  • Resolved: 2013-05-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Fixed
Related Reports
Blocks :  
JDK-8102604 - Picking issues
Blocks :  
JDK-8099878 - Implement rendering for all 3D transformed primitives
Blocks :  
JDK-8103012 - Optimize bounds picking of 2D nodes in 3D space
Blocks :  
JDK-8099881 - Implement 3D bounds
Blocks :  
JDK-8092447 - Optimize picking performance
Blocks :  
JDK-8099879 - Implement 3D picking for all primitives
Description
We need to use quick bounds-based rejection technique to speed up picking.
We need to optimize for common 2D primitives, such as rect and cirle.
Comments
All depends-on issues are resolved and there doesn't seem to be more work, so I'm marking this one as resolved as well.
24-05-2013
Well, it seemed odd to put this issue to the commit message of the small additional optimization. So I created a separate issue for it - RT-30639 - and I'm linking it as "depends on".
24-05-2013
How is this converting to geometries or textures related to picking? We pick directly on the nodes. I mean, we compute intersection with a javafx.scene.shape.Rectangle and this is not going to change, is it? I resolved it by accident a minute before, I would undo it instead of the reopening if it was possible. There is no changeset associated with this issue so it should not be a problem. The additional improvement definitely fits into the "Optimize 3D picking" bucket.
23-05-2013
The optimize for primitives were mentioned because we convert 2D shapes to tessellated geometries if they are 3D transformed. This will not be an issue once we switched to converting them into textures instead of geometries. We already have a JIRA filed for this work. BTW, I don't think we want to reopened a resolved JIRA. It is better to file a new JIRA if you have further improvement to do.
23-05-2013
While writing the additional idea I forgot I was in the "resolve" window. Reopening.
23-05-2013
The requirements were: * We need to use quick bounds-based rejection technique to speed up picking. This technique is in place. * We need to optimize for common 2D primitives, such as rect and cirle. I'm not sure what exactly was meant by this. The intersection with 2D shapes is done by intersecting pick ray with XY plane and then calling their contains() method, I don't think we can make that much faster. However, I've just got an idea of one additional fast-path: we could most probably compute bounds intersection significantly faster for 2D bounds in 3D (right now we treat them as 3D bounds and compute the two identical sides and four collapsed sides separately). I'll keep this issue open to do this.
23-05-2013
Not sure whether this is still relevant. Pavel, could you take a look?
29-01-2013
The fix to RT-5257 is just a quick fix. We should unify the algorithm for 2D and 3D picking on 2D primitives.
16-02-2010