Apache OpenOffice (AOO) Bugzilla – Issue 98252
Slideshow quality insufficient for professional usage (all platforms: objects not round, Linux: not anti-aliased)
Last modified: 2017-05-20 11:08:22 UTC
Hi, please have a look at the attached three screen shots. (Make sure to view them in native resolution, 100%.) As you can see Impress WindowsXP looks like an anti aliased image but the object is not round. It looks like connected lines with some white space between. OOo Linux has the same problem (not round) AND it is not anti aliased. Just look at the attached Powerpoint screen shot that shows how it should also look like in Impress.
Created attachment 59497 [details] Linux
Created attachment 59498 [details] Windows
Created attachment 59499 [details] Powerpoint Windows
Created attachment 59500 [details] ODP
Created attachment 59501 [details] PPT
Reproducible. But you might be interested to hear that this has been improved in latest build DEV300m39 (CWS aw059, issue 28526).
Hi wg, thanks for your response. But in Issue 28526 you say: ------- Additional comments from wg Mon Jan 5 07:39:29 +0000 2009 ------- @dengel: the changes that have been made are for edit view only. Anti-Aliasing for slideshow is another area.. ------- ------- ------- ------- ------- ------- ------- ------- ------- So what is correct? With THIS issue I mean the slideshow! I re-open this issue and waiting for your response.
Is there are requirements spec for the Anti-aliasing feature? My view is that AA-rendering in the slideshow view is more important than for edit view, so this feature should not be in a full release until both slideshow and edit-view have AA-rendering. (otherwise it's a regression).
> so this feature should not be in a full release until both slideshow > and edit-view have AA-rendering I don't think so. please note that all OOo 3.0 application have no anti-aliasing for edit-view. In Draw for example it is a big advantage to have drawings displayed anti-aliased. So anti-aliasing for edit-view only is better than no anti-aliasing. But you may be right that the users could be irritated when he notices that the slideshow looks worse than the edit-view.
@bryancole: you can find the spec at : http://specs.openoffice.org/appwide/drawing_layer/SolidDragging.odt
AW: You are mixing up all kind of issues here. AA for edit view had a lot of votes and needed intensive preparation. AA for Slideshow depends on the system and the UNO API canvas renderer used, so it works on some systems and not on others. Both graphic systems are pretty separated (by purpose). So the first thing to do is to specify excactly at which version You see a defect and on which system (and probably with which distribution, too). I will set this issue to THB, he is the best to give a comment to the slideshow AA problematic.
AW: Adding myself to CC
I'm not sure if this is only an AA problem. The picture also looks not round, like connected lines. Is it possible that there are more problems in slideshow mode? Perhaps the image is rendered in wrong (not screen native) resolution and scaled on bitmap level to the screen? Please carefully(!) view the attached ooo300windows.png at native resolution (100% scaling). It IS anti-aliased but nevertheless it looks angeled like connected lines with some white space. This strange effect can be better seen in the attached ooo300linux.png (kubuntu 8.10 intrepid ibex 32-bit) where AA is missing.
AW->norbert2: With which version is ooo300windows.png created? If it's OOo3.0 as in field 'Version', then yes, it will not be round. For DrawingLayer, staring from DEV300 m30, it will look round. That was the reason for the three-year deep change of the needed internals. Please refer to CWS aw033 changes, tasks and comments for that. I cannot speak for Slideshow, though. THB?
Yes, it was created using the "official" OOo3.0 final release. The windows screen shot has been created with a portable build of OOo 3.0.
And why does AA not work for Linux build? is this fixed in DEV300 m30, too?
AW->norbert2: So please get a DEV300 m39 and check there (as WG already hinted correctly); it should be massively improved there for DrawingLayer.
... I will try DEV300 m30 Linux build and report the result here.
Where can I download DEV300 m39?
AW->norbert2: AA for linux build is activated from DEV300 m39 (as can be seen in CWS aw059, the added tasks and comments) AW->norbert2: Why DEV300 m30? Again: AA is activated staring from DEV300 m39 AW->norbert2: Where did You get DEV300 m30? Just use OpenOffice.org (see http://download.openoffice.org/test/other.html). HTH!
Created attachment 59576 [details] DEV300m 39 (Build 9378) in slideshow view running on kubuntu linux 810 intrepid ibex 32bit.png
Da haben wir wohl aneinander vorbeigeredet weil ich meinen Browser nicht aktualisiert hatte. ;-) ----------------- The edit view looks good in m39 but I cannot see improvements in slideshow mode. Please have a look at the attached "DEV300m 39 (Build 9378) in slideshow view running on kubuntu linux 810 intrepid ibex 32bit.png"
While edit view is anti aliased and round slideshow view still looks like connected lines and is NOT anti aliased.
Perhaps it looks a little bit better compared to OOo 3.0 final release but in m39 the quality is still not acceptable.
AW->norbert2: Again: I did not talk about Slideshow as mentioned multiple times now. But when You talk about Sliseshow, You HAVE to say on which system (also said already: Different on different Systems, even on different distributions partially). So, please, when writing something like "Perhaps it looks a little bit better compared to OOo 3.0 final release but in m39 the quality is still not acceptable", add on WHICH System and if You are talking about DrawingLayer OR Sliseshow, else this statement is useless for us. Also interesting (and new) for me: the *.png is NOT from graphics export, but from a screenshot ?! Again here: System, Slideshow, DrawingLayer...(version is know now at least) ? As long as You have no more problems on DrawingLayer (i guess this, is NOT clear from Your entries) i am out anyways. THB will comment on slideshow. To allow him that, please add information about the System and the distribution You are using. Thanks.
norbert2->aw: > Again: I did not talk about Slideshow as mentioned multiple times > now. This issue is about slideshow! So i talk about slideshow. > add on WHICH System Just look at the screenshots file name. It contains so much information for a file name. ;-) > As long as You have no more problems on DrawingLayer If DrawingLayer=EditView so I can confirm that it looks good and is anti aliased. So again, this issue is about sideshow!
AW->norbert2: Okay, thanks for confirming. DrawingLayer == EditView is correct. When DrawingLayer is out (and i am, too), this indeed is a Slideshow task from now on, so THB should be in now. BTW: How do You like DEV300 m39 (FullDrag, AA, better Selection in SW)...?
> BTW: How do You like DEV300 m39 (FullDrag, AA, better Selection in SW)...? norbert2->AW: Nice. And I can confirm that these features all work in Linux build.
Ok, first off, switching on slideshow AA on Linux is merely a matter of enabling cairo -> @mh @rt: any reason that's not yet switched on? @norbert2: the "connected lines" problem is caused by emulated line stroking in the drawing layer, which then passes down a split-up polygon to slideshow. @aw: any chance to use VCL's LineInfo for stroking, when possible (I know it will only catch a few common cases)? Other than that, the slideshow now needs to make use of the new drawing layer natively, such that we get exactly the same output as in edit view. I take this part of the issue for one of the next 3.x feature release versions.
>@aw: any chance to use VCL's LineInfo for stroking, when possible (I know it >will only catch a few common cases)? AW->THB: In the MetaFile, all comment actions still exist (and are emuated with big effort :-) using SvtGraphicStroke and relatives, so a quick advancement would be possible now, too. Of course using primitives in slideshow will be superior to that in maaaaany aspects...
> Ok, first off, switching on slideshow AA on Linux is merely a matter of enabling > cairo -> @mh @rt: any reason that's not yet switched on? I'm the wrong addressee here. I do not set such switches unless unless developers ask me to do so.
@aw: ah, way cool, didn't know as cppcanvas currently does not interpret GraphicStroke (it was largely broken before).
@af: Thanks for taking a look. You should at least use cairocanvas now.
I'm adding ENABLE_CAIRO TRUE to the oracle build for unxlngi6 and see what happens. cl->thb: anything else I have to look at?
@cl: there's nowadays a bit more, have a look into configure.in, search for ENABLE_CAIRO there - FWICT also BUILD_PIXMAN needs to be set.
After just setting ENABLE_CAIRO to yes and doing a complete build everything works fine on a current suse. Added change to cws impress191. This will enable anti aliased rendering for slideshow on linux platforms (unxlngi6). I found some minor regressions when it comes to complex geometry (thick dotted lines for circles, wrong scaling in some obscure metafiles) but I think the overall benefit is more important than some issues we can fix later.
verified in cws, back to qa @cl->wg: this issue is only about unxlngi6.pro
cl->thb: you where right, the evolution data source crashes if no pixman is installed *sigh* adding that...
Since adding pixmap is more work than I expected, I have to remove this from cws impress191. @cl->thb: why is no *.so build for pixmap? Do you see any problems adding a pixmap.so to the OOo build?
set to new
@cl: I recall it worked once - though we seem to patch this slightly, although I fail to see the material difference - bit in a hurry now, so take it with a grain of salt etc etc
Created attachment 70021 [details] cairo patch
Created attachment 70022 [details] pixman patch
@cl: and of course there's BUILD_PIXMAN, as I mentioned earlier. ;)
I am affected by this bug too on OOo 3.4. But what's going on now, since Oracle is not supporting OOo anymore? Shall we open duplicate bugs on Libre Office?
Reset assigne to the default "issues@openoffice.apache.org".