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