Bugzilla – Full Text Bug Listing
Created attachment 284879 [details]
Wrong displaying when displaying annotation.
I have the same issue after update to Big Sur (In reply to Jeeeyul Lee from comment #0) @Jeeeyl, thanks for the steps and investigation, I'm able to reproduce the problem. > > However, After digging about this, > I realized that NSView.lockFocus() in Control#update() is related with this > problem. lockFocus() / unlockFocus() are deprecated. And it seems that We > can't avoid Automatic Differed Painting(ADP) mechanism anymore. Even we > called lockFocus() / draw() / unlockFocus() manually, AppKit seems to draw > once again for ADP. > > Currently Control#update(boolean) checks availability of NSGraphicsContext. > If it's not available then it try to lock focus to draw, and check graphics > context again. This seems to be an indirect or direct cause. > > When I removed this checking code, everything works fine again. I don't know > these checking is still needed or not. > > What if some one can give me explanation about this, than I will make Gerrit > for this. https://bugs.eclipse.org/bugs/show_bug.cgi?id=540357#c7 has some discussion on this issue. Bug 547399 fixed the NPEs caused by null NSGraphicsContext, but it caused Cheese in the editor when scrolling horizontally - Bug 548491. Please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=548491#c8 for the explanation of the fix, that added lockFocusIfCanDraw in update(boolean). (In reply to Lakshmi P Shanmugam from comment #3) > https://bugs.eclipse.org/bugs/show_bug.cgi?id=540357#c7 has some discussion > on this issue. > Bug 547399 fixed the NPEs caused by null NSGraphicsContext, but it caused > Cheese in the editor when scrolling horizontally - Bug 548491. Please see > https://bugs.eclipse.org/bugs/show_bug.cgi?id=548491#c8 for the explanation > of the fix, that added lockFocusIfCanDraw in update(boolean). @Lakshmi Thanks for the explanation. I could not reproduce the cheese problem on JavaEditor anymore at least on BigSur. As commented in https://bugs.eclipse.org/bugs/show_bug.cgi?id=548491#c8 by Till Brychcy, IMHO, I think that the entire implementation of the update() is pointless at this point. Bigsur seems to force the use of the ADP mechanism. Currently, Control update() causes that: 1. What if there is dirty region, Painting on NSView's buffer occurs synchronously against of the dirty region. 2. Painting occurred once again aginst of the full area the control just before displaying on screen It makes all the GEF editors very slow. Below code just works fine and fast for me: boolean update (boolean all) { if (OS.isBigSurOrLater()) { return true; } ... New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/172929 (In reply to Jeeeyul Lee from comment #4) > > Below code just works fine and fast for me: > > boolean update (boolean all) { > if (OS.isBigSurOrLater()) { > return true; > } > ... @Jeeeyul, I've created a patch with this change (set you as the author) and tested it out. It fixes the problem in the child eclipse and doesn't cause the cheese issue. But, we need to make sure that this works fine with the base Eclipse. The difference being, Eclipse launcher is built with macOS SDK 10.12 and the new behaviour was initially only for Applications linked with 10.14 and later. Since we see this on base Eclipse in BigSur, seems like this has changed. Let's try this in the Eclipse build and see if works as expected. I think Bug 568964 is similar and may benefit from this fix. I can't reproduce that problem consistently so cannot verify it. As a side note, will open a separate bug to build Eclipse launcher with newer SDK for 4.19. @Sarika, This patch addresses the serious performance issue in the editor while typing. Bug 568964 also looks related. This patch only affects BigSur. Please see comment#6 for details. Patch looks localized and important for BigSur. +1 for RC2. Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/172929 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=3245fca267f65c8e358efdbdf597d388013ecea8 This seems to have fixed Bug 568964 Thank-you for the fix. (In reply to Phil Beauvoir from comment #10) > This seems to have fixed Bug 568964 > > Thank-you for the fix. Thanks for testing Phil. Request you to use the latest build [1] for a couple of days and report if you see any drawing/repaint related issues. [1] https://download.eclipse.org/eclipse/downloads/drops4/I20201127-1010/download.php?dropFile=eclipse-SDK-I20201127-1010-macosx-cocoa-x86_64.dmg @Jeeeyul, thanks for the fix. Request you to use the latest build [1] for a couple of days and report if you see any drawing/repaint related issues. [1] https://download.eclipse.org/eclipse/downloads/drops4/I20201127-1010/download.php?dropFile=eclipse-SDK-I20201127-1010-macosx-cocoa-x86_64.dmg (In reply to Lakshmi P Shanmugam from comment #11) > (In reply to Phil Beauvoir from comment #10) > > This seems to have fixed Bug 568964 > > > > Thank-you for the fix. > > Thanks for testing Phil. > > Request you to use the latest build [1] for a couple of days and report if > you see any drawing/repaint related issues. > > [1] > https://download.eclipse.org/eclipse/downloads/drops4/I20201127-1010/ > download.php?dropFile=eclipse-SDK-I20201127-1010-macosx-cocoa-x86_64.dmg I'm on it. Many of our Mac users are also testing these I-builds in our RCP app, Archi [1]. [1] https://www.archimatetool.com/beta/ > As a side note, will open a separate bug to build Eclipse launcher with > newer SDK for 4.19. Opened Bug 569257 to track this. Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/173069 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=b1a96f8b7ddee3511eabccef091799dbc9900595 *** Bug 568964 has been marked as a duplicate of this bug. *** Verified with I20201201-0600. New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/173210 (In reply to Eclipse Genie from comment #18) > New Gerrit change created: > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/173210 Update to javadoc Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/173210 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=a5dacddabdeee4de3c9766e18ef771434e902c02 New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176269 Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176269 was merged to [R4_15_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=6cf6f81de68006ed985bd70d657de1181cb1f107 New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/178526 New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/184464 |
Some annotation painters which is activated by entering some text into text editors such as Matching Bracket Annotation causes gives wrong visual result. (See the attachment) Steps to reproduce problem: 1. Open any Java Editor. 2. Enter several closing braces, eg: }}} 3. Enter several opening braces before closing brace. 4. '{' will not visible some while. 5. Text editor shows wrong content for while, or until scroll. I could not specify the exact reason that causes this problem. However, After digging about this, I realized that NSView.lockFocus() in Control#update() is related with this problem. lockFocus() / unlockFocus() are deprecated. And it seems that We can't avoid Automatic Differed Painting(ADP) mechanism anymore. Even we called lockFocus() / draw() / unlockFocus() manually, AppKit seems to draw once again for ADP. Currently Control#update(boolean) checks availability of NSGraphicsContext. If it's not available then it try to lock focus to draw, and check graphics context again. This seems to be an indirect or direct cause. When I removed this checking code, everything works fine again. I don't know these checking is still needed or not. What if some one can give me explanation about this, than I will make Gerrit for this. And I also noticed that: * All the NSView uses buffer now (It's not an option). * We can't avoid Automatic Differed Painting mechanism. * ADP will merge buffers of NSViews with direty regions just before displaying on screen. * So I think that the update() is pointless. * The update() causes rendering synchronously, However it is rendered on it's own buffer. And it will not visible unitl the ADP merges buffers to display it. * So, actually we don't have to do anything update(). Even just blank implementation works fine.