Apache OpenOffice (AOO) Bugzilla – Issue 122149
repaint error when scrolling (under particular circumstances)
Last modified: 2017-05-20 10:34:13 UTC
Created attachment 80583 [details] File to produce the repainting problem I use AOO350m1(Build:9611) - Rev. 1424563 Rev.1425220 Open attached document and change the value B1 for example to 2. Scroll up and down by dragging the scrollbar. Notice, that there are lines remaining from the tooltip object at the scrollbar and that the chart is not correctly repainted. It has been OK in AOO 3.4.1.
Created attachment 80584 [details] Screenshot of repaint errors
i noticed a repaint problem in aoo 4 if "window - freeze" is used and rows are inserted using a macro. i cannot reproduce with aoo341 too.
Attachment works OK in Rev. 1467541 Debian.
ALG: Very strange, it only happens after doing the change, no repaint with the original opened document. After activating/deactivating the OLE chart, it again stops happening. Workaround
ALG: Workaround: Press CTRL+SHIFT+R to force a complete repaint
Created attachment 81141 [details] Confirm problem
I reported the same problem. I tested your Calc document and got the same result (look my attachment). Also, please specify your hardware and OS, and is it 32 bit or 64 bit.
(In reply to sevalav from comment #7) > I reported the same problem. https://issues.apache.org/ooo/show_bug.cgi?id=122801
(In reply to Armin Le Grand from comment #5) > ALG: Workaround: Press CTRL+SHIFT+R to force a complete repaint I tried to do this (CTRL+SHIFT+R). Yes, I got a nice, undistorted sheet, but if I want to use scroll bar after that command I will get distort sheet again.
adding an example file and screenshot - open spreadsheet "example_repaint_error.ots" - select entries from listboxes in cells c2,c4,c6,c8 -> some lines from listboxes will sty on screen - press CTRL+SHIFT+R to force a complete repaint will not happen in aoo341
Created attachment 81147 [details] screenshot
Created attachment 81148 [details] repaint error example file
(In reply to brinzing from comment #12) > Created attachment 81148 [details] > repaint error example file I confirm that problem. Brinzing, I tested your file, the same happend to me. Brnzing, what is your configuration (hardwere and OS)?
> what is your configuration (hardwere and OS)? win7 64bit
(In reply to brinzing from comment #14) > > what is your configuration (hardwere and OS)? > > win7 64bit win7 Home Premium or?
> win7 Home Premium or? professional
Brinzing, I tested your file and got next result: AutoCalculate (Tools/Cell content/AutoCalculate) is involved in this problem. When I turn off this option, I can filling cells (C2, C4, C6, C8) without any problems. Using scroll bar do not make distorted picture of sheet. But, when I turn on AutoCalculate option, active cells with formulas will be updating, and, if I using scrool bar after that, I will get distorted picture. Please, do this yourself in your computer to confirm this. 1) open your calc document 2) turn on AutoCalculate option (Tools/Cell content/AutoCalculate) 3) Make changes in cells (C2, C4, C6, C8) 4) Visualy observe are there some problems when you in filling process of cells 5) Use scroll bar and observe 6) Turn on AutoCalculate option 7) Use scroll bar again and observe
Created attachment 81176 [details] autocalc turned off
with autocalc turned *off* it's getting worser ... see attched screenshot
*** Issue 122930 has been marked as a duplicate of this issue. ***
*** Issue 122801 has been marked as a duplicate of this issue. ***
Some clarification: Currently I do not see any evidence that the root of the problem is a bug in the AutoCalculate arey. I only added that to the summary because AutoCalculate seemed to be a reliable precondition to make the problem reproducible. Kirill's Comment 24 in "Bug 122801 - Redraw causes damaged Viewing with active AutoCalculate" indicates that there also might be additional conditions what make visible the problem. Severity of this problem should not be underrated. Original report shows some smaller blemishes, but during my tests I also saw appearances of the problem making the sheet unreadable / unusable until next redraw, what might cause some panic for unexperienced users.
I do not know what exactly cause the problem. I posted only what I saw how program works. What I can see, the most frequent of this kind problems are occur in win7 64. I am not an programer. That is job for someone who have this skills to find solution. 3.4.1. have not this problems. Well, somebody must compare code of 3.4.1. and 4.0. Also, managing in AOO 4.0 with heavy picture in Draw is very slow.
I tried to use 4.0.0 CALC for normal work, but it's impossible because of this issue. Seems to work more or less for small simple sheets, but big sheets with lots of formatting, conditional formatting, formulas look horrible after only few scrolls, completely unusable. So MAJOR, and I think this one is a shownstopper for 4.0.1 I was not able to reproduce the problem with AutoCalculate = OFF, but I don't think that that observation is important.
I was wrong in my Comment 24, I AM able to reproduce the problem also with AutoCalculate = OFF, but for me the hassle is less with that setting.
This is such a severe bug, that it makes Openoffice v4 useless for Win7 users who need Calc. Could we provide additional informations, tests, etc. to the developers so that they can fix the bug?
The redraw problem also happens on Windows XP Professional (32bit) with Openoffice v4. So it looks like it's NOT Windows 7 specific.
http://wiki.openoffice.org/wiki/Showstopper
*** Issue 122929 has been marked as a duplicate of this issue. ***
*** Issue 122977 has been marked as a duplicate of this issue. ***
Drop worrying AutoCalculate hint
I have tried again and could not reproduce the problem any longer. It is difficult for me, to remember all what I have done in between. On thing has been changing dpi and font in Windows 7 desktop settings.
(In reply to Regina Henschel from comment #32) > I have tried again and could not reproduce the problem any longer. It is > difficult for me, to remember all what I have done in between. On thing has > been changing dpi and font in Windows 7 desktop settings. Please, what dpi you have now? Or fonts?
Yes, big progress with "AOO 4.0.0-Dev – English UI / German locale - [AOO400m3(Build:9702) - Rev. 1511231 2013-08-08]" on German WIN7 Home Premium (64bit)", own separate user profile: some quick tests showed that some price calculating work with my own spreadsheets, what was more or less impossible with 4.0.0 final, now works like a charm. But still a problem with Bug 122801, what might indicate that at least some of the problems there are independent from this bug here?
(In reply to sevalav from comment #33) > (In reply to Regina Henschel from comment #32) > > I have tried again and could not reproduce the problem any longer. It is > > difficult for me, to remember all what I have done in between. On thing has > > been changing dpi and font in Windows 7 desktop settings. > > Please, what dpi you have now? Or fonts? I have now 125% and font "Segoe UI".
Please, what is the path for this changes?
I have this problem with more than spreadsheet, I am a constant user of Calc, on Vista 32. It happens reliably from the moment I start scrolling the screen and is continuous. It does not affect functionality except that I can't see what's going on reliably. I have not experienced anything like this before up to OO 3.2. Is there a fix or should I revert to 3.2 for the time being?
There is no fix for this yet. I am now using AOO 3.4. because AOO 4.0 make me the same problem as yours. So, go back to your 3.2 version if you have problems.
ALG: Grepping and taking a look.
ALG: Can not always reproduce, seems some numerical stuff.
ALG: Tracked down to a numerical problem in PolyPolygon clipping. The clipping works in principle and uses 'unsharp' comparisons in the process. The result in the Region for visual clipping in the paint process then uses sharp comparisons which may lead to errors when the contained polygons still overlap (what they should not do anymore after clipping). There are various possibilities to fix this, starting from better fallback to use RegionBands if these exist for Region processing, looking where the small numerical diff is produced (in my debug example it's 8129.0000000000000 comared to 8128.9999999999991 e.g.), correcting the problem in the clip process. A combination will be necessary, starting with correcting unsharp-equal positions in the clip process in the clip results...
ALG: Corrected ClipResults by snapping same pixels. Next question is why are there Regions with PolyPolygons used at all? Seems to come into play by a call in ScGridWindow::UpdateFormulas us9ing GetChangedArea() which - without any need - works on PolyPolygon. What is new though is that it *stays* a PolyPolygon in Region since this is supported, was converted to RegionBand in older versions on pixel base what is pretty expensive...
If this is any help for you... http://www.openoffice.org/gsl/canvas/api/rendering/XCanvas.html
confirmed on WinXP 32bit
The same happens with the output picture when we close the document. See here: http://youtu.be/p8dbI_0LSGQ
In that video you can see that part of the image moves up. Perhaps that is not so important because we want to close document, but that telling us that something are not working properly in AOO 4.0
ALG: Thanks sevalav, I can now stable reproduce, thus I'm getting forward. It has to do with some reworks in the Region logic and with the fact that Calc for some reason starts to use PolyPolygons as Regions after changing that value (as part of UpdateFormulas call). PolyPolygons numerical error corrected, works in principle. Looking why still a line less is updated than in RegionBand version...
ALG: Added a point corrector to solver::getB2DPolyPolygon which uses found and remembered unsharp-equal points in the polygon and corrects these when no change was done in the original before returning these. This works in principle, but fails on setB2DPoint since this internally also checks on unsharp-equal and thus will not really correct the value. Changing this...
ALG: Working as expected. Comparing Region ranges between poly- and non-poly processing, no difference to see but the repaint still misses a line when using polygon version. Looking deeper...
ALG: After some search I found a difference: WinSalGraphics::setClipRegion itself seems to work different/do different thigs with polygons; of course setting a Polygon as clip region is different, but setting a rectangle or the corresponding polygon seems to make a difference. Forcing jumping there from one case to the other cures the problem. Need to dig into GDI/GDI+ region setting on windows...
Similar problems with Calc on XP Pro SP3 after installing 4.0.0 Not sure if all of these symptoms were noted by users, so here's my list: 1. Happens when I use mouse to scroll down 1 page using slider bar, then return to top. 2. Does not happen with PgDn-PgUp 3. On returning to top of page: random black line stubs at right edge of screen 4. Grid lines are incorrectly painted, with row gaps. 5. On one occasion, the displayed data was incorrect: several columns of times, 24-hr format, were listed incorrectly, i.e. out of sequence 6. A forced refresh e.g. going to another tab/worksheet & back fixed the error I can provide screen shots of these errors if needed.
(In reply to Tony Patriarche from comment #51) > Similar problems with Calc on XP Pro SP3 after installing 4.0.0 > Not sure if all of these symptoms were noted by users, so here's my list: > > 1. Happens when I use mouse to scroll down 1 page using slider bar, then > return to top. > 2. Does not happen with PgDn-PgUp > 3. On returning to top of page: random black line stubs at right edge of > screen > 4. Grid lines are incorrectly painted, with row gaps. > 5. On one occasion, the displayed data was incorrect: several columns of > times, 24-hr format, were listed incorrectly, i.e. out of sequence > 6. A forced refresh e.g. going to another tab/worksheet & back fixed the > error > > I can provide screen shots of these errors if needed. Great summary of behaviour Calc in Vista 32.
(In reply to Armin Le Grand from comment #50) Thanks Armin, your work is appreciated. :-)
ALG: asking for release blocker
ALG: For AOO401 it will be safest to just correct ScOutputData::GetChangedArea to Rectangle/Region usage with RegionBans, this will already hinder usages of PolyPlygon-based regions. For trunk I will do some more to make that case work, too. Going on with taking a deeper look at GDI region handling stuff...
ALG: To detect 'simple', PolyPolygons which do not need a polygon-based clip region I added and use basegfx::tools::containsOnlyHorizontalAndVerticalEdges; when true, fallback to use the RegionBand stuff. Also added test code to scale the polygon-based region by 1 in X and Y, also works as expected. Thus: - Avoid using polygon-based regions in SC - Corrected some clipping and snap of unsharp-equal points - Detect 'simple' polygons and fallback to RegionBand - Correct polygon-based clip region setting by scaling it as needed for target system All this steps make the non-polygon and the polygon-based Regions work identical; only the first change already fixes the task and thus only that one will be targeted to AOO401, the rest goes to trunk.
approve showstopper request
ALG: Added some comments, removed conditional test stuff, re-checked, preparing commits. BTW: This shows one more reason why it is necessary to drive forward the changes to primitives; when the whole Calc app would use this these repaint stuff would be simpler, faster and more uniform to handle...
ALG: Got branches/AOO401, built, checked, applied fix in SC, built re-checked that it is fixed, comitted, done for AOO401. Comitted full stuff for trunk, done.
"alg" committed SVN revision 1513538 into branches/AOO401: i122149 Do use RegionBand Regions in Calc after recalculation
"alg" committed SVN revision 1513541 into trunk: i122149 Corrected stuff around polygon-based clip regions, do not use them wh...
Armin Le Grand, big thanks to you in the name of all user! Your corrections works great. I am using now Rev. 1514218 and finally, I can use AOo 4.0... BTW is there some limitations of these corrections, or you fix everything in that area? Again, thanks!
(In reply to sevalav from comment #62) > Armin Le Grand, big thanks to you in the name of all user! +1
(In reply to Edwin Sharp from comment #63) > (In reply to sevalav from comment #62) > > Armin Le Grand, big thanks to you in the name of all user! > > +2
But it still happens something with the output picture after we pressed button for closing the document. (See comment 45 and 46.)
*** Issue 123104 has been marked as a duplicate of this issue. ***
ALG: @sevalav: That short change probably happens because the toolbars get closed first, thus the document content gets scrolled, but there will be no more repaint (due to the document closing). Besides this being a little ugly, do you see a problem with it?
> Besides this being a little > ugly, do you see a problem with it? Yes, it is only a little ugly. But also, it gives impression that something is wrong with this program. That is all.
Good work on everyone's part to resolve the issue! How do I apply those fixes to my machine. I am just a user. None of that made a bit of sense to me. Thanks
It's verified fixed in build AOO401m1(Build:9710) - Rev. 1516414
*** Issue 122962 has been marked as a duplicate of this issue. ***
*** Issue 123265 has been marked as a duplicate of this issue. ***
OS = ALL due to DUP Bug 123265 (Mac)
I am going round in circles trying to get some help with a problem I logged and was assigned 123265. I find the help system or bug system very difficult to understand. Very simply put I have a problem which I am told should be resolved by version 4.0.1. I was asked to comment if this release fixed my problem on my mac as it apparently worked for windows environments. Problem is version 4.0.1 has not been released, so I ask for link to this release. Eventually I get a link but it is not obvious what link I should select. Could somebody in plain English answer the following: I am not technical so would appreciate help in which download to select. English UK Mac OS intel seems an obvious choice for me. But then I am given four options which are meaningless to me. 1. Snapshot - I tried this and it was not found on the server so I am not sure which I should click as I do not know what options 2 -4 mean. Is it 2. ASC or 3. MD5 or 4. SHA256
If it is urgent, here is Development Snapshot page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds Find colunmn "MacOS Intel" and row "English United Kingdom (en-GB)". Click on SNAPSHOTS.
Repaint error is still here. Look video here: https://docs.google.com/uc?export=download&id=0B_xv-Bc9VISwcksyaFVWS2hDakU
(In reply to sevalav from comment #76) > Repaint error is still here. Look video here: > https://docs.google.com/uc?export=download&id=0B_xv-Bc9VISwcksyaFVWS2hDakU I sorry, I posted on wrong bug address.
@Jeff: Like real life creation of an office suite IS complex, and sometimes a normal user has to wait until official version has been published. It whould be great if you could test with 4.0.1 final when it will be available.
*** Issue 123319 has been marked as a duplicate of this issue. ***
*** Issue 123322 has been marked as a duplicate of this issue. ***
*** Issue 123335 has been marked as a duplicate of this issue. ***
*** Issue 123343 has been marked as a duplicate of this issue. ***