Community
Participate
Working Groups
Created attachment 214082 [details] Redraw issue Consecutively selecting the same tree items in different views / editors (JFace TreeViewer) cause major repaint issues (see the attached correct / incorrect screenshot of Eclipse for Testers Juno M6). This issue is reliably reproducible using the before mentioned version of Eclipse for Testers: 1. Start EfT - connect to database - load random project from db 2. Select an item from the "Test Suite Browser" 3. Select an item from the "Test Case Browser" 4. Select the same item previously selected from the "Test Suite Browser" --> redraw issue occurs in this view / viewer 5. Select the same item previously selected from the "Test Case Browser" --> redraw issue occurs in this view / viewer
Created attachment 214083 [details] Correct view display (e.g. after minimizing and restoring the window)
Markus, does 3.8 have the same problem? Bogdan, I'm familiar with some linux tree redraw issues. Do you know if we've been seeing any on windows? PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
I can consistently reproduce this issue in the default generated EMF editors. This editor has multiple tabs, that seems to be a pre-condition. For single tab editors the tree updates fine.
*** Bug 526694 has been marked as a duplicate of this bug. ***
(In reply to Rolf Theunissen from comment #5) > *** Bug 526694 has been marked as a duplicate of this bug. *** Bug 526694 comment 3, Bug 526694 comment 7, give some clues where to search for the root cause.
I think that this a SWT issue with the Tree widget. The bug occurs when: 1. Multi-selection is enabled 2. A drag-listener is attached to the tree 3. A custom rendered is used (that paints the parent) 4. The tree doesn't have focus 5. Either a current selected element is clicked or CTRL-click is used w.r.t. the custom renderer, the Eclipse E4 CSS engine is acting like the custom renderer. Therefore, the issue is only seen in Eclipse with CSS enabled. When above conditions are true, Tree#WM_LBUTTONDOWN line 6950 is executed. The comment describes what is going wrong: /* * Feature in Windows. When the tree is not drawing focus * and the user selects a tree item while the CONTROL key * is down, the tree window proc sends WM_UPDATEUISTATE * to the top level window, causing controls within the shell * to redraw. When drag detect is enabled, the tree window * proc runs a modal loop that allows WM_PAINT messages to be * delivered during WM_LBUTTONDOWN. When WM_SETREDRAW is used * to disable drawing for the tree and a WM_PAINT happens for * a parent of the tree (or a sibling that overlaps), the parent * will draw on top of the tree. If WM_SETREDRAW is turned back * on without redrawing the entire tree, pixel corruption occurs. * This case only seems to happen when the tree has been given * focus from WM_MOUSEACTIVATE of the shell. The fix is to * force the WM_UPDATEUISTATE to be sent before disabling * the drawing. * * NOTE: Any redraw of a parent (or sibling) will be dispatched * during the modal drag detect loop. This code only fixes the * case where the tree causes a redraw from WM_UPDATEUISTATE. * In SWT, the InvalidateRect() that caused the pixel corruption * is found in Composite.WM_UPDATEUISTATE(). */ So the current code has only a workaround for WM_UPDATEUISTATE. In case of the CSS theme engine, the parent is also redraw. But no workaround is applied. When WM_SETREDRAW is not disabled, the issue disappears. Also, when invalidating the whole tree (after redraw is enabled again in line 6703) the issue resolves, although in this case the UI flickers. A robust solution is to not call 'callWindowProc (handle, OS.WM_LBUTTONDOWN, wParam, lParam)' while redraw is disabled. Could be done by moving this call forward or the redraw code later, though I have no clue what could be side effects of that.
*** Bug 436114 has been marked as a duplicate of this bug. ***
*** Bug 458015 has been marked as a duplicate of this bug. ***
*** Bug 571312 has been marked as a duplicate of this bug. ***
*** Bug 574653 has been marked as a duplicate of this bug. ***
*** Bug 385121 has been marked as a duplicate of this bug. ***
*** Bug 578622 has been marked as a duplicate of this bug. ***
