Download it now!
Bug 44391 - VIEWING: Artifacts in Input Line
Summary: VIEWING: Artifacts in Input Line
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Master old -3.6
Hardware: Other All
: medium minor
Assignee: Noel Power
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-02 10:25 UTC by Rainer Bielefeld Retired
Modified: 2015-11-30 13:52 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshots (20.59 KB, application/x-download)
2012-01-02 10:25 UTC, Rainer Bielefeld Retired
Details
Sample Document (15.96 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-01-02 10:27 UTC, Rainer Bielefeld Retired
Details
Empty Cell/Input Line with Artifact (9.77 KB, image/png)
2012-01-19 11:52 UTC, famo
Details
Screencast of Input Line in LO 3.5, played at halfspeed (72.38 KB, application/download)
2012-02-01 04:29 UTC, famo
Details
Screencast of Multiline Input Line in LO 3.5, played at halfspeed (35.31 KB, application/download)
2012-02-01 04:39 UTC, famo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2012-01-02 10:25:38 UTC
Created attachment 55052 [details]
screenshots

Steps how to reproduce with Parallel Dev-Installation of  "LibreOffice 3.5.0 Beta2 - WIN7 Home Premium (64bit) English UI [Build-ID : 8589e48-760cc4d-f39cf3d-1b2857e-60db978]:

1. Open attached sample document
2. Click into A1 if necessary
3. Arrowdown to reach cell A2
   Expected:perfect view of "15" In input pane
   Actual: small artifact in open arc of the "5"

It's a general Master problem, IMHO related to multi row input line.

I did not observe the problem with a Master build from 2011-09-06 without multirow input line.

The effect is not 100% reproducible, sometimes "expected" artifact will not appear.

No problem when you reach the cells by mouseclick

Anti aliasing and hardware acceleration are without influence.
Comment 1 Rainer Bielefeld Retired 2012-01-02 10:27:40 UTC
Created attachment 55053 [details]
Sample Document

See original report!
Comment 2 Volker Merschmann 2012-01-19 11:50:29 UTC
Confirmed with 3.5RC1 on Windows XP.
Comment 3 famo 2012-01-19 11:51:55 UTC
I can reproduce this under Windows XP and LO 3.5 beta.

If you use higher numbers (100, 1000, 10000, 100000, etc.) you can see how the artifact moves along in the input line. With text there are also artifacts.

It seems like the drawing of the very first vertical line of each character in the input line is messed up. 
If you move from a not-empty cell with artifact to an empty cell, sometimes you can even see the artifact there. I made a screenshot from that.
Comment 4 famo 2012-01-19 11:52:53 UTC
Created attachment 55807 [details]
Empty Cell/Input Line with Artifact
Comment 5 Rainer Bielefeld Retired 2012-01-20 06:59:01 UTC
@Kohei:
Please feel free to reassign (or reset Assignee to default) if it’s not your area. Please set Status to ASSIGNED if you accept this Bug.
Comment 6 Kohei Yoshida 2012-01-20 07:04:02 UTC
Noel would be a more suited assignee for this.
Comment 7 Noel Power 2012-01-24 04:23:32 UTC
http://cgit.freedesktop.org/libreoffice/core/commit/?id=f00b387faeca2902909ce181f2f772a51ec4527f

might fix this, have to say I couldn't reproduce the behaviour described ( although I did see some issue with moving between blank and cells with content similar to that described in the end of comment #3 ) After the fix I couldn't reproduce the problem

would be great someone how easily reproduces this problem could be test a master build ( note: fix was committed today )
Comment 8 famo 2012-01-25 05:12:19 UTC
(In reply to comment #7)
> would be great someone how easily reproduces this problem could be test a
> master build ( note: fix was committed today )

Is there a ordinary binary/installer of the master build for Windows (XP)? If so, I would be willing to test this.
Comment 9 Noel Power 2012-01-25 05:57:42 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > would be great someone how easily reproduces this problem could be test a
> > master build ( note: fix was committed today )
> 
> Is there a ordinary binary/installer of the master build for Windows (XP)? If
> so, I would be willing to test this.

http://dev-builds.libreoffice.org/daily/

note: this fix is applied to the 3.5 branch as well and that probably is a better one to try ( in terms of general stability ) 

http://dev-builds.libreoffice.org/daily/Win-x86@6-fast/libreoffice-3-5/current/ should contain the fix ( build date is today at least )
Comment 10 famo 2012-01-30 14:12:53 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > would be great someone how easily reproduces this problem could be test a
> > > master build ( note: fix was committed today )
> 
> http://dev-builds.libreoffice.org/daily/Win-x86@6-fast/libreoffice-3-5/current/
> should contain the fix ( build date is today at least )

I checked now with 3.5 RC2 on Windows XP:

The bottom line is the artifact is gone!
However one (or at least me here) can clearly see how the (missing-) artifact is repainted after the rest of the line, theres a gap of like ~10ms(?). It looks a bit awkward, but I guess if you don't look straight at the input line you'll hardly notice this.
Comment 11 Rainer Bielefeld Retired 2012-01-30 23:33:54 UTC
Yes, that's good news, I see good progress.
I still see the problem with Parallel Dev-Installation of  "LibreOffice 3.5.0 Beta3- WIN7 Home Premium (64bit) German UI [Build-ID: e40af8c-10029e3-615e522-88673a2-727f724], 
but not with "LibreOffice 3.5.0 RC2 German UI/Locale [Build-ID: e371a95-bf68a13-5a1aa2b-d3c1ae9-b938258] on German WIN7 Home Premium (64bit). Is it really possible that the fix is in the build installer dated 25-Jan-2012 11:05?

famo's observation concerning first vertical pixel column is reproducible, when I move the cell cursor from cell with "10" to cell with "100" I see the redraw effect at the last "0" very good. For me success to reproduce is best when I swith from an other window to test sheet with <alt+tab> before I move cell cursor, I can't tell whether it has to do with my eyes or the reported effect.

So we still have a minor problem.
Comment 12 Noel Power 2012-01-31 08:13:18 UTC
(In reply to comment #11)
> Yes, that's good news, I see good progress.
that's somewhat encouraging
> I still see the problem with Parallel Dev-Installation of  "LibreOffice 3.5.0
> Beta3- WIN7 Home Premium (64bit) German UI [Build-ID:
> e40af8c-10029e3-615e522-88673a2-727f724], 
> but not with "LibreOffice 3.5.0 RC2 German UI/Locale [Build-ID:
> e371a95-bf68a13-5a1aa2b-d3c1ae9-b938258] on German WIN7 Home Premium (64bit).
> Is it really possible that the fix is in the build installer dated 25-Jan-2012
> 11:05?
the fix is in RC2 but I am not sure if the fix made the build dated 25-jan, should be in the following ones at least
> 
> famo's observation concerning first vertical pixel column is reproducible, when
> I move the cell cursor from cell with "10" to cell with "100" I see the redraw
> effect at the last "0" very good. For me success to reproduce is best when I
> swith from an other window to test sheet with <alt+tab> before I move cell
> cursor, I can't tell whether it has to do with my eyes or the reported effect.
> 
> So we still have a minor problem.

well I'd really appreciate if someone could provide a screen shot ( and a big indicator showing the present artifact ) I'm afraid I didn't really get the previous description ( probably because I fail to see it here ) also I wear nice big thick glasses so possibly I really need a big red pointer for me to notice the problem :-)
Comment 13 famo 2012-02-01 04:29:19 UTC
Created attachment 56441 [details]
Screencast of Input Line in LO 3.5, played at halfspeed

This is a screencast of the input line in LO 3.2, showing the delayed artifact. For better visibility it plays at halfspeed.
If you zoom it to full screen it should be pretty obvious (even with thick glasses ;-).
Comment 14 famo 2012-02-01 04:39:00 UTC
Created attachment 56443 [details]
Screencast of Multiline Input Line in LO 3.5, played at halfspeed

This is a screencast of the input line in multiline mode in LO 3.5, showing the delayed artifact.
Here you can even see the "standing" artifact when moving to empty cells.
Comment 15 Noel Power 2012-02-07 07:33:05 UTC
(In reply to comment #14)
> Created attachment 56443 [details]
> Screencast of Multiline Input Line in LO 3.5, played at halfspeed
> 
> This is a screencast of the input line in multiline mode in LO 3.5, showing the
> delayed artifact.
> Here you can even see the "standing" artifact when moving to empty cells.

Thanks for the screencasts, that's much clearer ( but I have to admit I expected some orphaned pixels and didn't quite expect the 'painting' nature of the bug ) Maybe it's just windows only or maybe my eyes refresh rate is so bad I can't see it ;-) but I don't see this on linux still. Anyway, I have some idea what might be causing it, probably like the last time it will be a bit of a blind fix so testing will be much appreciated, will post here when I have committed something. Thanks in advance
Comment 16 Kohei Yoshida 2012-02-23 08:46:27 UTC
The new input bar is a new feature, hence it's not a regression. Just a normal bug.
Comment 17 famo 2012-03-15 10:49:46 UTC
(In reply to comment #15)
> Thanks for the screencasts, that's much clearer ( but I have to admit I
> expected some orphaned pixels and didn't quite expect the 'painting' nature of
> the bug ) Maybe it's just windows only or maybe my eyes refresh rate is so bad
> I can't see it ;-) but I don't see this on linux still. ...
Additional thoughts:
Before your commit (comment #7) the artifact was permanent. So your patch didn't solved the initial problem, but rather triggered a second (correct) painting of the input line. Maybe reverting this patch helps in finding a solution.

Just an idea.
Comment 18 A (Andy) 2014-08-02 11:39:06 UTC
Is this still reproducible?
I can't see anything like this with LO 4.3.0.4 (Win 8) or I am doing something wrong
Comment 19 QA Administrators 2015-09-04 02:49:37 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.0.5 or later)
   https://www.libreoffice.org/download/

   If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
 
 If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 

1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug 
3. Leave a comment with your results. 

4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 
4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
Comment 20 Buovjaga 2015-11-30 13:52:17 UTC
Not seeing any artifacts of redraw weirdness. WFM.

Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+
Build ID: a7c3a2a9be83686657c06f37d521f9f6d2004ddd
Threads 4; Ver: Windows 6.1; Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2015-11-28_04:39:18
Locale: fi-FI (fi_FI)