Intermittent paint flicker bug on MacOS?
Sergey Bylokhov
Sergey.Bylokhov at oracle.com
Mon Dec 7 14:33:02 UTC 2015
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" <swpalmer at 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 <ebakke at 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.
More information about the macosx-port-dev
mailing list