Slow performance with document images

[cnevins]

Our organization is having performance issues with Oxygen when navigating documents that contain images stored on a network share. When there are more than 3 or 4 images in the document, performance seems to degrade heavily – documents take a long time to load, and it appears that Oxygen keeps requesting the images as the user scrolls back and forth through the document. Initial document load times increase linearly with the number of images in the document.

Any suggestions on how to deal with this?

Thanks!

-Cole

[Radu]

Hi Cole,

About how many images does an XML document refer?
Did you consider breaking your documentation in more XML chunks and aggregating them together when publishing?
Do you use a custom XML vocabulary?

Here's what Oxygen does currently:

1) When the document is opened Oxygen needs to know the width and height of each image in order to know how much space in the edited page to reserve for each one. It will connect to each image to find this our without loading it in the memory. So Oxygen does not have all images stored in memory after the loading.

2) When scrolling the XML document Oxygen has an in-memory image cache but it cannot store all images in memory (because it could overflow its allocated maximum available memory) so the cache stores only a couple of images. This is why when scrolling up or down the internal cache gets overflown and images need to be obtained again from the shared network drive.

In your opinion, what problem is the most severe, (1) or (2)? Is the shared network drive on the local network or on a remote location?

We will try to improve this behavior in a future version.

For problem (1) we could maybe start a different parallel processing which determines the widths and heights of images and refreshes parts of the loaded document when finished.

For problem (2) we still cannot hold all images loaded in Oxygen's memory space. We could download each image and store it locally but this is useless if referenced images are on the local drive. The problem with shared network drives is that an application does not really know if a resource is located on the local drive or not.

Out of curiosity, how do you manage to avoid conflicts when working in a team on a shared network drive?
For our user manual we use a version control server (Oxygen comes with a Subversion client included) which gives us the possibility to update, commit, checkout and see the history on every resource from our project. It also allows us to tag the project on each release so we can publish our documentation for specific versions of our product. The advantage is that each of us has a local copy of the project which offers redundancy if the server breaks + there are no speed problems as the one you are experiencing right now.

Regards,
Radu

[AlGor]

Hi Radu,

What is the oxygen internal cache size?
Could it be configured or it's predefined?

Regards,
Alexey.

[Radu]

Hello Alexey,

Could you also give us more details about the problems you are experiencing?

Our cache is designed to hold at least 4 images in it (as long as each of them is not over 24 Megabytes (computed like: width * height * 4)).
It will remove from cache older images if the total added cached image sizes are over 10 MBs (computed the same as above).

Also in Oxygen 15.0 (and the corresponding Author Component) the Author visual page auto scales down large images (like the ones you sent us for tests) and more of them should fit in the cache.
Please see the Images section in the Oxygen Preferences->"Editor / Edit modes / Author" page, these are the settings which for now can be changed.

Regards,
Radu