Opus allows you to do some very powerful things very easily but you will need to take into account the impact they may have on performance especially if you are distributing your publication generally and cannot therefore predict what level of system the publication will be run on.
You should design your publication to run at its best on the kind of system you expect it to be used most on, even if that means that you cannot use all the features provided in Opus.
Note:
For example, actions on a page containing large video or sound files in a publication run from CD-Rom will need to be planned carefully as the video will take time to load. Also load times from CD can be slow so any actions set to happen via the Initially Hidden's Show After option will have their timing thrown off.
If animations have been started before the video has loaded they will stutter. Consider using the Resource tab in the Object Properties dialog to preload resources see The Resources tab for more information.
The Opus properties which will impact the speed and smoothness of your publication on lower specification systems include things like:
Transparency, irregular Borders and Blend effects.
Blur transitions on large images
Multiple concurrent Animations and Tweens.
Doing too much at the same time this is often not only a design issue but a technical one (see point 4 below). This is particularly true where you have designed a publication requiring lots of updates to the screen (animations, transparency, things flashing on and off, etc.), which is being displayed on a system with a lower specification graphics card, especially the kind found on the motherboards of some laptops.
Large publications containing large video or sound files run from a CD-ROM may run VERY slowly and may even appear to have crashed. Consider a separate menu program which launches individual video publications or dont embed the video files if copyright is not an issue. See also the note on compression below.
The key things that will impact the functioning of your publication are not the processor speed but the quality of the graphics card and its support for DirectX and the speed of the hard disk and cd-rom drive if appropriate.
If you want to be entirely secure about the timing of aspects of your publication, try to allow them time to complete and ensure that each of these happens in sequence rather than all at once and for accurate timing use a Timeline.
Note:
This can also mean taking into account system specific failings, which might delay actions so that Opus ends up trying to do several things all at once even when you spaced them out in your publication see Timing the Activity in your Publication for more information.
Publish your publication often and check that it works as you expect. If you can, try and use a system that as near matches the specification of the end-users machine as possible.
If you are publishing to the web using the Plexus Plug-in see Plexus Publications and Publishing to the Internet for more information:
If you are publishing to the web using Opus Flex (set in the Type tab of the Publication Properties dialog) consider what transitions you apply see Overview of Opus Flex for more information.
The Publish process allows you to specify a compression setting for your publication. It may seem that uncompressed publications can be read quicker and therefore start more quickly. However, this is NOT the case. The decompression of a compressed publication will take place in memory while the bottleneck in running a publication is loading it from disk (especially from CD) . Thus a publication will actually load quicker the more it is compressed but note that this can extend the time taken to publish the file quite considerably.
Note that this compression is different from the option to use a compressed player element.
Large publications will often perform better if Master Pages are placed at the end of your publication.