Issue 86163

Created attachment 51552 [details]
The line between the rectangle should be dashed (resolution 200%)

There is actual no version for 2.4rc1, so I set m241 instead.

I had a look at this. When changing the linestyle using linestyle dropdown box
in the line and filling toolbar the problem is reproducible. But executing a
repaint (CTRL-SHIFT-R) shows the line with the desired changing. I think there
is just the repaint missing. Doing the line style change using the context
menu/line/line properties works for me.

Reassinged. Seems to be a showstopper.

AW: Maybe just the old numerical problem with exactly horizontal/vertical lines.
In that case, the boundng rect may get a height/width of zero which does not
really a repaint in VCL. I will check tomorrow if this is the case when i have a
office on hand (to check: do the same with a diagonal line -> does it happen, too?)
When only a repaint is missing its of course bad, but neither load/save nor
exports or printing will be involved. It may even not happen depending on the
screen resolution and zooming. HTH ATM, will look tomorrow...

AW: Checked in a SRC680 m245 (pretty new, but the main line) and ut does not
happen there. Will take a look at whatever is 2.4rc1, will check...

AW: Tried with a OOH 680 m7 wntmsci10.pro but could not reproduce. It looks
linux-specific, so maybe the VCL guys need to take a look. I will install a
linux version on v60x-so16 now.

AW->WG: Tried on OOH 680 m7 unxlngi6.pro now, could not reproduce. I switched to
200% zoom, too. What am i doing wrong ?!? Please describe detailed how You
reproduce this. Maybe i take the wrong versions or OSes?

I tried it on my virtual linux (Suse) machine using vnc. Take a fresh start of
the Office and open a new draw. Take the line tool from the drawing toolbar and
draw a line. Keep it selected and use the linestyle drop down box from the line
and filling toolbar to change to another style: nothing happens in the document.
A refresh helps to show the change.
With a FedoraCore version I cannot reproduce this problem.

Reassigned.

AW: Okay, installing a SUSE 10.3 on a new virtual mashine...

AW->PL: I need Your help. I have installed a VirtualMachine with SUSE 10.3, but
i cannot get a OOH680 m7 running on it. When You follow the descriptions, it
seems like the Invalidate() call in VCL does different things under different
Linuxes, e.g. i tested on the v60x-so16 where it works (also works on windows)
whereby WG says that it goes wrong on SUSE linux. Is this possible? Could You
have a look on a SUSE version? Can You reproduce it at all? Does it happen with
SRC680 m246, too?

Feel free to send back to me if You have some more informaton, i just need
someone with more Linux knowledge.

are you using SunRay to display your virtual machine ? On a 1600x1200 display ?
These show line artifacts sometimes (see issue 85943), native and on virtual
machines running e.g. windows. However that is a Sunray problem AFAIK.

As for invalidate: there is no platform specific thing that is done in vcl.

pl->aw: Even without any sunray involved, isn't your first assumption most
likely correct that it is a rounding problem ? These things are ultimately
dependent on the DPI settings of the environment since painting is done on pixel
basis (what else), so rounding errors differing from system to system are IMHO
the best guess without a method of reproducing this (I tried and failed also).

Seems to be ok on the same machine with a version 2.3.1, so this is a
regression, confirmed.

set keywords

Summary and findings so far:
============================
It happens on a virtual machine displayed on SunRay with SUSE (10.3?) running
with a vertical line in a Draw frame which is set to 200% zoom on a unxlngi6.pro
OOH 680 m7 when changing the line style from the (default) continuous to
something dashed.

It was seen on a machine at andreasma (who filed the bug) and WG (who can
reproduce it).
PL could not reproduce it.
We could not reproduce it on
   - windows or
   - on v60x-so16 or
   - on two virtual machines with Ubuntu 7.4 and SUSE 10.3 using VirtualBox
running on a windows machine.
WG told that it does not happen on a OOG m9. Nothing was changed in the
DrawingLayer between OOG m9 and OOH m7.

PL thinks it's not a paint problem at all but a status update/timing problem and
suggests that CL knows that area best.
CL thinks the status update may take some time but it's still a missing repaint.
AW thinks that the invalidation is system-independent based on model data on
DrawingLayer side (not on VCL) and there is no reason the repaint should not happen.

Open questions for clarification:
(a) WG: Can You always reproduce it or only sometimes?
(b) WG: Does the visulaisation change also miss when You change the line color,
not the Line style?
(c) WG: Does the visulaisation change also miss when You move the line and then
back using UNDO without changing the zoom?
(d) CL: What changes were introduced to SD between OOG m9 and OOH m7?
(e) PL: What changes were introduced to VCL between OOG m9 and OOH m7?
(f) WG: To which LineStyle exactly do You change?

To decide between missing repaint and missing status update, please use the
answers from (b) and (c). The invalidate and thus the repaint is the same as
with changing the dashing. If one or both are 'no', the repaint works.

