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

[Dmitry Markov]

Hi Phil,

I have opened https://bugs.openjdk.java.net/browse/JDK-8217718 <https://bugs.openjdk.java.net/browse/JDK-8217718> for XRender issue on XVNC4.

Any thoughts regarding the proposed fix for this one? Any inputs are much appreciated.

Thanks,
Dmitry

> On 23 Jan 2019, at 17:25, Phil Race <philip.race at oracle.com> wrote:
> 
> OK, that is good enough for now, please file a bug against Xrender + 16bit visuals, so
> we can remember this.
> 
> -phil.
> 
> On 1/23/19 3:23 AM, 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 <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.
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20190124/a1d09d96/attachment-0001.html>