[OpenJDK 2D-Dev] [13] RFR 8214579: JFrame does not paint content in XVFB / X11vnc environment

Ichiroh Takiguchi takiguc at linux.vnet.ibm.com
Tue Jan 29 10:05:47 UTC 2019

Hello Dmitry.

Thank you for your explanation.

I could recreate your issue with XVFB/X11VNC on Ubuntu 18.04.
I tested sun.java2d.xrender system property also.
Since this Xserver had many visuals, I tested depth 32 visual by using 
FORCEDEFVIS environment variable.
It worked fine, so it seems it may be depth 16 related issue as you 

When I used vnc4server package on Ubuntu 18.04 with depth 32,
window did not come up.
It seemed infinity loop was happened by following codes:

(It seemed "i" was "-1" on line 447)
  447         awt_data->awtImage->clrdata.bScale = 0;
  448         while (i < 0x80) {
  449             awt_data->awtImage->clrdata.bScale++;
  450             i <<= 1;
  451         }

In case of XVFB/X11VNC:
     visual id:    0x41
     class:    TrueColor
     depth:    32 planes
     available colormap entries:    256 per subfield  <<<====
     red, green, blue masks:    0xff0000, 0xff00, 0xff
     significant bits in color specification:    8 bits

In case of vnc4server:
     visual id:    0x24
     class:    TrueColor
     depth:    32 planes
     available colormap entries:    2048 per subfield  <<<====
     red, green, blue masks:    0x7ff, 0x3ff800, 0xffc00000
     significant bits in color specification:    8 bits

It may be another issue, you handled 8214109 [1].
Is it same kind of color related issue ?

[1] https://bugs.openjdk.java.net/browse/JDK-8214109

Ichiroh Takiguchi

