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.bylok...@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.r...@oracle.com >>> <mailto:philip.r...@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.bylok...@oracle.com >>>>> <mailto:sergey.bylok...@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.