Question (f) is for excluding another possibility which came to mind. If the
dashing is very small and the graphic subsystem of the virtual machine for any
reason paints the last pixel of a rasterconverted line (which is against the
convention, but may happen) it maybe that the continued row of short lines is
just visualised as 'one' line on those systems. This may also be checked by
zooming in.

Facts:
- It's the visualisation (which a repaint shows), so neither the model data nor
copy/pasted data nor saved data is in any way corrupted.
- Visualisation can be corrected by zooming, changing page, repainting, etc.
- It's only on virtual machines and rarely reproducable 

Suggestion: Remove from list of showstoppers, but still treat as a bug and fix
it ASAP.

removing from release blocker list.

as agreed in release status meeting 2008-02-25 set target to 3.0

I can confirm it with OOH_m8 (2.4 RC2)

add mh to inform him

I tried it today on two other machines. First I could reproduce the defect on a
machine with OpenSuSE 10.2-64bit, KDE 3.5.8 Release 33.2 and a
Nvidia-Graphiccard (5400 chip). There I could reproduce it also inside the
writer with lines from the toolbar drawing. Curious: I could see a different
line style in the page section on the left side in draw (but not on the working
place in the middle).
On another box with OpenSuSE 10.3-i586 and KDE 3.5.8 Release 25 and also a
Nvidia-Card from the same type, I could see different line styles. I hope that
helps a bit to solve this issue.

Seen on another opensuse10.2. Random data points: happens with all vcl plugins.
Happens as well with overlay/paintbuffer turned off. Forced repaint does _not_
help. Page preview sometimes shows correct content, sometimes not.

Document content appears to be ok. Locally-built ooo-build based on m8 does
_not_ show the issue. Especially the fact that ctrl-shift-R did not help
troubles me...

Today I had the opportunity to test with 2.4rc6 on a freshly installed openSuSE
10.2 (inside a VM) on a 10.3-host (with nvidia graphic card; on the host worked
2.4rc2 for this part fine). I get the problem with dashed lines. They are not
visible (in no part of the working place).. I get the same, if I use the toolbar
drawing and paint a line in writer (and change the line style). Nothing visible
of my changes. 

A repaint with ctrl + shift + R doesn't works for me. There are no changes in 
the GUI.

Created attachment 52352 [details]
One likely cause of this issue

valgrind found a _very_ fishy missing initialization in line style code - we
should definitely take this for 2.4.1

AW->THB: So, does this FIX the problem, then? It does not happen with
primitives, so the current fix is to get them in from my point of view...

@aw: well, not for the 2.4 code line, I'd say.

AW->THB: Again: Does Your fix solve the problem? I know that primitives will not
solve the problem for 2.4.x codeline. You gave NO hint with Your fix if it does
just cure 'a _very_ fishy missing initialization' or solve the issue. Please
answer that question. Thanks!

FWIW thb's attachment is a dup of #i85553#

@aw: cannot reliably reproduce this bug here. Andreasma, did your build succeed,
can you verify that this fixes your issue?

@cmc: thx for the link. But I think we should really fix this for the 2.4 code
line as well...

I tested with ooobuild and the fix of thb and it works on my both machines with
openSuSE 10.2 (i586 with ATI mobility 9700; 64bit with nvidia 5200). The line
changes are visible.
As I explained before the version 2.4 final don't work on that machines. There
are no line changes visible. I tested this again today. Please provide a
OOo-dev-version with this fix. I'm willing to test this on my machines.

AW->andreasma: Thanks for testing this!
AW->THB: Thanks for finding this!
AW->valgrind: Thanks for being available!

So, if this fixes the issue, we have to look for the 2.4 codeline. I am still
wondering how this could start to happen between OOG m9 and OOH m7. Did someone
change that initialisation? I remember the bool exsiting for quite some time...

AW->CL: Added You to CC; we have a fix for this now. How are the plans for the
2.4 line?

Any progress on this? We have an obvious issue, a trivial fix, and a looming
deadline...

AW->THB: Got no response from CL yet, repeating...
AW->CL: AGAIN: We have a fix for this now. How are the plans for the 2.4 line ...?

got approval by cgu, reassign to rt for masterfix

Patch applied as masterfix for OOH680 m16.
Do we need it on DEV300 code line, too?

@rt: nope, it's already fixed there.

AW->THB: nope, it never HAPPENED in DEV300, it never needed to be fixed. All in
all it was a merge error on both codelines. In aw053, i removed that bool
completely. in DEV300 the merge brought the initialized bool back, used in one
decision, but always false and cannot be changed. In 2.4 codeline a similar
wrong merge happened, but the initialisation to false was not added by the
merge. Maybe git would have been better with this ...

found fixed in OOH680_m16 -> closed