Apache OpenOffice (AOO) Bugzilla – Issue 99662
3D charts look ugly with antialiasing on
Last modified: 2013-02-24 21:19:13 UTC
This is a follow up issue of issue 98289 which was not fixed completely. Create a 3D column chart and look at it (edit mode and metafile replacement). The contours of the columns and the grid lines look blurry. Switch of anti-aliasing and those hoizontal and vertical lines do display clear.
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.