Apache OpenOffice (AOO) Bugzilla – Issue 113080
converting geometry to graphics in edit view produces jagged edges on boundaries to transparent parts
Last modified: 2017-05-20 10:20:30 UTC
Very thick lines have significant rendering problems (spikes and stripes of lighter color) when exported as an image. The problem is not evident when anialiasing is disabled. The image attached shows a solid-colored line 8mm thick.
Created attachment 70495 [details] Sample image showing problem
Yes, I can confirm that problem, for example pls. see a.m. link or <http://de.wikipedia.org/wiki/Drehschieberpumpe> where I contributed images showing that problem. But a quick test with "Ooo-Dev 3.3 multilingual version English UI WIN XP: [DEV300m84 (Build 9512)]" did not show the problem. @jes: Can you please contribute a step by step instruction how to reproduce that problem with a new DRAW document "from the scratch"?
Oops--I didn't think to check m84. Good point! Testing "OOo-dev 3.3 300m84(Build:9512)" I see the same problem, however. Here's a sample file made with m84. Steps to reproduce: 1) File > New > Drawing 2) Create a Bezier curve 3) Set the line thickness; values >5mm make the problem easier to see. I used 8mm in the first sample and 0.6" in the second. 4) Select the line 5) File > Export; Selection: YES; Type: PNG
Created attachment 70496 [details] Sample document showing problem
NOT reproducible with "Sun Jul 11 12:51:00 +0000 2010: Draw_thick_line_fill.odg" and "Ooo-Dev 3.3 multilingual version English UI WIN XP: [DEV300m84 (Build 9512)]" - strange!
The previous sample file I uploaded was incomplete; here is the file I intended to provide.
Created attachment 70498 [details] updated sample file
Still not reproducible at all
Not reproducible on windows with m84 , too. @jes: which OS are you on and do you use a compression for png?
putting aw on cc, can you see something from the attached png?
AW: What You see are the single filled areas the fat line is composed of on systems which do not directly support fat line painting in their sub-systems. Bad AA renderers often do not paint geometrically correct touching edges correct. The pixels on the edges of two identical edges should add up to the object color in a correct AA renderer. If they do not normally the only workaround is to paint the polygon fills non-AAed and to extra-paint the polygon edges over it as hairlines. Caution: This may lead to problems when transparency is used, so all geometry has to be painted in a single run with a single transparency.
cl->aw: thanks for the in depth technical analysis. Any chance on a version that can be understand by the qa people and will help them locate the source of the problem and why jes has it and others can't reproduce? :-)
AW: Don't underestimate QA :-) Serious: It depends of what is done on which system. E.g. Win uses GDi+ to render fat lines directly, at least in editview (and AFAIK in exporters which fetch bitmap data from GraphicExporter). If OTOH the output is generated by transporting information using a Metafile, it is never easy to find out who renders it using what. So, in general: Not easy to find out. We will need a description on which system we are, if there is XRender (if linux) and exactly in which way the graphic is created. Or short: We need a description to reproduce it (as always and as You know)
AW: Tried with DEV300m84 on WIN, using selection (and whole page), transparent and not, could not reproduce.
AW->rainerbielefeld, jes: Still saw no information on what System You are getting this. Please add information.
So sorry! I don't know why I keep forgetting to include this... I'm on Fedora Linux 13, using the nouveau hardware driver. I can attach an Xlog file, if you need more detail. The log does mention the RENDER extension: $ grep -i render /var/log/Xorg.0.log [ 28.918] (II) Composite (RENDER acceleration) [ 28.921] (II) Initializing built-in extension RENDER I use the default compression level (6) for the PNG export. I get the same result if I export as BMP or TIFF. I've seen a similar problem before with PDF export: a large area is painted as several sub-areas and the pixels where they touch are lighter than the rest because of the aa. But what seems odd is that I don't see any problem on screen, in the editing view, or in exported PDF--only in the exported images. I would have thought that images would be rendered by cross-platform code, giving the same result everywhere.
I changed my PC. I saw the reported problem (pls see links to pictures) for pictures created with a WIN XP Athlon 3200+ PC 1GB RAM ATI RAEDON 9600 Currently I use Processor: AMD Athlon 64 Bit 3500+ Hauptspeicher: 1GB Graphic Card: Nvidia GeForce 7300 LE Monitor : 1024*768 OS: WIN XP SP3
AW->jes: Thanks for the info. >I'm on Fedora Linux 13, using the nouveau hardware driver Does this mean that all worked before You started to use 'the nouveau hardware driver'...? Error happens definitely in created bitmap, thus independent from bitmap export format. When You do not see it on screen, it really gets odd. Checked the code in the GraphicExporter; normally indeed a complete repaint of a view happens. Interestingly it can also happen there that a metafile is recorded and then converted using the (stone-old) GetBitmapFromMetaFile. AW->jes: Does this also happen when You do not select the shape and do not use the 'selection' checkmark in the dialog, but export the whole page...?
>I'm on Fedora Linux 13, using the nouveau hardware driver Does this mean that all worked before You started to use 'the nouveau hardware driver'...? No. I only mentioned it as part of my software/graphics environment. > When You do not see it on screen, it really gets odd. ... I double-checked the editing view: even zoomed in, the thick line is painted uniformly. > AW->jes: Does this also happen when You do not select the shape and do not > use the 'selection' checkmark in the dialog, but export the whole page...? Good point! No, the problem definitely does _not_ happen if I export the entire page as PNG.
>I double-checked the editing view: even zoomed in, the thick line is painted >uniformly. Yes, that's because the new rendering layer using primitives can handle graphic oddities (as this one) as needed. AA graphics is not as straighforward as one might think... >Good point! No, the problem definitely does _not_ happen if I export the entire >page as PNG. Then we have it. AW->CL: Reason is that UnoGraphicExporter in GraphicExporter::GetGraphic still uses GetBitmapFromMetaFile. This internally still triggers a VCM Metafile paint which was never (and is not) capable of handling AA cases correctly. The code following 'if( !bSingleGraphic )' should be changed to not use GetBitmapFromMetaFile but to render to a bitmap-equipped VDev directly to use the higher render capabilities of the used sdr::contact::ObjectContactOfObjListPainter directly. When first creating a Metafile (as currently) and then letting VCL change that to a bitmap data construct, AA will be not well supported, possibly in more cases that this one.
@aw: do your comments Mon Jul 12 mean: Confirmed / NEW?
AW->rainerbielefeld: Depends on this being reproducable now, i think. Adding CL to CC.
ALG: Taking over
This Issue requires more information ('needmoreinfo'), but has not been updated within the last year. Please provide feedback as requested and re-test with the the latest version of OpenOffice - the problem(s) may already be addressed. You can download Apache OpenOffice 3.4.1 from http://www.openoffice.org/download Please report back the outcome of your testing, so this Issue may be closed or progressed as necessary - otherwise the issue may be Resolved as Invalid in the future.
Re-tested with AOO 3.4.1 on Fedora 17, Nvidia X driver. Both problems are still visible: the thick curve is cropped and has the rendering artifacts as shown in the (updated) sample file. # grep -i render /var/log/Xorg.0.log [ 21.513] (II) NVIDIA(0): Initialized X Rendering Acceleration [ 21.515] (II) Initializing built-in extension RENDER
Re-tested with nightly build: AOO350m1(Build:9611) - Rev. 1442201 2013-02-05_04:29:57-Rev.1442466 Looks great! No more clipping of the thick line, and any rendering artifacts seem very minimal. The object is now exported over a transparent background (nice!), but it seems that the edges of the thick line are not antialiased: they are jagged and sharp. The aa option under Tools > Options > AOO > View is ON. As far as I'm concerned, this report can be closed: the current result may not be perfect but it's good enough.
ALG: Hi Joe, thanks for checking. I will anyways take a look where the jagged edges come from, I'm curious myself.
Created attachment 80505 [details] Draw screen shot Still reproducible on current trunk, on screen, in edit view. ~]$ uname -a Linux localhost 3.8.5-201.fc18.x86_64 #1 SMP Thu Mar 28 21:01:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ~]$ lspci -vv 01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS880 [Radeon HD 4290] (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device 8454 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at d0000000 (32-bit, prefetchable) [size=256M] Region 1: I/O ports at b000 [size=256] Region 2: Memory at fe5f0000 (32-bit, non-prefetchable) [size=64K] Region 5: Memory at fe400000 (32-bit, non-prefetchable) [size=1M] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: radeon
ALG: Adapted title, grepping, taking a look.
"alg" committed SVN revision 1465948 into trunk: i113080 added test code (in debug mode), cleanedup a small inconsistency
ALG: Fixed
Testing AOO400m3(Build:9702) - Rev. 1502185 2013-07-11 08:22:42 (Thu, 11 Jul 2013) - Linux i686 on Fedora 17 Viewing thick line selection exported to PNG image: Clipping and jagged edges look great now; thick line filling still shows segments, same as in first attached image, above. I'm not clear whether the segments are an X problem or not. Please let me know if I need to provide more info.