AW: First, it's not "not fixed" with #98289#, that one was (A) an enhancement, 
and (B) a feature for 2D hairlines, so i put this to enhancement. That change 
was never meant to work on 3D, too.
Second, for 3D, this is a completely other feature (since 3D AA works with 
oversampling) and is in no way coparable to the generally implementable 2D 
solution. It is also in no way a regression, since we never supported snapping 
hor/ver hairlines to non-AAed positions in 3D before, so i remove the 
regression keyword, too.
Third, i will add some more mildly interested people to the CC line, just in 
case someone is missing this task...
And forth, i will put this to 3.2 since i am on vacation right now and a 
solution for 3D will not be quickly achievable. It needs to be discussed if 
this is wanted at all. When we do this for our own renderer (and it would have 
to be done in the renderer), everyone else using own primitive renderers 
supporting AA in 3D will have to support it on it's own way from there on.

For 3.1, general AA in 3D will have to be sufficient. It's already a good 
working feature and a big improvement over 3.0 (why, oh why do i have to think 
about reaching small fingers here...).

Greetings from Naples, Florida.

@aw, I understand that from your implementation perspective this might have been
a feature, but from the users perspective the former issue was a defect and this
one is also and it is also a regression from the users perspective as the charts
in the former version have not looked blurry. I understand if this cannot be
solved for 3.1 anymore because of time and resource constraints. But as it is a
regression from the users point of view I think this should be tried to be fixed
with for 3.1.1 then. Have a nice vacation nevertheless you surely have earned it!

AW: I see no reason to concentrate on User's perspective in the task's handling.
I see the user's perspective per se (and take it into account and respect it),
but this is a task from a developer to a developer in a developer issue tracker.
No user is involved yet. The opposite would be correct: when users write tasks,
it's our (and QA's) task to identify and document the technical backgrounds
using reproducible technical descriptions.

The task's title should also - more correctly - at least be something like
'Grids of 3D charts (Hor and Ver hairlines) are blurry when AA is used'. I do
not see that the charts themselves look 'ugly', their display quality is greatly
enhanced.
This description also already shows the dilemma clearly: Hor and Ver lines are
drawn in AA, so OF COURSE they are AAed when not placed exactly on a pixel
(which they are not since definition is view-independent and thus
zoom-dependent). That's what the AA paradigm is about and what was to be
expected with AA being activated. You wanted AA, You got AA.

Don't get me wrong; i see that this is a useful 'optical enhancement' as i
already did and enhanced it for 2D (and will do for 3D), but it is in no way an
error since AA is defined to work that way.

I have to do some annotations here:

- I am not the one who defined what AA does with hairlines, but only use it. AA
is defined to visualize a horizontal hairline which hits two discrete pixel lines

- Avoiding this in 2D (the former task) means some runtime already since every
polygon's edge of a to-be-painted hairline has to be tested for being hor or ver
and to be snapped to discrete units (pixels) during paint

- Doing this 'optical enhancement' actually reduces AA display correctness
(that's why i tend to call it an optical enhancement); this should be known and
accepted for charts

- We can only ensure this 'optical enhancement' in our own renderers which
target pixels, exports to vector formats will not support that (e.g. there is no
way to make a PDF viewer to do the same 'optical enhancement' to hairlines as we
decided to do. There will be more cases, e.g. SVG, PS, ...)

- We will also have to implement that 'optical enhancement' in all existing
canvas renderers to support it during Slideshows

- For 3D, there is not the choice to not-AA single primitives (as is used in
2D), since AA is done oversampling the whole scene (e.g 3x3 for each pixel), so
this is not easily implementable

As can be seen, this simple looking enhancement has some serious drawbacks,
especially when exporting to other formats. Maybe we should find out how our
competitor(s) handle this. Do they suppress AAing the grid? If Yes, what hapens
when it gets exported e.g. to PDF?

BTW: The 2D task to change this had no error status (it was an enhancement).
This task is about exactly the same for 3D, so why handle as error now?

The priority to implement this 'optical enhancement' is from my point of view
not dependent from this flags, i will do it anyways (if my 100% commitment to
performance allows to do this in-between...). If You want to ensure an even
higher priority, use the priority field, please.

Technically, the description of this task is:

"optically enhance the display of horizontal and vertical hairlines for
AntiAliased 3D Scenes". It cannot be described without using the term enhancement.

I am tired of task ping-pong, so this time i will not change back fields, even
when i am convinced this is wrong. I would
- change to enhancement
- change task description to the suggested string above,
but i do not care too much.

The task to do, the work involved and the priority to do it will not change in
any way by this from my point of view.

AW: After discussing with IHA and showing what AA normally does, we identified
two reasons for bad looking:

(1) The grid lines are not regularly AAed since they are displayed on different
positions on the discrete raster

(2) The deactivated OLE chart looks slightly different since the MetaFile
containing the 3D bitmap is visluslized slighly zoomed.

For (1): Added support for the SnapHorVerGridLines configuration flag (same as
for 2D) to snap hor/ver grid lines to centered raster positions. Really snapping
them to single pixel lines did not look to good and showed problems with those
lines vanishing sometimes (no surprise; those lines are now forced to smaller
polygons, especially compared with the extended, AAed areas). Best looking
solution is to snap those lines in 3D to center of grid to force them to be
regularly AAed (same as our competitot does). This is also an acceptable
enhancement for all other 3D.

For (2): IHA was investigating one day to again look for the precision error
involved in usage of many system layers (chart, framework, etc...) which leads
to different display sizes bewteen activated and non-activated charts. Too
complex, had to stop now. I investigated this issue on visualisation side and
added code to primitive renderers to ignore single pixel errors (which result
from lacking precision from layers described above). This works well and leads
to unscaled MetaFile visualisation.

All in all these two changes enhance 3D visualisation greatly for charts and
should be considered a candidate for 3.1. Checking in at aw066 and building
install-sets.

AW: Task is finished, CWS builds running, auto test started.

What to test: Create a simple chart, fastest using calc and typing a block of
numbers (e.g. 3x3). Set cursor on one of them, klick on chart in the toolbar on
the top, select 3D look in the dialog and finish.

For (1): Compared with 3.0, the grid lines shall be regular, all looking the
seme independent from their Y-Position

For (2): The activated and deactivated OLE chart should look the same (different
from 3.0 where single pixel lines were missing, best seen on the grid lines of
the left wall)

AW->WG: Please verify as described.

Issue was proposed and accepted as stopper on release mailing list -> add
dependency to stopper issue and set target.

Verified in CWS.

Tested in OOO310_m8. Closed.