(Forgot to CC--sorry for duplicate message.) Hi, Sergey. I think the core problem is that the Aqua L&F uses some very expensive approach to painting the indeterminate JProgressBar, going to the underlying window system on every single repaint. That's fine for static components like JButton, but probably not a good idea for animated components like indeterminate JProgressBar. The trivial Swing app at https://gist.github.com/anonymous/9ee8f2164c258c1a2b5f demonstrates this:
* When run on a 13-inch Mid 2012 MacBook Air with the Window maximized (at 1440x900) and the progress bar turned on, the ProgressBarTest process runs at between 20-27% CPU while the MacOS WindowServer process takes 10-14% CPU. * If I connect my external monitor and maximize the window to 2560x1440, CPU usage increases to 24-29% for the ProgressBarTest process while WindowServer takes 12-17%. That's with no other Java apps running at the same time. Curiously, the trivial Swing app above crashed twice (but not every time) as I connected my external monitor with the progress bar running. The crash report is attached. Might be a separate bug that is triggered by the high rate of window system calls. If the minimal JProgressBar app above is run while the NetBeans IDE is running, the flicker bug mentioned earlier appears in NetBeans. I haven't been able to reproduce the flicker bug in a simpler app, although it is _caused_ by the trivial app above. I suspect if the CPU usage part of the bug is solved, e.g. through using a different painting approach, then the flicker problem will go away as well. Ironically, the high CPU usage of the indeterminate JProgressBar tends to occur when other threads need the CPU the most--that is, when some other expensive process is going on that warrants the display of a progress bar (e.g. the dreaded "Background Scanning of Projects<https://blogs.oracle.com/joshis/entry/netbeans_ide_is_scanning_parsing>" that always makes the NetBeans IDE feel sluggish). -- Eirik On 12/7/15, 9:33 AM, "Sergey Bylokhov" <sergey.bylok...@oracle.com<mailto:sergey.bylok...@oracle.com>> wrote: Hi, Eirik. Can you share the test code(without using of external apps) and exact steps to reproduce this issue? On 03.12.15 23:58, Eirik Bakke wrote: I seem to be able to reproduce the bug now, at least on my own setup. When an animated indeterminate JProgressBar in the Aqua L&F is showing in one Java app, the CPU usage of MacOS' WindowServer process jumps to 25%, and the bug appears in _other_ Java apps (not the one containing the JProgressBar). When the JProgressBar shuts off, the bug disappears. I've confirmed this in both directions: When my Java IDE is showing an indeterminate JProgressBar in the form designer, my other running Java app has the flicker bug. When my Java app shows an indeterminate JProgressBar, the IDE has the flicker bug. When the JProgressBar is not showing in the other process, the bug disappears. Does it happen if you don¹t connect the external monitor? No, but it's possible it's just because painting takes too little time on a small monitor for the flicker to become noticable. Maybe try running with: export J2D_TRACE_LEVEL=4 When I did this I got new logging messages on startup (pasted below), but none while observing the bug. you could also try forcing openGL off with: -Dsun.java2d.opengl=false. This did not actually make the bug go away. I confirmed the setting with System.getProperty("sun.java2d.opengl"). Could this be as simple as a really odd bug in JProgressBar's Aqua L&F implementation? E.g. maybe the JProgressBar is doing a lot more work than necessary during its animation, like revalidating itself in the window hierarchy on every frame? -- Eirik =========================================================================== ================ [I] CGLGraphicsConfig_initCGL [I] OGLFuncs_OpenLibrary [I] OGLFuncs_InitPlatformFuncs [I] OGLFuncs_InitBaseFuncs [I] OGLFuncs_InitExtFuncs [I] CGLGraphicsConfig_getCGLConfigInfo [I] CGLGraphicsConfig_getCGLConfigInfo: OpenGL version=2.1 INTEL-8.28.36 [I] OGLContext_IsExtensionAvailable: GL_ARB_fragment_shader=true [I] OGLContext_IsExtensionAvailable: GL_ARB_multitexture=true [I] OGLContext_IsExtensionAvailable: GL_ARB_texture_non_power_of_two=true [I] OGLContext_IsExtensionAvailable: GL_ARB_texture_rectangle=true [I] OGLContext_IsExtensionAvailable: GL_EXT_framebuffer_object=true [I] OGLContext_IsExtensionAvailable: GL_ARB_depth_texture=true [I] OGLContext_IsFBObjectExtensionAvailable: fbobject supported [I] OGLContext_IsLCDShaderSupportAvailable: LCD text shader supported [I] OGLContext_IsBIOpShaderSupportAvailable: BufferedImageOp shader supported [I] OGLContext_IsGradShaderSupportAvailable: Linear/RadialGradientPaint shader supported [I] OGLContext_IsExtensionAvailable: GL_NV_fragment_program=false [I] OGLContext_IsExtensionAvailable: GL_ARB_fragment_program=true [I] OGLContext_IsExtensionAvailable: GL_NV_texture_barrier=true [I] CGLGraphicsConfig_getCGLConfigInfo: db=1 alpha=1 [I] CGLGraphicsConfig_getCGLConfigInfo [I] CGLGraphicsConfig_getCGLConfigInfo: OpenGL version=2.1 INTEL-8.28.36 [I] OGLContext_IsExtensionAvailable: GL_ARB_fragment_shader=true [I] OGLContext_IsExtensionAvailable: GL_ARB_multitexture=true [I] OGLContext_IsExtensionAvailable: GL_ARB_texture_non_power_of_two=true [I] OGLContext_IsExtensionAvailable: GL_ARB_texture_rectangle=true [I] OGLContext_IsExtensionAvailable: GL_EXT_framebuffer_object=true [I] OGLContext_IsExtensionAvailable: GL_ARB_depth_texture=true [I] OGLContext_IsFBObjectExtensionAvailable: fbobject supported [I] OGLContext_IsLCDShaderSupportAvailable: LCD text shader supported [I] OGLContext_IsBIOpShaderSupportAvailable: BufferedImageOp shader supported [I] OGLContext_IsGradShaderSupportAvailable: Linear/RadialGradientPaint shader supported [I] OGLContext_IsExtensionAvailable: GL_NV_fragment_program=false [I] OGLContext_IsExtensionAvailable: GL_ARB_fragment_program=true [I] OGLContext_IsExtensionAvailable: GL_NV_texture_barrier=true [I] CGLGraphicsConfig_getCGLConfigInfo: db=1 alpha=1 =========================================================================== ================ On 12/3/15, 7:40 AM, "Scott Palmer" <swpal...@gmail.com<mailto:swpal...@gmail.com>> wrote: I don¹t think I¹ve seen it. Does it happen if you don¹t connect the external monitor? Maybe try running with: export J2D_TRACE_LEVEL=4 to see if there are any debug messages that might give a hint as to what is going on. you could also try forcing openGL off with: -Dsun.java2d.opengl=false. Scott On Dec 3, 2015, at 12:19 AM, Eirik Bakke <eba...@mit.edu<mailto:eba...@mit.edu>> wrote: Hi, macosx-port-dev. Below is a bug report about a paint flicker bug on MacOS. I've tried to capture it on video here<https://vimeo.com/147649683>, although it's hard to see due to my camera's limited frame rate. Has anyone else observed this bug? Is this the right mailing list to ask on? -- Eirik ===== Bug report follows ===== There seems to be an intermittent but bad paint bug in recent versions of Java for MacOS (last 6-12 months; unsure which exact version it first appeared in). In my setup, I have the NetBeans IDE running on my MacBook Air for most of the day, and I connect and disconnect an external 2560x1440 monitor several times a day. About once a week, my running Java app (NetBeans IDE or the Java app I'm developing) enters a mode where all paint updates happen with a very noticable flicker. This is especially jarring when scrolling in a JScrollPane or typing text in the NetBeans editor. Typing also seems to be delayed. The flicker can also be seen in the indeterminate JProgressBar animation (blue stripey barberpole animation). The workaround is to restart the IDE or Java app in question. From observing the bug, what seems to be happening is that every time a new frame is painted, the old frame becomes briefly visible again for a fraction of a second before the new frame reappears. For instance, suppose the editor shows the word "tes" and the user types "t", then the following will happen: 1) The editor first shows "tes|". (where | is the cursor) 2) The user then types the letter "t", and the editor updates to show "test|". 3) Immediately afterwards, for a very brief moment, the editor shows "tes|" again. 4) Immediately afterwards again, the editor finally shows "test|" again. The bug appeared again today and I've tried to capture it on this video: https://vimeo.com/147649683 . However, the flickering happens so fast that it's difficult to see what's going on in a low-frame-rate screen recording. You can just see it happening during scrolling at 01:13 (compare with smooth scrolling in a different Java app for which the bug has not manifested itself at 02:40) and during editing right after 01:48. During editing, notice how the text cursor skips back while I'm typing characters (the recording only manages to catch it doing this every now and then). Product Version: NetBeans IDE 8.1 (Build 201510222201) Java: 1.8.0_66; Java HotSpot(TM) 64-Bit Server VM 25.66-b17 Runtime: Java(TM) SE Runtime Environment 1.8.0_66-b17 System: Mac OS X version 10.9.5 running on x86_64; UTF-8; en_US (nb) Hardware: 13-inch MacBook Air, Mid 2012 ======================== -- Best regards, Sergey.
