Created attachment 40729 [details]
Custom2.xls

Excel 2003 show the chart faster than OOo 2.1 Win xp

removed 'new chart:' from summary as the same effect can be seen already in the
regular version src680m124 or also src680m188.

->thb: Not sure whether you are the right person to fix this. During the repaint
of the metafile ugly black rectangles are shown. I assume that they are caused
by bitmap fillings which are used for shapes created in the underlying chart.

confirm

@tonygalmiche: seems that CWS aw024 improved that a lot - would you try
something >=m194, and report back if this has really been fixed?

It's OK with Chart2m10 -> Close this issue ?

@bm: please add to chart2 CWS, and set to fixed - you seem to have solved this
en passant.

Please verify in Milestone 10.

setting target and to fixed.

->tonygalmiche: Hm, I am not quite sure what this issue is really about. I still
see black filled rectangles for a short while before the actual bitmap is drawn
in Milestone 10. I am using Windows via an rdesktop. Maybe that's the reason why
I still see them, but it looks like they are still painted. Or did I
misunderstand the issue?

I think it should be reopened. I would say it is not fixed. If you don't see the
black rectangle, I assume your display is just too fast.

->thb: I don't know who does the painting of meta-files, but I definitely see
the solid black rectangle when painting the replacement image. You can also check:

1. Create a Draw OLE
2. Insert a circle with a fill bitmap
3. Copy it several times (e.g. with middle mouse button) to get 20 objects
4. Move the deactivated OLE object around
=> You see the flashes. If you don't, add more shapes.

I checked in chart2mst3 Milestone 10 which is based on m195 (including aw024).

BTW., it looks like the problem only appears inside Writer and Calc. Not in Draw
(haven't checked Impress). So maybe there is just a flag missing for rendering?

@aw:looks like Writer & Calc don't buffer the output - can you confirm  (or even
fix) that?

AW: Yes, in Draw7Impress the paint is buffered (since m194, aw034).
AW: Discussed with BM, has nothing to do with OLE but with metafiles. Can also
be produced with 'paste special/as metafile' and some graphic objects. Trying to
reproduce on my side, at BMs machine it was remote desktop.

AW->THB: Happens with bitmap and gradient fillings in SW and SC -> this is the
optimized XOR magic of OutputDevice for Bitmaps and gradients when the target is
pixel-oriented.

I confirm this problem with OOo 2.3 m213
it's very painful whith export dysplay on Linux (LTSP) or with FreeNX/Nomachine
or with Citrix or with Windows terminal server.
-> Issue Type = Deffect ?

@aw: isn't this gonna be fixed with your work on overlays in both calc and writer?

AW->THB: Not really. There is the possibility to solve it with primitives
indirectly when using a non-vcl-renderer later. When vcl renderer is used the
vcl-problem with the XOR gradient painting will show as it shows now.
But there is another chance for disappearing: In aw046, with complete
prerendering and overlay buffering, it may be gone anyways (is nominated now).
As long as it is not gone i think it should reside at the one who is closest to
the vcl XOR gradient painting code.

AW->tonygalmiche: It's not a defect at all, it's just an ugly repaint effect
from how VCL paints it's gradients (using XOR and some masking tricks). It
depends on the graphics driver of the system if this can be seen at all or not.
The 'trick' is used on all systems, but can only be seen on some as it seems.

Fixed with SRC680 m218 (indirectly with the overlay stuff from aw046). Please
verify.

.

Verify work fine with sample file on AOO 3.4.1
Close this bug.