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.
