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

[Phil Race]

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
>>>
>>>
>>>> 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/20190123/8efeb88a/attachment.html>