Download it now!
Bug 36391 - VIEWING Redraw problems
Summary: VIEWING Redraw problems
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.3.2 release
Hardware: x86 (IA32) Windows (All)
: medium trivial
Assignee: Winfried Donkers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-19 05:23 UTC by sasha.libreoffice
Modified: 2012-04-12 01:35 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot of Calc UI problem (red rectangle, that remains unpainted) (19.85 KB, image/jpeg)
2011-04-19 05:23 UTC, sasha.libreoffice
Details
repaint problem, screenshot, see rows 81/82 (114.96 KB, image/gif)
2011-12-21 23:22 UTC, Winfried Donkers
Details
paint of merged cells is distorted (18.86 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-12-22 01:26 UTC, Winfried Donkers
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sasha.libreoffice 2011-04-19 05:23:53 UTC
Created attachment 45811 [details]
screenshot of Calc UI problem (red rectangle, that remains unpainted)

in Calc on windows, toolbar item "Name box" is incorrectly painted. It painted not fully and around in remains some unpainted arrea.

To reproduce this start Calc, then minimize and maximize it. On top left field, containging A1, remains some background from window behind it.

In attachment is screenshot. I have placed red rectangle on screen and then maximized Calc. Around field with A1 appears red rectangle.

Produced on Windows XP with LibreOffice 3.3.2
Comment 1 Kohei Yoshida 2011-04-19 08:06:42 UTC
There is a general repainting issue that I've been observing, though I'm not sure if this is limited to Calc, or applicable to all apps.

Do you see this only in Calc, or in Writer, Impress, Draw etc as well?
Comment 2 sasha.libreoffice 2011-04-19 23:35:22 UTC
I can find this problem only in Calc and only on Windows
Comment 3 Rainer Bielefeld Retired 2011-09-28 23:36:48 UTC
NOT reproducible with "LibreOffice 3.4.3 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]", LibreOffice Portable 3.3.3  - WIN7  Home Premium (64bit) German UI [OOO330m19 (Build:301  Tag 3.3.3.1)]" pr any other of my LibO versions.

My PC:
64 bit AMD Phenom II X4 955 Processor 3.2 GHz, 4GB RAM, 
Graphic Card: NVIDIA GeForce GT 430

@sasha:
Still a problem with the current versions? Any idea whether a setting or anything else might cause the problem?
Comment 4 sasha.libreoffice 2011-09-29 03:03:06 UTC
Indeed, it is not reproducible. I can reproduce it only in one computer-room and only under Guest. It my be because of corrupted Windows. 
I think this bug my closed as invalid because not reproducible.
Comment 5 Rainer Bielefeld Retired 2011-09-29 03:57:46 UTC
Closing due to comment before.
Please feel free to reopen this Bug if you find evidence that we have an independent issue here.
Comment 6 Winfried Donkers 2011-12-21 23:20:25 UTC
Paint problem occurs with us as well (see attachment of screenshot).
I have also had report of paint-problem with writer (no screen shot available_, which occurred while copy-pasting; the text to be overwritten was only partially removed. Scrolling up/down caused the screen to be properly repainted again).
I think/fear this is a general repainting issue, which is difficult to reproduce.
version: 3.4.3, O/S Windows XP

I cannot confirm that is does not occur with Linux, as it did occur a lot in the past (with OOo) and I got so used to it, that I ignored the phenomenom. Should I observe it, I will mention it.
Comment 7 Winfried Donkers 2011-12-21 23:22:32 UTC
Created attachment 54665 [details]
repaint problem, screenshot, see rows 81/82

see my comment of today
Comment 8 Rainer Bielefeld Retired 2011-12-21 23:51:52 UTC
@Winfried Donkers
Your test 3.4.3 is outdated, please do not reopen reports without check whether your problem still exists in current stable version. What are your results with 3.4.4?

I can't see any relation of your problem (document contents repaint problem) with original report problem (UI element without frame). May be you should file a separate bug for this! The WRITER problem you mention is known, I am sure that we have a report for that, but I can not find it. Can you help

Please
- attach a sample document
- contribute a step by step instruction how to reproduce the problem
- describe what your problem is, your screenshot shows many artifacts. "Top
  of second line text in A64 cropped"?
Comment 9 Winfried Donkers 2011-12-22 00:43:26 UTC
(In reply to comment #8)
@Rainer
> Your test 3.4.3 is outdated, please do not reopen reports without check whether
> your problem still exists in current stable version. What are your results with
> 3.4.4?
I have asked the user who reported the issue (we're a company) to update to 3.4.4 and send me a new screen dump.
> I can't see any relation of your problem (document contents repaint problem)
> with original report problem (UI element without frame).  May be you should file
> a separate bug for this!
My reopening was triggered by your comment#5; as I had noticed this behaviour in multiple instances (but was not yet familiar with bug reporting) I suspect it be be a general issue, as mentioned in comment#1.
I'm quite happy to file a new bug, I was just trying to avoid duplicates ;)

> Can you help Please
> - attach a sample document
> - contribute a step by step instruction how to reproduce the problem
> - describe what your problem is, your screenshot shows many artifacts. "Top
>   of second line text in A64 cropped"?
I will help as much as I can (including picking up easyhacks), no problem.
I have already asked if the user that reported to me can reproduce the problem and provide me with the calc-document.
About the attached screenshot: I probably was not clear with my reference in the attachment title, but the problem can be seen in row 81/82, where the merged cells have their text. The text is 'cropped', and this was solved by zooming up/down (or vice versa).

I will provide additional information when I receive it and file this as a new bug when you prefer this.
Comment 10 Winfried Donkers 2011-12-22 01:26:37 UTC
Created attachment 54672 [details]
paint of merged cells is distorted

open file, scroll to row 125/126 or 80/81 and look at the text in cols A, G, H, L.
zoom/unzoom produces a correct repaint.
the problem seems not to be related to one zoom percentage (it can occur at 90% and also at 100%)
the problem can be reproduced with 3.4.3 and 3.4.4 (Windows) and on master (Linux build).
INFO COMPLETE
Comment 11 Winfried Donkers 2011-12-22 03:12:18 UTC
I found a way to reproduce the problem with a new calc document:
-fill cell c3 with 'abc'
-fill cell c4 with 'def'
-select both cells and merge them (choose to add the contents of c4 to the merged cell)
- the merged cell contains distorted text (some times compressed vertically, sometimes italic, sometimes clipped, sometimes different font size)
- scrolling up/down causes a proper repaint

Done on 3.4.4 (Windows) and on master (Linux. It was easier to reproduce with Windows than it was with Linux.
Comment 12 sasha.libreoffice 2011-12-22 06:28:12 UTC
I reproduced steps from comment 11 on Fedora 64 bit LOdev 3.5.0 (build 13 December)
Cell becomes corrupted just after merging. After scrolling all renders correct.
In version 3.3.4 was the same. Therefore it is not regression.
Comment 13 Winfried Donkers 2011-12-24 01:26:42 UTC
see comments 9 to 12
Comment 14 Winfried Donkers 2012-04-12 01:24:19 UTC
Cannot reproduce the problem with version 3.5.2 (Windows XP), nor on master (openSUSE 11.4)
Comment 15 sasha.libreoffice 2012-04-12 01:35:38 UTC
Thanks for additional testing
I also can not reproduce this bug in 3.5.2 on Fedora 64 bit
Changing status to WorksForMe