Bug 30519 - Bad transitions if "use hardware acceleration" is enabled
Summary: Bad transitions if "use hardware acceleration" is enabled
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: David Tardon
URL:
Whiteboard: target:3.7.0 target:3.5.5 target:3.6....
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-30 15:14 UTC by RGB
Modified: 2012-08-03 12:33 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Simple sample file with screenshot showing the problem (32.83 KB, application/vnd.oasis.opendocument.presentation)
2010-10-01 08:26 UTC, RGB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description RGB 2010-09-30 15:14:38 UTC
When "use hardware acceleration" is enabled, all "cover" variants for slide transitions do not work as intended: it seems effect goes below the current slide, instead of on top (you can see some "movement" around the slide, but nothing over it). By disabling hardware acceleration on Tools -> Options -> LibreOffice -> View, the "cover" transitions works as intended.
Tested on beta1 of LibreOffice 64 bits on openSUSE 11.2
Comment 1 RGB 2010-09-30 15:17:15 UTC
Of course, I'm talking about Impress... ;)
Comment 2 Raphael Bircher 2010-09-30 15:36:55 UTC
Are you able to attach a exemple? It would help a load. Thanks
Comment 3 RGB 2010-10-01 08:26:52 UTC
Created attachment 39102 [details]
Simple sample file with screenshot showing the problem

A simple Impress file with one of the "cover" transitions enabled on all slides. Last slide include a screenshot showing the problem. When disabling hardware acceleration, the transition works as expected.
Last bit of info: an intel 965 integrated video card.
Comment 4 Jan Holesovsky 2010-10-14 04:36:21 UTC
Radek: For you?
Comment 5 Rainer Bielefeld Retired 2010-12-12 09:31:12 UTC
NOT Reproducible with "LibreOffice 3.3.0 RC1 - WIN XP English UI  [OOO330m17 (build 3.3.0.1)]", related to LINUX, graphic card or something else?

@RGB:
Still a problem with RC1?
Comment 6 RGB 2010-12-12 15:24:19 UTC
(In reply to comment #5)
> NOT Reproducible with "LibreOffice 3.3.0 RC1 - WIN XP English UI  [OOO330m17
> (build 3.3.0.1)]", related to LINUX, graphic card or something else?
> 
> @RGB:
> Still a problem with RC1?

Yes, still a problem with rc1 64 bits on Linux. With hardware acceleration enabled cover/uncover effects have the bad behavior described above.
Comment 7 David Tardon 2012-06-12 02:47:46 UTC
taking over...
Comment 8 Not Assigned 2012-06-18 01:57:13 UTC
David Tardon committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=012b43d571aaa4f79b7f6fcfa92939e8d19af492

fdo#30519 paint scrolled area from the right surface
Comment 9 Not Assigned 2012-06-18 02:38:05 UTC
David Tardon committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=26130d1c29dba3b597c10fc279145cc42286021d&g=libreoffice-3-5

fdo#30519 paint scrolled area from the right surface


It will be available in LibreOffice 3.5.6.
Comment 10 Not Assigned 2012-06-18 02:38:38 UTC
David Tardon committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=760fba9e415291ad166a9d3ba1abaf83dda18cf5&g=libreoffice-3-6

fdo#30519 paint scrolled area from the right surface


It will be available in LibreOffice 3.6.
Comment 11 Not Assigned 2012-06-18 13:10:12 UTC
David Tardon committed a patch related to this issue.
It has been pushed to "libreoffice-3-5-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f9ef83a80fb05274e4c5268459d84af9b4558df1&g=libreoffice-3-5-5

fdo#30519 paint scrolled area from the right surface


It will be available already in LibreOffice 3.5.5.
Comment 12 Björgvin Ragnarsson 2012-08-03 12:33:02 UTC
*** Bug 43495 has been marked as a duplicate of this bug. ***