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.
Created attachment 55053 [details] Sample Document See original report!
Confirmed with 3.5RC1 on Windows XP.
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.
Created attachment 55807 [details] Empty Cell/Input Line with Artifact
@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.
Noel would be a more suited assignee for this.
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 )
(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.
(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 )
(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.
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.
(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 :-)
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 ;-).
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.
(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
The new input bar is a new feature, hence it's not a regression. Just a normal bug.
(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.
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
** 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
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)