Issue 86163 - Regression: Broken line not visible in 2.4-rc1
Summary: Regression: Broken line not visible in 2.4-rc1
Alias: None
Product: Draw
Classification: Application
Component: viewing (show other issues)
Version: OOH680m7
Hardware: All Linux, all
: P2 Trivial (vote)
Target Milestone: OOo 2.4.1
Assignee: rt
QA Contact: issues@graphics
Keywords: oooqa, regression
Depends on:
Blocks: 86505 88258
  Show dependency tree
Reported: 2008-02-17 21:04 UTC by maand
Modified: 2008-05-27 17:33 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

The line between the rectangle should be dashed (resolution 200%) (18.49 KB, image/png)
2008-02-17 21:10 UTC, maand
no flags Details
One likely cause of this issue (331 bytes, patch)
2008-03-28 20:21 UTC, thb
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description maand 2008-02-17 21:04:41 UTC
I used OOo 2.4-rc1-Draw (official rpm) on openSuSE 10.2-i586, KDE 3.5.8 to
create a graphic. I wanted to change some lines inside the graphic to dashed
stile. I couldn't see any changes (not via contextmenu nor via toolbar).
I saved the odg-file and reopened it on the same machine and environment with
OOo 2.3.1 and now the dashed lines appeared. Therefore it is for me a regression
and it makes Draw not usable.
I found this problem also for the connectors. There is also no change to another
line stile visible (in 2.4-rc1, but in 2.3.1).
Comment 1 maand 2008-02-17 21:10:31 UTC
Created attachment 51552 [details]
The line between the rectangle should be dashed (resolution 200%)
Comment 2 maand 2008-02-17 21:15:37 UTC
There is actual no version for 2.4rc1, so I set m241 instead.
Comment 3 wolframgarten 2008-02-18 09:12:30 UTC
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.
Comment 4 wolframgarten 2008-02-18 11:10:33 UTC
Reassinged. Seems to be a showstopper.
Comment 5 Armin Le Grand 2008-02-18 12:16:52 UTC
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...
Comment 6 Armin Le Grand 2008-02-19 10:02:30 UTC
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...
Comment 7 Armin Le Grand 2008-02-19 10:17:05 UTC
AW: Tried with a OOH 680 m7 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.
Comment 8 Armin Le Grand 2008-02-19 10:26:54 UTC
AW->WG: Tried on OOH 680 m7 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?
Comment 9 wolframgarten 2008-02-19 11:16:20 UTC
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.
Comment 10 wolframgarten 2008-02-19 11:16:53 UTC
Comment 11 Armin Le Grand 2008-02-21 01:59:18 UTC
AW: Okay, installing a SUSE 10.3 on a new virtual mashine...
Comment 12 Armin Le Grand 2008-02-21 03:44:15 UTC
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.
Comment 13 philipp.lohmann 2008-02-21 09:31:27 UTC
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.
Comment 14 philipp.lohmann 2008-02-21 09:53:01 UTC
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).
Comment 15 wolframgarten 2008-02-21 11:23:16 UTC
Seems to be ok on the same machine with a version 2.3.1, so this is a
regression, confirmed.
Comment 16 Mechtilde 2008-02-21 20:51:37 UTC
set keywords
Comment 17 ooo 2008-02-22 10:01:34 UTC
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
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.

- 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.
Comment 18 Martin Hollmichel 2008-02-22 12:16:18 UTC
removing from release blocker list.
Comment 19 Martin Hollmichel 2008-02-29 13:19:58 UTC
as agreed in release status meeting 2008-02-25 set target to 3.0
Comment 20 Mechtilde 2008-03-01 19:58:53 UTC
I can confirm it with OOH_m8 (2.4 RC2)

add mh to inform him
Comment 21 maand 2008-03-02 19:31:06 UTC
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.
Comment 22 thb 2008-03-14 22:27:49 UTC
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...
Comment 23 maand 2008-03-25 21:31:14 UTC
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. 
Comment 24 maand 2008-03-26 14:51:30 UTC
A repaint with ctrl + shift + R doesn't works for me. There are no changes in 
the GUI.
Comment 25 thb 2008-03-28 20:21:23 UTC
Created attachment 52352 [details]
One likely cause of this issue
Comment 26 thb 2008-03-28 20:22:43 UTC
valgrind found a _very_ fishy missing initialization in line style code - we
should definitely take this for 2.4.1
Comment 27 Armin Le Grand 2008-03-31 04:04:26 UTC
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...
Comment 28 thb 2008-03-31 10:15:01 UTC
@aw: well, not for the 2.4 code line, I'd say.
Comment 29 Armin Le Grand 2008-03-31 10:19:23 UTC
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!
Comment 30 caolanm 2008-03-31 11:22:13 UTC
FWIW thb's attachment is a dup of #i85553#
Comment 31 thb 2008-04-01 10:51:56 UTC
@aw: cannot reliably reproduce this bug here. Andreasma, did your build succeed,
can you verify that this fixes your issue?
Comment 32 thb 2008-04-01 10:53:23 UTC
@cmc: thx for the link. But I think we should really fix this for the 2.4 code
line as well...
Comment 33 maand 2008-04-01 22:04:03 UTC
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.
Comment 34 Armin Le Grand 2008-04-02 03:26:57 UTC
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?
Comment 35 thb 2008-05-16 09:43:16 UTC
Any progress on this? We have an obvious issue, a trivial fix, and a looming
Comment 36 Armin Le Grand 2008-05-16 11:48:55 UTC
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 ...?
Comment 37 Martin Hollmichel 2008-05-23 09:13:40 UTC
got approval by cgu, reassign to rt for masterfix
Comment 38 rt 2008-05-23 09:28:45 UTC
Patch applied as masterfix for OOH680 m16.
Do we need it on DEV300 code line, too?
Comment 39 thb 2008-05-23 09:46:06 UTC
@rt: nope, it's already fixed there.
Comment 40 Armin Le Grand 2008-05-27 11:20:39 UTC
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 ...
Comment 41 andreschnabel 2008-05-27 17:33:56 UTC
found fixed in OOH680_m16 -> closed