Created attachment 53110 [details] Problem with transparency gradient There is a problem with the 'transparency gradient' (linear, axial, radial, etc) in Impress, when turning to presentation mode. It is a regression from openoffice, but present since the first version of LibreOffice. The best way to see it is the following: 1) Make a new slide with black background; 2) Draw a shape and fill area with black (so you have a black shape on black background); 3) Right click -> Area -> Transparency -> Gradient and choose for instance a linear one; 4) Start the diaporama (F5) and wait for the rendering: your black form isn't black anymore ! See test files in attachment for illustration... Even if this functionnality can be considered as not essential, this bug can be a big problem, affecting the retro-compatibility with openoffice: for instance, an enterprise using transparency gradient for its logo (made on OpenOffice) is very very annoyed ! This bug was reported, but mixed with other problems, in bug 35681. As it was recently closed, but not completely fixed, I open this one with a specific description.
Created attachment 53111 [details] Other illustration of the problem with transparency gradient.
[Reproducible] with "LibreOffice 3.4.4 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:402)]" I created a new example from reporter's ones only showing contents related to report. To reproduce the bug simply open "Test_new344.odp", start presentation and compare pictures with "So it looked in Edit mode", you will see strange differences. Related or not? copy /paste as Bitmap also shows strange gradient geometry modifications, but mostly different from those visible in presentation mode @Radek: Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Created attachment 53474 [details] Sample Document See comment 1
@Rainer Bielfeld: I don't understand why you truncated my test file. Moreover, why did you change my title? With my old title 'problems with transparency gradient in presentation mode', every slide of my test file was relevant, especially the first one, which exactly repeat the procedure described in comment 0. Please note that the problem is more than just a geometrical one. Maybe you didn't see exactly what the problem is: when you run the first slide of my file in presentation mode, the screen will be black for few seconds, but if you wait a little (the rendering process takes some time), you will see the relevance of this slide !
bugzilla-daemon@freedesktop.org schrieb: > @Rainer Bielfeld: I don't understand why you truncated my test file. Hi, Your document demonstrates various problems with common subject "gradient/transparency", but very different manifestations and roots. As I told you several times when you posted again and again the various elements of your sample document in various reports, it is important to submit different reports for different problems. > Maybe you didn't see exactly what the problem is: You are wrong. I see all the problems demonstrated in your documents very clear. Some of the problems have already been fixed in Master some are in the fixing process, only the geometry problem is a new one that hadn't been reported until now. So I stripped away all known problems and left the relevant new one. CU Rainer
@Rainer: Thanks for your answer. I am glad to hear that the problem displayed in the first slide of my test file is already solved :) I was afraid about that because the patch proposed for bug 33591 don't solve it (it is another problem, which don't involve 'transparency gradient'). Actually, this bug 42553 is in some way a duplicate of my old bug 36547, but with a more precise description. Note that Bug 36547 was considered as a duplicate of bug 36470, and bug 36470 as a duplicate of bug 33591, and now bug 33591 as fixed. But bug 36547 is not fixed by the patch for bug 33591, it's a different problem. So my question is: as neither bug 33591 nor bug 35681 solve the problem described here in comment 0 (illustrated on the first slide of my initial test file), which bug fixed it in the master branch ? In all cases, the new title about gradient geometry isn't in adequation with my description in comment 0...
I can also confirm this bug. Along with the one I reported some time ago (#39369), it makes Impress totally unusable for anything more than trivial slides.
@Radek: Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Not working with 3.4.4 on Ubuntu I will have a look at it with 3.5 soon
persists in 3.6 (master), unrelated to cairo / hardware acceleration. Odd that it is independent of size / zoom - we can render that gradient at that size correctly; -but- when we render it in a presentation we bust it ;-) Perhaps some metafile replay thing ?
(In reply to comment #10) > persists in 3.6 (master), unrelated to cairo / hardware acceleration. > Odd that it is independent of size / zoom - we can render that gradient at that > size correctly; -but- when we render it in a presentation we bust it ;-) > Perhaps some metafile replay thing ? > So we're all on the same page - in a master build, the only remaining problem I see is that rectangular gradients don't scale horizontally, to completely fill the shape, correct?
> is that rectangular gradients don't scale horizontally, to completely fill > the shape, correct? Seems so, the only obvious problem I see with parallel installation of Master "LOdev 3.6.0alpha0+ – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 35ec153]" (tinderbox: Win-x86@6-fast, pull time 2012-05-02 06:53:41) is in Sample Document slide 2 "Area : black, Quadratic". In edit mode the beams lead to the corners of the shape (not rectangular), in slideshow they are rectangular to each other.
Created attachment 61021 [details] gradient bugs still in master Attached an updated sample document - note that transparency gradient behaves different to std color gradient, and that hw-acceleration on/off affects std color gradient, and *only* that.
See bug 49508 for a similar, but separated problem.
reproduced in 4.0beta1.
Interestingly, the square gradient in slideshow mode is rendered by vcl's ImplDrawComplexGradient But in editing mode it appears to be rendered by something else; odd.
Still rather unclear about this; it all seems to work rather nicely except for the 'Square' gradient. The 'Square'-ness of the gradient is rather unclear to me in the drawing-layer impl. [ which I believe is used for the large preview in the gradient dialog ]. The thumbnail there however is rendered with the vcl gradient rendering and is indeed square - which is what we see in the presentation mode. Most odd - did the behavior here really change ?
Created attachment 71331 [details] fix square gradient rendering I'd love some review / feedback on this: Thorsten ?
Thorsten ack'd on IRC; pushed.
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=055fca04a4e00b14e68fa5860b417cb25e471299 fdo#42553 - fix square gradient rendering by vcl. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=54d6055685d0b4b24779708373f7641eeec7d7d6&g=libreoffice-4-0 fdo#42553 - fix square gradient rendering by vcl. It will be available in LibreOffice 4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Compared the display results of 'Test_new344.odp' file between 'LibO-Dev_4.0.0.0.beta1_Linux_x86-64_install-deb_en-US' and 'Version 3.6.2.2 (Build ID: 360m1(Build:2))'. Could not spot the problem in the daily build. (Kubuntu 12.10)