On 2019-01-26 00:14, Dmitry Markov wrote:
> Hi Ichiroh,
> That’s right, the problem is related to XRender. It does not happen
> if XRender pipeline is disabled.
> As far as I know the problem is not specific for Ubuntu 18.10. I think
> it takes place on other Linux platforms as well. Currently I can
> reproduce the problem only in XVFB/X11VNC environment, (i.e. you
> should run X11VNC over XVFB and depth parameter for VNC server must be
> set to 16). Alternatively you can use docker image (link is located at
> bug description) which contains necessary configuration to reproduce
> the problem.
> Thanks,
> Dmitry
>> On 25 Jan 2019, at 13:33, Ichiroh Takiguchi 
>> <takiguc at linux.vnet.ibm.com> wrote:
>> Hello.
>> I think if it's related xrender, could you try 
>> -Dsun.java2d.xrender=false ?
>> I could not recreate your issue, so I could not test it by myself.
>> It only happens on Ubuntu 18.10 ?
>> Please give me more detail configuration.
>> Thanks,
>> Ichiroh Takiguchi
>> On 2019-01-25 20:04, Dmitry Markov wrote:
>>> Hi Sergey,
>>> Thank you for the suggestion. I tested the patch proposed in that
>>> email thread. Unfortunately the problem is still reproducible on the
>>> build with the fix for JDK-8212677.
>>> Thanks,
>>> Dmitry
>>>> On 24 Jan 2019, at 16:05, Sergey Bylokhov 
>>>> <sergey.bylokhov at oracle.com> wrote:
>>>> Hi, Dmitry.
>>>> Can you please check your test on top of this fix?
>>>> https://mail.openjdk.java.net/pipermail/awt-dev/2019-January/014940.html
>>>> The description of the bug looks similar to this one.
>>>> On 23/01/2019 03:23, Dmitry Markov wrote:
>>>>> Hi Phil,
>>>>> I have found that the problem occurrence depends on depth setting 
>>>>> of VNC server. XVFB/X11VNC configuration (where the problem takes 
>>>>> place) uses 16 bpp and at the same time I cannot reproduce the 
>>>>> issue on X11VNC with 32 bpp. In other words the issue depends on 
>>>>> pixel size used by the configuration: it takes place if the pixel 
>>>>> size is 16 and does not happen if the pixel size is 24. I am not an 
>>>>> expert in XRender but the following seems correct: current 
>>>>> implementation of XRSurfaceData.getSurfaceType() always returns INT 
>>>>> (32-bit) surface type which might not work properly for the 
>>>>> configuration where pixel size is 16.
>>>>> Also the problem is not reproducible on XVNC4 (default depth value 
>>>>> is 16) because XRender pipeline cannot be enabled there for some 
>>>>> reasons. That may explain why the issue is  not observed on other 
>>>>> XVNC configurations. The root cause of XRender pipeline failure for 
>>>>> XVNC4 is currently unclear but I think it is out of scope for this 
>>>>> bug.
>>>>> Thanks,
>>>>> Dmitry
>>>>>> On 8 Jan 2019, at 18:44, Phil Race <philip.race at oracle.com 
>>>>>> <mailto:philip.race at oracle.com>> wrote:
>>>>>> I don't really understand why this only affects XVFB/X11VNC ?
>>>>>> The bug evaluation is vague in explaining the root cause.
>>>>>> What are they doing that is different ?
>>>>>> Is there an unexpected alpha channel ?
>>>>>> If so,
>>>>>> - are we then selecting a loop which is supplying a zero value 
>>>>>> alpha
>>>>>> channel instead of an opaque one ?
>>>>>> - why is it only for X11VNC ?
>>>>>> - Why was this not seen on Solaris ? Most if not all testing there 
>>>>>> uses Xvnc.
>>>>>> -phil.
>>>>>> On 1/8/19 2:24 AM, Dmitry Markov wrote:
>>>>>>> Hi Sergey,
>>>>>>> We started using XRSurfaceType (surface type from XRSurfaceData) 
>>>>>>> after integration of JDK-8204931 [1]. Before that fix 
>>>>>>> getSurfaceType() was not overridden in XRGraphicsConfig and 
>>>>>>> surface type from X11GraphicsConfig/X11SurfaceData, (i.e. 
>>>>>>> X11SurfaceType) was used for XRWindowSurfaceData and 
>>>>>>> XRPixmapSurfaceData. If I got it right JDK-8204931was intended 
>>>>>>> for fixing problems with XRPixmapSurfaceData and it solved them 
>>>>>>> by introducing surface type with PixelConverter in XRSurfaceData 
>>>>>>> and overriding getSurfaceType() in XRGraphicsConfig. These 
>>>>>>> changes are correct for XRPixmapSurfaceData but they accidentally 
>>>>>>> broke XRWindowSurfaceData and caused this problem.
>>>>>>> In proposed fix I restored the previous behaviour for 
>>>>>>> XRWindowSurfaceData, (i.e. use surface type from X11SurfaceData 
>>>>>>> instead there one from XRSurfaceData).
>>>>>>> Thanks,
>>>>>>> Dmitry
>>>>>>> [1] - https://bugs.openjdk.java.net/browse/JDK-8204931
>>>>>>>> On 7 Jan 2019, at 23:14, Sergey Bylokhov 
>>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> 
>>>>>>>> wrote:
>>>>>>>> Hi, Dmitry.
>>>>>>>> On 03/01/2019 10:29, Dmitry Markov wrote:
>>>>>>>>> Fix:
>>>>>>>>> It is necessary to use X11SurfaceType instead of XRSurfaceType 
>>>>>>>>> inside createData() for XRWindowSurfaceData
>>>>>>>> Can you please provide some more details why it is necessary? 
>>>>>>>> From the
>>>>>>>> first point of view the XRSurfaceType should be used for 
>>>>>>>> XRWindowSurfaceData,
>>>>>>>> because all this code is implementation of the XRender pipeline.
>>>>>>>> --
>>>>>>>> Best regards, Sergey.
>>>> --
>>>> Best regards, Sergey.

More information about the 2d-dev mailing list