To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=99662
------- Additional comments from a...@openoffice.org Mon Mar 16 17:02:20 +0000 2009 ------- 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. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
