Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8277133

Dragboard contents retrieved all over again during a DND process on WebView

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: openjfx17
    • Fix Version/s: openjfx18
    • Component/s: javafx
    • Labels:
      None
    • Subcomponent:
      web

      Backports

        Description

        WebView has a drag and drop eventHandler which is added to several drag events:

                setOnDragEntered(destHandler);
                setOnDragExited(destHandler);
                setOnDragOver(destHandler);
                setOnDragDropped(destHandler);

        As part of this eventHandler, the dragboard content is retrieved from QuantumClipboard, which has a cache strategy in place, but unfortunately the cache is flushed away when the drag events starts (QuantumToolkit::startDrag).

        This means that such content (for instance, an Image), is being retrieved from a given URL over and over again (via QuantumClipboard::readImage), on every mouse move/drag over, causing a high lag in showing the image and moving it as the drag view.

        This issue can be reproduced on all platforms and JavaFX versions, but there are different cases.

        On Windows and Linux, dragging an image from a web page (wrapped or not with an hyperlink) uses Clipboard::getLocalData, and QuantumClipboard::readImage tries to create a new Image(url) on every call, without background loading, which takes around 200 ms for the first image of https://openjdk.java.net.

        Running the attached test from Ubuntu 20.04 with JavaFX 18-ea+6 gives:

        location = https://openjdk.java.net/
        DND readImage time = 407
        DND readImage time = 225
        DND readImage time = 226
        DND readImage time = 230
        location = https://openjdk.java.net/faq/
        DND readImage time = 178
        DND readImage time = 177
        DND readImage time = 177

        Similar values on Windows 10 with 18-ea+6:
        location = https://openjdk.java.net/
        DND readImage time = 174
        DND readImage time = 173
        DND readImage time = 174
        DND readImage time = 178
        DND readImage time = 175
        DND readImage time = 176
        location = https://openjdk.java.net/faq/
        DND readImage time = 178
        DND readImage time = 179
        DND readImage time = 176
        DND readImage time = 174
        DND readImage time = 174
        DND readImage time = 180
        DND readImage time = 176


        On Mac, however, SystemClipboard::popFromSystem is used.
        If the image is not in an hyperlink, the load is done via pixels/rawData, which is really fast (the first image of https://openjdk.java.net. takes 2 ms) as it doesn't call new Image(url).

        However, when the image is in an hyperlink (after the proposed patch for JDK-8160597 is applied), QuantumClipboard::readImage goes through new Image(url) on every call, again without background loading. For a given image, like the one on https://openjdk.java.net/projects/jdk/17/, this can take up to 700 ms.

        Running the test from Mac OS 11.6 and JavaFX built from head+patch for JDK-8160597:

        location = https://openjdk.java.net/
        DND readImage time = 910
        DND readImage time = 1
        DND readImage time = 1
        DND readImage time = 2
        DND readImage time = 1
        DND readImage time = 1
        DND readImage time = 2
        DND readImage time = 2
        DND readImage time = 1
        location = https://openjdk.java.net/faq/
        DND readImage time = 1093
        DND readImage time = 705
        DND readImage time = 705
        DND readImage time = 705
        DND readImage time = 713
        DND readImage time = 713
        DND readImage time = 704
        DND readImage time = 705

        While enabling background loading of images in QuantumClipboard::readImage should make an big improvement, it seems necessary to use the linkedLists in the WebView eventHandler to cache the content, avoiding creating over and over again the same image/content.

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                jpereda Jose Pereda
                Reporter:
                jpereda Jose Pereda
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: