Bug 914930 - Improve transitions display (2D and 3D) to install package libreoffice-ogltrans
Summary: Improve transitions display (2D and 3D) to install package libreoffice-ogltrans
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: libreoffice
Version: rawhide
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-23 14:22 UTC by Bastián Díaz
Modified: 2013-02-26 04:58 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-26 04:58:42 UTC


Attachments (Terms of Use)
Utility Files (3.44 MB, application/zip)
2013-02-23 14:32 UTC, Bastián Díaz
no flags Details


Links
System ID Priority Status Summary Last Updated
FreeDesktop.org 61353 None None None Never

Description Bastián Díaz 2013-02-23 14:22:25 UTC
Context:
This bug was introduced earlier in fedora 17 and 18 to mark as dependency libreoffice-impress, libreoffice-ogltrans package.

Description of problem:
The problem is a decrease in performance in a number of 2D transitions, when installing the package libreoffice-ogltrans (which does not happen without the package libreoffice-ogltrans). It has a poor performance in most 3D transitions (slow start) and others simply do not work (example: Static and fine dissolve)

Related Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=813202
https://bugzilla.redhat.com/show_bug.cgi?id=872815

Version-Release number of selected component:
Honestly I could not try the rawhide version (the fedora nightly are marked as failed), but introduced the bug so changes can be made in advance (see comment 3 Bug 872815 :P )

I tested with Fedora 18 32-bit - GNOME 3.6.2
LibreOffice 3.6.5.2 and 4.0.1.0

How reproducible:
1. Try 2D transitions in LO (without libreoffice-ogltrans)
2. Try 2D and 3D transitions in LO (with libreoffice-ogltrans)
3. Compare performance of 2D transitions in both cases.
*attached presentations (ODP) with all transitions (fast speed and automatic intervals of 1 second)
  
Actual results:
Transitions with problems (without OGLtrans) (LO 3.6)
→ Cut Through Black: Not displayed
→ Cover (variant left-down and right-down): It displays a large black shadow under the slide.
*In most transitions showed a black shadow (very small, a line)

Transitions with problems (with OGLtrans) (LO 3.6)
*shows the same problems with the transition cover. It adds the right-up variant. 
→ Shape Diamond: slow start
→ Fade Through Black, Cut Through Black and Fade Smoothly: Not displayed (looks a quick cut)
→ All 3D transitions have a very slow start
→ Static and fine dissolve: Not displayed

Transitions with problems (without OGLtrans) (LO 4.0)
*Generally transitions are displayed slightly more fluid
→ Cover (variant left-down, right-down and right-up) It displays a large black shadow under the slide.
→ Fade through black: is displayed slowly
→ Cut through black: not displayed

Transitions with problems (with OGLtrans) (LO 4.0)
→ Shape diamond: slow start
→ Cut through black: not displayed
→ Cover (variant left-down, right-down and right-up) It displays a large black shadow under the slide.
→ All 3D transitions have a very slow start
→ Static and fine dissolve: Not displayed

*The results with LO 3.6 and LO 4.0 are very similar
** The tests were performed with ideal conditions (the only open program was LO)​​. When opening another program (eg Firefox) or used the system screencast of GNOME 3, the performance decreased significantly (eg fade through black not displayed, without ogltrans installed)

Expected results:
That transitions are displayed fluently and uncut :D.

Additional info:
*I have installed on the system, the package libtxc_dxtn.I do not know if it affects the performance of LO transitions.
**I wanted to upload videos as transitions are displayed, but as I mentioned, the GNOME system screencast, significantly affects the performance of the transitions and therefore the results would not be as true to actually visualize.

Thanks

Comment 1 Bastián Díaz 2013-02-23 14:32:42 UTC
Created attachment 701639 [details]
Utility Files

Zip file's contents.

→ Presentations (ODP) having all LO Impress transitions (transition speed: Fast - 1 second intervals between slides)
→ Videos of transitions display (I tried to be as faithful as actually displayed). LO were performed with 3.6
→ Xorg.0.log File

* The tests were performed with a computer video card Intel GMA 3150

thanks

