Created attachment 68022 [details] screenshot - Open attachment 46857 [details] Expected: - see attachment 46858 [details], without black border, of course! - the image in top-right should not have a background Actual: - see screenshot attached - the image in top-right have blue background, as indicated by arrows Tested on Windows XP NOT REPRODUCIBLE from W2008R2@20-With-Symbol-Bytemark-Hosting, pull time 2012-09-25 09:47:35, core: eebc9748d2ea26a7b5af246dba115103d6bb15db REPRODUCIBLE from W2008R2@20-With-Symbol-Bytemark-Hosting, pull time 2012-09-26 20:38:48, core: 106a1b4eba1303e1d989eb67eff63ed864500578 Still REPRODUCIBLE from W2008R2@20-With-Symbol-Bytemark-Hosting, pull time 2012-10-01 05:02:30, core: e12f501bebf83ea8121e517283c25c24587268a7 So a recent regression in master.
Still Reproducible on Windows XP with master pull time 2012-10-25_22.55.31. NOT Reproducible on Linux Git bisect and found that first bad commit is: http://cgit.freedesktop.org/libreoffice/core/commit/?id=f0efecfb69b336e064e7c8dd2597655eff07944f
Created attachment 69157 [details] Screenshot of sample slide made with LOdev 3.7 (Master) 2012-10-27 on Mac OS X The attached screenshot, made with the LOdev 3.7 (master) build dated 2012-10-27 on Mac OS X 10.6.8 (Intel), shows that the bug is not reproducible on Mac OS X.
Tibby - when bisected appears to come near your commit - any thoughts on this master regression ? :-)
I am unable to reproduce on Bodhi Linux with Master pulled two days ago.
(In reply to comment #4) > I am unable to reproduce on Bodhi Linux with Master pulled two days ago. So all comments confirm that this bug appears on Windows only. Anybody to confirm it (officially) on Windows?
Adding Rainer to this as I know he has a recent build on Windows. Rainer can you test this out?
1 Regression is enough NOT Reproducible] with parallel installation of "LOdev 4.0.0.0.beta1 - GERMAN UI / German Locale [Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)]" {tinderbox: @6, pull time 2012-12-06} on German WIN7 Home Premium (64bit) with separate /4 User Profile for Master Branch with a self created .pptx containing y .png with transparent bakcground area. Looks fine in edit mode and slide show. Anti aliasing and hardware acceleration do not matter. @Korrawit: Can we get a sample document with brief comments concerning it's history? You get the problem during the running slideshow or in edit mode or both?
Created attachment 71352 [details] Not reproducible here @Korrawit: Can you please test this .pptx (MSO2003) created with LibO 3.6.4.3? For me it works fine, right smiley shown without background, left smiley as expected with background.
Comment on attachment 71352 [details] Not reproducible here Wrong document
Created attachment 71353 [details] This one works for me Details see Comment 8!
Rainer, Thanks for testing, but could you please test again with: (In reply to comment #0) > - Open attachment 46857 [details] Thanks in advanced :)
I just tested again with 4.0.0.0.beta1 on Windows 7 x64, and it's reproducible only in edit mode. Presentation mode: not reproduced. I didn't check another version whether presentation mode affected. But with all tested and reproduced versions, it affects edit mode.
(In reply to comment #12) > I just tested again with 4.0.0.0.beta1 on Windows 7 x64, and it's > reproducible only in edit mode. Presentation mode: not reproduced. Sorry, I forgot to say that, this is for the file mentioned in comment 11.
Where have I had my eyes?! Works fine with "LibreOffice 3.6.4.3" German UI/ German Locale [Build-ID: 2ef5aff] {pull date 2012-11-28} on German WIN7 Home Premium (64bit). [Reproducible] with parallel installation of "LOdev 4.0.0.0.beta1 - GERMAN UI / German Locale [Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)]" {tinderbox: @6, pull time 2012-12-06} on German WIN7 Home Premium (64bit) with separate /4 User Profile for Master Branch. I see 2 Effects, a) the semi transparent background rectangles as shown in the screenshots in presentation edit mode b) in Slideshow some "background colored St. Elmo's fire" The picture itself seems ok? I extracted it after having saved the slideshow as .odp from 3.6.4 and 4.0, no difference, works fine, also when I import the pictures into the sample. But stop, the problem also disappears when I save the sample document from LibO 3.6.4 AND when I save it from LibO 4.0 as .odp. This causes very bad other problems, but the picture background disappears. Compression problem or similar? I will have to think about that tomorrow.
I hoped in vain to find some relations or similar. We had some other picture problems with MS XML document import, but this one seems different to any other problem I find or remember.
I don't see this with master for the 1st document; it's unclear what the 2nd (comment #10 Rainer?) is supposed to show. I see two smileys, one in a white rectangle, one without (identical to 3.6.x). I'm using a build from: bb3f2900a867fdcb6df916fff58199b4ce94dd05
Comment on attachment 71353 [details] This one works for me Sorry, this attachment has nothing to do with the bug, i simply did not see - Open attachment 46857 [details] in the original report- @Michael: Sorry, may be I mislead you to do the same mistake?
Korrawit - thanks for the bisection: can you still reproduce with a recent 4.0 or master build ? Noel this was kindly bisected by Korrawit to near your commit - any thoughts ?
(In reply to comment #18) > Korrawit - thanks for the bisection: can you still reproduce with a recent > 4.0 or master build ? Noel this was kindly bisected by Korrawit to near your > commit - any thoughts ? no idea, if it is the commit identified in comment #1 then indeed I am the comitter but not the author see comment #3 if indeed it is that commit then strange that this is windows specific :-/ Also that patch doesn't tweak the transparency ( but the shadow transparency ) I had a windows build ( dated 2012-12-13 ) and I still see this problem present with it so it appears to be still an issue. Also noticed if the transparency is changed e.g. to select 50% ( and then changed back again to no transparency ) then the bad effect is gone. Perhaps there is some strange property setting order ( or timing related ) issue that only rears it's head on windows. No idea though still if the commit above really does trigger this or not ( that patch itself though looks ok )
ok firstly it is the patch that causes the problem, it appears that it really is the shadow transparency that affects things. But also the shadow transparency value imported is good. It seems that how that shadow is applied to the shape is somehow broken on windows. No idea about that stuff I'm afraid, not sure who would know maybe radek?
(In reply to comment #20) > ok firstly it is the patch that causes the problem, it appears that it > really is the shadow transparency that affects things. But also the shadow > transparency value imported is good. It seems that how that shadow is > applied to the shape is somehow broken on windows. No idea about that stuff > I'm afraid, not sure who would know maybe radek? and also worth noting that on 3.6 this doesn't seem to be a problem ( I had a 3.6 windows build and applied the patch, don't see the same nasty effect when changing shadow transparency )
+ rPropMap.setProperty( PROP_ShadowColor, maShadow.moShadowColor.getColor(rGraphicHelper, -1 ) ); + rPropMap.setProperty( PROP_ShadowTransparence, maShadow.moShadowColor.getTransparency()); etc. all get shoved into a: typedef ::std::map< sal_Int32, ::com::sun::star::uno::Any > PropertyMapBase; I wonder if some iteration order for that is different between the win32 std::map and everyone else's (somehow).
(In reply to comment #22) > + rPropMap.setProperty( PROP_ShadowColor, > maShadow.moShadowColor.getColor(rGraphicHelper, -1 ) ); > + rPropMap.setProperty( PROP_ShadowTransparence, > maShadow.moShadowColor.getTransparency()); > etc. > > all get shoved into a: > > typedef ::std::map< sal_Int32, ::com::sun::star::uno::Any > PropertyMapBase; > > I wonder if some iteration order for that is different between the win32 > std::map and everyone else's (somehow). nah, don't think so, like I said changing the shadow transparency manually with the test document and you get the strange effect ( I was confused previously by changing the normal shape transparency which has the side effect of clearing the shadow transparency which in turn makes gets rid of the strange background border effect )
*** Bug 58782 has been marked as a duplicate of this bug. ***
Sorry for very late reply :( This bug disappeared since http://cgit.freedesktop.org/libreoffice/core/commit/?id=edf54efa7f939be9b289f94ed4f19fb8322660ef (in branch -4-0) commit edf54efa7f939be9b289f94ed4f19fb8322660ef Author: Michael Stahl <mstahl@redhat.com> Date: Fri Dec 21 13:54:43 2012 +0100 fdo#55044: OutputDevice::ImplDrawAlpha: reset members before calling GetBitmap(), as apparently they are used by GetBitmap(), resulting in missing/not rendering parts of the preview image in the bugdoc. (regression from c0ce7ca4884f7f6d1016bd1dbcc22066cb4a7797) Change-Id: I02a6abb822900e1a28a1c632a122c1e093b73553 (cherry picked from commit 06968a96afd334c276b425bf6b809c011f88b716) But I don't know how the fix also affects this bug. Marking as RESOLVED/WORKSFORME