Performance MetaDataEditor Gallery Drag-&-Drop via jQuery-UI

[thomaslow]

Related issues:

• Metadata editor takes a long time initializing #4195

Conflicts with:

• Generalize drag and drop PoC #5011

When navigating to the meta data editor, a lot of loading time is spent at initializing the drag-&-drop functionality of the gallery panel and structure tree. This can be tested by removing the authority to edit images of a process, which disables drag-&-drop in the meta data editor.

The problem can be traced back to the Primefaces components <p:draggable /> and <p:droppable />. Unfortunately, they can only reference a single other component that is supposed to be made draggable or droppable via their for="some-component-id"-property. Because of this, and in order to make every thumbnail draggable, they have to be placed inside the <p:dataList /> components and, thus, are repeated many times. Presumably, this causes the browser to initialize all event handlers for each drag-&-drop individually, which slows down the page drastically.

Luckily, Primefaces uses jQuery-UI in order to provide drag-&-drop functionality. This pull request removes <p:draggable /> and <p:droppable> from the gallery panel and replaces it with corresponding Javascript code that initializes the drag-&-drop functionality via jQuery-UI directly. As a result, all thumbnails can be made draggable via one method call to jQuery-UI, which is much more efficient.

Advantages

The loading time of a meta data editor with 1000 pages is reduced from 5.79 seconds to 3.33 seconds (desktop workstation) or 20.81 seconds to 9.94 seconds (laptop).

Together with the following other pull requests

• Performance MetaDataEditor Lazy Loading of Gallery Thumbnails #5114
• Performance Enable Gzip Compression #5115

the loading time is reduced from 5.79 seconds to 2.27 seconds (desktop workstation) or 20.81 seconds to 6.01 seconds (laptop).

Drawbacks

Compatibility: Since components are made draggable outside of Primefaces, if those components are updated via Primefaces, they will loose all their custom event handlers. Therefore, a custom Javascript hook was implemented, which re-initializes drag-&-drop functionality after each update of any Primefaces components of the meta data editor. However, this does not slow down other parts of the meta data editor, because jQuery-UI is able to detect if a component is already draggable, and skip its re-initialization. Still, in the future, this hook or any other parts of the custom Javascript code may break in Primefaces v10 or v11.

Maintainability: Since this pull request removes Primefaces components and replaces them with custom Javascript code, the overall maintainability of the meta data editor decreases somewhat more.

An alternative would be to reduce the number of draggable and droppable components via pagination as suggested in:

• Suggestions for the optimal structuring in the metadata editor #5010

[markusweigelt]

@thomaslow The behavior of meta editor has changed a bit with this, since there are no more visual drop areas, right?

Is the problem also for larger number of pages fixed? Question from the following background:

For the discussion #5011 i created a PR (only as draft so conflicts are not bad ;) ) which replaces primeface drag & drop too and implemented drag & drop with vanilla js instead of jquery (to reduce registered event handlers to one handler on document). Besides, the number of stucture elements has been reduced due to the conversion using CSS. PR was not completely finished because the behavior with more than 1500 pages or in specific test object with more than 1900 pages drag and drop was no longer possible.

Is drag & drop also possible for 1900 or more pages with this change? At that time I came to the conclusion that with higher number of stuctural elements and images drag & drop becomes slower and slower. Will this implementation make it better or do you also think that the editor only works up to a certain limit of pages and images?

In addition, there is the point that the client computers may not have as many resources available for the browser, as is the case with our development computers.

What do you mean?

[thomaslow]

@markusweigelt

@thomaslow The behavior of meta editor has changed a bit with this, since there are no more visual drop areas, right?

No, drop areas are preserved by this pull request. Each drop area is also initialized outside of Primefaces via a call to jquery-ui. From a user perspective, there should be no difference to the previous drag & drop behavior (except performance). I tested dragging of single pages, dragging to empty stripes and dragging of multiple selected pages.

Is the problem also for larger number of pages fixed? Question from the following background:

For the discussion #5011 i created a PR which replaces primeface drag & drop too and implemented drag & drop with vanilla js instead of jquery (to reduce registered event handlers to one handler on document). Besides, the number of stucture elements has been reduced due to the conversion using CSS. PR was not completely finished because the behavior with more than 1500 pages or in specific test object with more than 1900 pages drag and drop was no longer possible.

Unfortunately, I just discovered your PR. Maybe we should talk and see whether we can combine some changes?

Is drag & drop also possible for 1900 or more pages with this change? At that time I came to the conclusion that with higher number of stuctural elements and images drag & drop becomes slower and slower. Will this implementation make it better or do you also think that the editor only works up to a certain limit of pages and images?

There is another issue with drag and drop, see #5116. With both changes, drag-&-drop is improved a lot, but not really nice to use.

One problem that remains is that selecting a page in the gallery view triggers a synchronization between the gallery view and structure view. This happens right before dragging starts, and also when dropping a page, which causes another delay.

In addition, there is the point that the client computers may not have as many resources available for the browser, as is the case with our development computers.

I tested a process with 1000 pages and ~1500 pages and couldn't really find any resource problems on my development workstation. Maybe I should add some more pages.

Can you tell me what kind of limiting resources they have (RAM, CPU, etc.), and what browsers are used?

[markusweigelt]

@thomaslow

Unfortunately, I just discovered your PR. Maybe we should talk and see whether we can combine some changes?

This is not a problem and we do not need to do it. The PR was just a draft to show that the drag & drop changes alone can improve the performance but with increasing number of structural elements and images the processing is capped. e.g. to a maximum number of DOM elements that are possible and to the resources of the client.

There is another issue with drag and drop, see #5116. With both changes, drag-&-drop is improved a lot, but not really nice to use.

The loading behavior of Primeface is then an additional "annoying" factor that is true and if the fix remedies this will be great.

I tested a process with 1000 pages and ~1500 pages and couldn't really find any resource problems on my development workstation. Maybe I should add some more pages.

Can you tell me what kind of limiting resources they have (RAM, CPU, etc.), and what browsers are used?

I cannot make any concrete statements on this. My only assumption here was that our developer computers are better than those in digitization and that problems are more likely to occur here.

In the concrete case example: there are >160 structural elements (chapters and subchapters) in the gallery on which > 1900 images/pages are distributed. All the better, if this works great and if it is also possible to edit even higher number of pages. :)