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