Comment 2 David Tardon 2013-02-25 05:58:16 UTC
(In reply to comment #0)
> Context:
> This bug was introduced earlier in fedora 17 and 18 to mark as dependency
> libreoffice-impress, libreoffice-ogltrans package.

And the dependency was removed again. So you now want to re-introduce it
or what? I admit I do not quite understand. This seems to be a bag of
various issues you have (or think you have) with slide transitions, with
two different versions of libreoffice. That is not the proper way to do
it: you should open one bug for a problem. I am inclined to close this
just because of that...

> 
> Description of problem:
> The problem is a decrease in performance in a number of 2D transitions, when
> installing the package libreoffice-ogltrans (which does not happen without
> the package libreoffice-ogltrans). It has a poor performance in most 3D
> transitions (slow start) and others simply do not work (example: Static and
> fine dissolve)

Yes, we know the 3D transitions are slow-starting.

> Actual results:

3.6 is old. Much of the standing problems with slide transitions have
only been fixed in 4.0. See
https://fedoraproject.org/wiki/LibreOffice/SlideTransitions .

> Transitions with problems (without OGLtrans) (LO 4.0)
> *Generally transitions are displayed slightly more fluid
> → Cover (variant left-down, right-down and right-up) It displays a large
> black shadow under the slide.

Yeah, I see that too. I either missed it earlier or it did not happen on
my previous machine with ATI graphics.

> → Fade through black: is displayed slowly
> → Cut through black: not displayed

It is; the transition shows the outgoing slide for a third of the time,
then black for another third, followed by the incoming slide.

> 
> Transitions with problems (with OGLtrans) (LO 4.0)
> → Shape diamond: slow start
> → All 3D transitions have a very slow start

Yes. The main problem is colorspace conversion of two relatively large
bitmaps (the outgoing and incoming slides) from (typically) cairo to
OpenGL color representations. I had an idea recently to do this in a
thread (one for each bitmap), which should cut the preparation time in
half on multicore machines.

> → Static and fine dissolve: Not displayed

This means that your graphics chipset does not support shaders. Sorry,
but there is nothing I can do.

Comment 3 Bastián Díaz 2013-02-25 08:12:49 UTC
(In reply to comment #2)

At first the problem was limited to Impress dependence with ogltrans package. The first response (logic) is that in the new systems in linux (gnome and kde) with better 3D support would not have problem running libreoffice 3D transitions (if the system works, work transitions), but since it is not actually, temporarily eliminated the ogltras package as dependency impress.

This bug stems from the above, and at one point turned to include the package "ogltrans" by default in the distribution without having solved the problem of transitions.

In short, you are the developer. If LO-ogltrans not impress dependency on fedora 19 and the other problems I mentioned are known, this bug should be closed.

thanks



> > → Static and fine dissolve: Not displayed
> 
> This means that your graphics chipset does not support shaders. Sorry,
> but there is nothing I can do.

I believe the office software should always be inclusive and work on most computers possible.

Suppose I have a computer graphics chipset that supports shaders, and prepared a presentation whose transitions are static and dissolve. The presentation I do on another computer (eg at university) and I have the same OS, the same software (libreoffice) and the same version I have installed on my machine. Start the slide show and everything goes wrong because the transitions are not displayed ... I answer the audience that does not work because the computer's graphics chipset of the university, does not support shaders.

* In Competition (office 2013) this does not happen (unless you use a version of office less than 2007). I've also tried Office 2013 on computers with lower specifications and everything works fine.
The idea is that LibreOffice, which I am a user, is a much better software.

Comment 4 David Tardon 2013-02-25 09:24:32 UTC
> > > → Static and fine dissolve: Not displayed
> > 
> > This means that your graphics chipset does not support shaders. Sorry,
> > but there is nothing I can do.
> 
> I believe the office software should always be inclusive and work on most
> computers possible.

You have it wrong. It should work on as many computers as practical. That is not the same thing.

> 
> Suppose I have a computer graphics chipset that supports shaders, and
> prepared a presentation whose transitions are static and dissolve. The
> presentation I do on another computer (eg at university) and I have the same
> OS, the same software (libreoffice) and the same version I have installed on
> my machine. Start the slide show and everything goes wrong because the
> transitions are not displayed ...

Huh? The worst that can happen is that the transitions do not work. That does not look like a big deal to me. Is the content of the presentation not more important than the bells and whistles around?

> I answer the audience that does not work
> because the computer's graphics chipset of the university, does not support
> shaders.

The audience does not have any clue that something is missing unless you told them.

Comment 5 Bastián Díaz 2013-02-25 17:01:16 UTC
(In reply to comment #4)

* When these transitions are not displayed, they jumped in the picture.

Insist if I'm wrong and the problems I mentioned are known issues, this thread should be closed.

thanks


Note You need to log in before you can comment on or make changes to this bug.