ICEpdf
  1. ICEpdf
  2. PDF-476

JavaFX Reference Implementation

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 6.4
    • Component/s: Viewer RI
    • Labels:
      None
    • Environment:
      any

      Description


      We've had a few requests for a JavaFX based viewer component and an accompanying reference implementations. The core is render Java2D based and could be fairlyeasily cut in the JavaFX architecture.

      Work on this new Reference RI will be tracked by this bug.

        Activity

        Hide
        Patrick Corless added a comment -

        I've spent quite a bit of time getting familiar with JavaFX custom controls. The first implementation was a simple node based solution build using standard FX controls and panes. Performance as excellent for documents with less then 1000 pages but performance quickly fell off as they approached 10000.

        To further my testing I built a documentview custom control that uses a variant of the virtual flow used in the list and table components. Given the nature of the virtual flow performance was excellent, with now realistic page max, scrolling was smooth and very performant.

        Cutting in our own document class and using our java2d core to render to image worked as expected. However creating a full clip optimized solutions has proven to be problematic. The node hierarchy does not seem to keep track of the absolute position of a note which makes finding the absolute position of note difficult. Quite a bit more work is needed to correctly calculate the page clip in the virtual flow. And as a result we currently have a view that is a bit jittery when zooming in.

        The JavaFX properties and bindings has proven to be very powerful. A full viewer RI would have significantly less code then its Swing RI counterpart and could be setup to be a true component that could be cut into a variety of different control configurations.

        I'm going to do some further testing to see we can wrap the swing view's in a JavaFX component. This way we can take advantage of the properties binding but still leverage existing code base for page view. At this time doing a full rewrite of the page view (annotations, text selection and highligh) is looking like significant amount of work. So providing a wrapped solution might allow us to measure how much demand is actually out there before committing to several man months of labour.

        Show
        Patrick Corless added a comment - I've spent quite a bit of time getting familiar with JavaFX custom controls. The first implementation was a simple node based solution build using standard FX controls and panes. Performance as excellent for documents with less then 1000 pages but performance quickly fell off as they approached 10000. To further my testing I built a documentview custom control that uses a variant of the virtual flow used in the list and table components. Given the nature of the virtual flow performance was excellent, with now realistic page max, scrolling was smooth and very performant. Cutting in our own document class and using our java2d core to render to image worked as expected. However creating a full clip optimized solutions has proven to be problematic. The node hierarchy does not seem to keep track of the absolute position of a note which makes finding the absolute position of note difficult. Quite a bit more work is needed to correctly calculate the page clip in the virtual flow. And as a result we currently have a view that is a bit jittery when zooming in. The JavaFX properties and bindings has proven to be very powerful. A full viewer RI would have significantly less code then its Swing RI counterpart and could be setup to be a true component that could be cut into a variety of different control configurations. I'm going to do some further testing to see we can wrap the swing view's in a JavaFX component. This way we can take advantage of the properties binding but still leverage existing code base for page view. At this time doing a full rewrite of the page view (annotations, text selection and highligh) is looking like significant amount of work. So providing a wrapped solution might allow us to measure how much demand is actually out there before committing to several man months of labour.

          People

          • Assignee:
            Patrick Corless
            Reporter:
            Patrick Corless
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: