Difference between revisions of "Impress/Performance"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Extended the slide show section.)
(OpenDocument: fixed internal wiki link)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
{{Performance}}
 
= Ongoing work =
 
= Ongoing work =
  
Line 5: Line 6:
 
We currently evaluate possible bottlenecks and performance opportunities in the implementation of loading and saving the native OpenDocument xml formats in impress.
 
We currently evaluate possible bottlenecks and performance opportunities in the implementation of loading and saving the native OpenDocument xml formats in impress.
  
Please find details [http://wiki.services.openoffice.org/wiki/Impress/Performance/OpenDocument here]
+
Please find details [[Impress/Performance/OpenDocument|here]]
  
 
== Slideshow ==
 
== Slideshow ==
Line 35: Line 36:
 
* '''Irregular number of frames per second'''<br/>This is not so much a problem of something being to slow but that an animation looks somehow "odd". Animations appear smoother when shown with a constant frame rate.  Sadly, a highly irregular frame rate seems to be the normal case, not the exception.
 
* '''Irregular number of frames per second'''<br/>This is not so much a problem of something being to slow but that an animation looks somehow "odd". Animations appear smoother when shown with a constant frame rate.  Sadly, a highly irregular frame rate seems to be the normal case, not the exception.
 
* '''Apparent pauses between animations'''<br/> The slide show is implemented on top of a set of queues that execute events in a highly asynchronous way.  This can lead to the effect that events that should be executed at the same time are executed with one or more frames in between.  See [http://www.openoffice.org/issues/show_bug.cgi?id=96540 issue 96540] for more details on that.
 
* '''Apparent pauses between animations'''<br/> The slide show is implemented on top of a set of queues that execute events in a highly asynchronous way.  This can lead to the effect that events that should be executed at the same time are executed with one or more frames in between.  See [http://www.openoffice.org/issues/show_bug.cgi?id=96540 issue 96540] for more details on that.
 +
 +
= Graphics =
 +
 +
* Someone should have a look at [http://framewave.sourceforge.net/] to speed up image processing inside vcl by using latest CPU technology.
  
 
= Previews =
 
= Previews =

Latest revision as of 13:37, 22 June 2010

Performance 170.png
Performance Project

performance.openoffice.org

Quick Navigation

Team

Communication

Activities

About this template


Ongoing work

OpenDocument

We currently evaluate possible bottlenecks and performance opportunities in the implementation of loading and saving the native OpenDocument xml formats in impress.

Please find details here

Slideshow

We are currently working on the visual performance of the slideshow in Impress.

There are many aspects of the slide show performance and not everyone is directly linked to "low speed". For this to understand you have to recall that the slide show is frame based, not continous. If an effect appears to be too slow than the long rendering time of individual frames is just one possible reason. It can as well be caused by wrong timing of the frames so that animations are stretched to a multiple of their original duration. Finally the original duration may be longer than what users are accustomed to in other applications.

Slide show performance problems can be categorized like this:

  • Not enough frames per second
    • Rendering of single frames takes too long when content is too complex
      • Hardware acceleration of rendering during slideshow is desirable
        • Rework of the directx canvas for windows to use native directx calls to render geometry instead of using the slow GDI+
        • New XCanvas implementation based on pure OpenGL. A prototype is available in ooo-build
      • avoid intermediate representations and conversions, by using the drawing layer primitives in slideshow as well
        • use more high-level canvas primitives, gradients are a lot faster when not decomposed into polygon strips
    • Artificial limitation of the number of frames per second (fps). There is code both in the slideshow and the sd module that limits the number of frames per second. While in general this is necessary (there is no sense in even trying to render, say, 200 fps), values that are too small are one hard upper fps boundary. In practice there often are factors that lead to even smaller fps numbers.
  • Duration of animations is too long
    • The requested duration is too long. This is a problem only when the same animation exists in other applications and has a different (shorter) duration there.
    • Due to the inner workings of the slide show animations are stretched in certain situations so that a minimal number of frames is shown. When the original duration is very short then the resulting duration can be a multiple of that. See issue 94193 for more details.
  • Irregular number of frames per second
    This is not so much a problem of something being to slow but that an animation looks somehow "odd". Animations appear smoother when shown with a constant frame rate. Sadly, a highly irregular frame rate seems to be the normal case, not the exception.
  • Apparent pauses between animations
    The slide show is implemented on top of a set of queues that execute events in a highly asynchronous way. This can lead to the effect that events that should be executed at the same time are executed with one or more frames in between. See issue 96540 for more details on that.

Graphics

  • Someone should have a look at [1] to speed up image processing inside vcl by using latest CPU technology.

Previews

PNG images can be saved in interlaced mode. This increases the file size a little but it allows to load preview image up to 64 times faster. Without it you can for example end with loading few megabytes image - only to compute a small preview containing 64x64 pixels. (see http://www.libpng.org/pub/png/pngintro.html for interlaced example)

The JPEG image format contains data stored hierarchically and thus can even provide higher quality preview images than a naive downsampling of the original size image. For JPEGs that have been saved in "progressive mode" only a small part of the image file has to be read for previews.

The pngperf cws adds necessary API for loading images in preview mode.

Preview API

So far there is API for previews, but OOo doesn't use it yet.

There exist slidesorter-demo-* patches in ooo-build http://svn.gnome.org/viewcvs/ooo-build/trunk/patches/src680/ to use pngperf API, but they have still some problems (such as impress sometimes showing preview quality images in slideshow presentation). There is problem with using that API, as Sun needs to keep API/ABI compatability, and thus it is now only possible to set parameters to png/jpeg loaders by static functions.

TODO:

  • provide hints for more situations where big images are previewed
  • many more optimizations are possible...
  • make an extension to downsample large images (5megapixels is common from digital camera) to screen resolutions such as 1024x768 or 800x600
  • add image downsampling to support to [Impress Photo Album Creator extension]
Personal tools