To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=93945
------- Additional comments from [EMAIL PROTECTED] Mon Oct 20 09:46:31 +0000 2008 ------- Again, several problems come together: 1) Painting the table takes very long (upward of 1s). The tables, Write OLE objects, are represented as metafile. Paint the table just have to iterate over the actions of the metafile and paint them. One type of action that takes relatively long to render is a text action. What makes painting so long is the setup of the clipping polygon. While in most cases (for this document) clipping is restricted to simple rectangles, sometimes the clipping area is the union of four rectangles. When done completely in VCL this would not be a problem because the Region class is optimized for this. The problem arises from the clipping area represented as com::sun::star::rendering::XPolyPolygon2D. However, text is still painted by VCL, even when everything else is done by the canvas. So, the clipping polygons are transformed to basegfx polygons and eventually to VCL Regions. Any knowledge about being a union of rectangles is lost at that point and the general conversion of polygons to Region is used. This involves the creation of data structures for every pixel line that the text spans in vertical direction. These are later optimized into just a handful but still this process is very time consuming. 2) Changing properties of animated shapes that are not visible cause painting of the background (the table in this case). The reason for this is, so I assume, the assumption that this case does not occur regularly. When the lower frame is faded in the following happens: the table is painted once. This takes very long as explained above. As a result the two animation actions for fading out the upper red frame are started simultaniously: one action for smoothly setting the alpha value from 1 to 0 and one to turn off visibility of the whole shape. The later action is intended to be started when the former is almost done. When both are started at once then visibility of the shape is turned off right away and then the alpha alue is modified for the next 1 second. This results every time in a request to repaint the background, the table in this case. The reason for this is, probably, that in the usual case when the visibility of a shape is turned off then it is converted from a sprite into a regular object that is part of the background. Therefore the background has to be painted. 3) The scheduling of animations does not really handle delays very well. As already said above, it can happen (this is a timing problem, it does not always happen) that when the upper red frame is faded out and the lower frame is faded in, the table in the background is painted once and this takes so long that it screws up the scheduling of pending animation actions. The actions for fading out the upper frame are scheduled to be started 1 (0.995 seconds to be precise) second apart. When painting the table takes longer than that second and is done at the wrong time then both actions are started at the same time. One is overdue more than one second, the other only a short time. This leads to the process as described above: visibility of the upper frame is turned off but its alpha value is constantly modified. This results in frequent repaints of the table which, as already observed, takes very long. Luckily, these repaints are done for simpler clipping areas, so repainting the table takes only about half a second. It could be worse and take the same 1.5 seconds as the repaint that started the whole mess. Well, the half second repaint causes the frame rate of the fade-in animation (remember, the fade-out animation already failed completely) to drop to a value between 1 and 2. Animation is not the best word to describe this. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
