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

[Ichiroh Takiguchi]

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.