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.r...@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.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 >>>> <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. >>>> >>> >> >
