Issue 113080 - converting geometry to graphics in edit view produces jagged edges on boundaries to transparent parts
Summary: converting geometry to graphics in edit view produces jagged edges on boundar...
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: save-export (show other issues)
Version: OOo 3.2.1
Hardware: PC All
: P3 Trivial (vote)
Target Milestone: 4.0.0
Assignee: Armin Le Grand
QA Contact:
URL: http://commons.wikimedia.org/wiki/Fil...
Keywords: needmoreinfo, oooqa
Depends on:
Blocks:
 
Reported: 2010-07-11 05:06 UTC by Joe Smith
Modified: 2017-05-20 10:20 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Sample image showing problem (46.48 KB, image/png)
2010-07-11 05:08 UTC, Joe Smith
no flags Details
Sample document showing problem (8.55 KB, application/vnd.oasis.opendocument.graphics)
2010-07-11 13:51 UTC, Joe Smith
no flags Details
updated sample file (32.08 KB, application/vnd.oasis.opendocument.graphics)
2010-07-11 23:35 UTC, Joe Smith
no flags Details
Draw screen shot (111.18 KB, image/png)
2013-04-08 13:06 UTC, Ariel Constenla-Haile
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Joe Smith 2010-07-11 05:06:42 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.
Comment 1 Joe Smith 2010-07-11 05:08:03 UTC
Created attachment 70495 [details]
Sample image showing problem
Comment 2 Rainer Bielefeld 2010-07-11 10:39:12 UTC
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"?
Comment 3 Joe Smith 2010-07-11 13:50:59 UTC
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
Comment 4 Joe Smith 2010-07-11 13:51:48 UTC
Created attachment 70496 [details]
Sample document showing problem
Comment 5 Rainer Bielefeld 2010-07-11 14:04:29 UTC
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!
Comment 6 Joe Smith 2010-07-11 23:34:10 UTC
The previous sample file I uploaded was incomplete; here is the file I intended
to provide.
Comment 7 Joe Smith 2010-07-11 23:35:02 UTC
Created attachment 70498 [details]
updated sample file
Comment 8 Rainer Bielefeld 2010-07-12 07:17:55 UTC
Still not reproducible at all
Comment 9 wolframgarten 2010-07-12 08:20:20 UTC
Not reproducible on windows with m84 , too. @jes: which OS are you on and do you
use a compression for png?
Comment 10 clippka 2010-07-12 11:21:38 UTC
putting aw on cc, can you see something from the attached png?
Comment 11 Armin Le Grand 2010-07-12 12:44:04 UTC
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.
Comment 12 clippka 2010-07-12 12:56:06 UTC
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? :-)
Comment 13 Armin Le Grand 2010-07-12 13:07:26 UTC
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)
Comment 14 Armin Le Grand 2010-07-12 13:41:54 UTC
AW: Tried with DEV300m84 on WIN, using selection (and whole page), transparent
and not, could not reproduce.
Comment 15 Armin Le Grand 2010-07-12 13:44:58 UTC
AW->rainerbielefeld, jes: Still saw no information on what System You are
getting this. Please add information.
Comment 16 Joe Smith 2010-07-12 13:54:44 UTC
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.
Comment 17 Rainer Bielefeld 2010-07-12 14:21:43 UTC
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
Comment 18 Armin Le Grand 2010-07-12 14:22:09 UTC
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...?
Comment 19 Joe Smith 2010-07-12 15:00:42 UTC
>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.
Comment 20 Armin Le Grand 2010-07-12 15:24:40 UTC
>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.
Comment 21 Rainer Bielefeld 2010-07-27 07:34:46 UTC
@aw:
do your comments Mon Jul 12 mean: Confirmed / NEW?
Comment 22 Armin Le Grand 2010-07-27 12:54:35 UTC
AW->rainerbielefeld: Depends on this being reproducable now, i think. Adding CL
to CC.
Comment 23 Armin Le Grand 2012-02-10 13:10:41 UTC
ALG: Taking over
Comment 24 Rob Weir 2013-02-02 03:00:24 UTC
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.
Comment 25 Joe Smith 2013-02-03 02:10:39 UTC
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
Comment 26 Joe Smith 2013-02-05 15:49:57 UTC
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.
Comment 27 Armin Le Grand 2013-04-08 08:52:16 UTC
ALG: Hi Joe, thanks for checking. I will anyways take a look where the jagged edges come from, I'm curious myself.
Comment 28 Ariel Constenla-Haile 2013-04-08 13:06:52 UTC
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
Comment 29 Armin Le Grand 2013-04-09 08:09:41 UTC
ALG: Adapted title, grepping, taking a look.
Comment 30 SVN Robot 2013-04-09 09:40:34 UTC
"alg" committed SVN revision 1465948 into trunk:
i113080 added test code (in debug mode), cleanedup a small inconsistency
Comment 31 Armin Le Grand 2013-07-12 16:07:35 UTC
ALG: Fixed
Comment 32 Joe Smith 2013-07-13 14:19:24 UTC
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.