[OpenJDK 2D-Dev] [13] RFR 8214579: JFrame does not paint content in XVFB / X11vnc environment
Ichiroh Takiguchi
takiguc at linux.vnet.ibm.com
Wed Jan 30 13:20:28 UTC 2019
Hello Dmitry.
Thank you for your suggestion.
I applied a fix to ignore infinity loop and applied your patch.
But color was mixed up...
I opened JDK-8218054 [1].
It seems new color implementation is required.
I am glad that some experts will check the related codes.
[1] https://bugs.openjdk.java.net/browse/JDK-8218054
Thanks,
Ichiroh Takiguchi
On 2019-01-30 02:36, Dmitry Markov wrote:
> Hello Ichiroh,
>
> Definitely the problem occurrence depends on depth, (i.e. pixel size)
> settings. Actually such behaviour looks quite expected because the
> current implementation of XRSurfaceData.getSurfaceType() always
> returns INT (32-bit) surface type which most likely won't work
> properly for the configuration where pixel size is 16. I think we can
> use X11SurfaceData.getSurfaceType() as a fallback option inside
> XRender if the depth is 16 or less. I’ll try to implement such
> approach.
>
> Regarding the usage of XVNC4 with depth 32. I didn’t use such
> configuration. Based on your description I suspect the problem you
> observed, (i.e. infinity loop) and 8214109 are different. 8214109 is
> reproducible on XVNC4 with depth 16. The detailed steps to replicate
> the issue are provided in the bug report. Possible fix and related
> discussion are located at
> http://mail.openjdk.java.net/pipermail/awt-dev/2019-January/014949.html
> <http://mail.openjdk.java.net/pipermail/awt-dev/2019-January/014949.html>
> I believe it will make sense to file a new bug for infinity loop issue
> you observed.
>
> Thanks,
> Dmitry
>
>
>> On 29 Jan 2019, at 10:05, Ichiroh Takiguchi
>> <takiguc at linux.vnet.ibm.com> wrote:
>>
>> 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
>> said.
>>
>> 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:
>>
>> src/java.desktop/unix/native/common/awt/X11Color.c
>> (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:
>> 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:
>> 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
>>
>> Thanks,
>> 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