Created attachment 44021 [details]
screenshot

Title and keyword added.

Adding kla to cc.

Created attachment 44045 [details]
screenshot old chart

Created attachment 44047 [details]
new chart screenshot with correct mime type

Created attachment 44051 [details]
screenshot new chart

Created attachment 44073 [details]
62percent zoom old/new and inplace/outplace

Created attachment 44074 [details]
100percent zoom old/new and inplace/outplace

This is not a new problem in the new chart, but already occurs for the old chart.
Look at the both screenshots I have attached.
On the left side you see the old chart on the right side the new chart.
In the top line you see the metafile replacement and on the bottom the inplace
edit mode.
For 100percent zoom all four images look the same ugly.
For 62percent zoom the metafile replacement looks significantly worse than the
edit mode.
So there seems to be a problem with the zoom factor.

Created attachment 44076 [details]
ExampleDoc

->Armin, please take over, as you have more insight in the creation of the
metafile from the 3D scene. Thanks a lot.

AW, IHA->CL: What we need is a parametrisation of GraphicExporter in UNO. ATM no
DPI can be handed over, thus the default-DPI from vcl VDev creation is used.
Please define parameters for handing over target DPIs.
Please define what parameters need to be passed over (DPI, Zoom?) and expand API
accordingly.

AW: Added myself to CC.
AW->CL: IHA will not take action, create a CWS and add tasks for it. Seems like
we need changes to GraphicExporter API and SdrOleObj::DpOaintObj. There. the
GetGraphic() will also need to pass parameters, but i do not know what xRef is
there and what APIs need to expanded there. Please use Your API knowledge to
give IHA hints about it.

retargeting

To ease the pain with this issue I made a workaround - see issue 79544.
The chart uses the last known zoomfactor and sets it to the MapMode which is
used to create the MetaFile in UnoGraphicExporter. I added according properties
to the exporter.
This workaround cannot be applied for charts in impress, because in impress the
zoomfactor of the presentation mode is the most important. So I didn't change
the behaviour for 3D charts in impress and they will still look almost always
ugly there in edit mode.

So the root cause remains:
3D scenes are rendered as bitmaps and then used in supposedly resolution
independent metafiles.

Listening to this issue

cl->iha: I'm currently completly unsure what the status of this is and what I
have do to. If I remember correctly you already added a resolution property to
the graphic exporter?

To solve this problem the applications need to ask the chart for a resolution
dependent output.
One way could be to use primitives instead of metafiles in the ole framework
communication. But that would be only possible with aw033.
To get an earlier solution either the applications need to ask for a resolution
dependent metafile or we avoid using metafiles completely and switch back to
direct rendering like we had it before OOo 2.0.
I can try to work on this together with mav, but not sure whether Impress has
special needs with its presentation view.
Christian, as this problem is worst in impress and you are an impress specialist
you maybe can help with that question: Are there specialties of ole object
display in the presentation view, or does it work like the ole display in the
edit mode for all applications?

cl->iha: I add thb to cc, he can best answer your previous question
cl->thb: to the rescue!

@iha: no, currently the slideshow relies on a metafile being provided by the
XShape. There might be hacks possible to pass along required resolution, but I'd
hate to have them, shortly before aw033. Another possibility is to handle them
like embedded plugins or videos, which I have a task for anyway (for frame
support). Personally, I wouldn't mind waiting for aw033, instead of investing in
stop-gap solutions for one minor, though...

For the slideshow I implemented a workaround within issue 84569 (ooh680m2 and
src680m243). It works for normal full screen slideshow. The complete solution
for the slideshow is targeted with issue 84570.

For printing and pdf export I implemented a mechanism that avoids the usage of
meta file replacements for charts and creates correct resolution dependent
output (see issue 82893). The solution will be available in ooh680m2 and
src680m243 (look for CWS chart15).

This implementation could also be used for direct rendering of the chart during
the edit mode of the applications: In file
svx/source/svdraw/chartprettypainter.cxx  in method 
ChartPrettyPainter::ShouldPrettyPaintChartOnThisDevice return true at the end
instead of false.
But the painting of the SdrView is much slower than the painting of an accessory
meta file. Thus for performance reasons still meta files are used.

->cl: The chart now has all done what is reasonable possible here. Now it's up
to the draw team to speed up rendering or provide a complete different working
solution (primitives...). Please consider and plan accordingly.

Target changed.

*** Issue 90498 has been marked as a duplicate of this issue. ***

Reset assigne to the default "issues@openoffice.apache.org".