Bug 105886 - Corruption with Java Swing Applications without a compositor
Summary: Corruption with Java Swing Applications without a compositor
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
Depends on:
Reported: 2018-04-04 16:32 UTC by Zachary Tahenakos
Modified: 2018-04-09 06:02 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Test application (1.64 KB, application/zip)
2018-04-04 16:32 UTC, Zachary Tahenakos
no flags Details
Source (788 bytes, application/x-compressed)
2018-04-04 16:32 UTC, Zachary Tahenakos
no flags Details
Corrupted Window (13.39 KB, image/png)
2018-04-04 16:32 UTC, Zachary Tahenakos
no flags Details
Good working window (84.27 KB, image/png)
2018-04-04 16:33 UTC, Zachary Tahenakos
no flags Details
Content missing in window (61.40 KB, image/png)
2018-04-04 16:33 UTC, Zachary Tahenakos
no flags Details

Description Zachary Tahenakos 2018-04-04 16:32:18 UTC
Created attachment 138590 [details]
Test application

On a stock Ubuntu 14.04.5 system with openjdk-7-jre installed, when using a non-compositing Window Manager such as Openbox, Java Swing applications will not render correctly. Text/Images may be completely missing from the screen or rendered in a corrupted way. Resizing the windows changes or clears the corruption. When using a compositing window manager, these issues do not occur, but using one is not an option. 

Attached are screenshots showcasing good vs bad behavior and a test application with source.
Comment 1 Zachary Tahenakos 2018-04-04 16:32:40 UTC
Created attachment 138591 [details]
Comment 2 Zachary Tahenakos 2018-04-04 16:32:55 UTC
Created attachment 138592 [details]
Corrupted Window
Comment 3 Zachary Tahenakos 2018-04-04 16:33:10 UTC
Created attachment 138593 [details]
Good working window
Comment 4 Zachary Tahenakos 2018-04-04 16:33:26 UTC
Created attachment 138594 [details]
Content missing in window
Comment 5 Zachary Tahenakos 2018-04-04 16:35:21 UTC
Apologies, I neglected to mention that this was tested on KBL hardware:

CPU: Intel 3865-U
GPU: HD 610 (8086:5906)
Comment 6 Chris Wilson 2018-04-05 20:55:33 UTC
Can you attach Xorg.log and java -version?

Does it always happen? E.g. "X & sleep 2; openbox& java -jar Test.jar" is sufficent or does it need to be mixed with other clients?
Comment 7 Chris Wilson 2018-04-05 21:05:40 UTC
Hmm, openjdk-7. Not trivially reproducing on openjdk-8, so I will have to go back in time...
Comment 8 Zachary Tahenakos 2018-04-05 21:15:51 UTC
Hi Chris,

So I try and do things as "sane" as possible here. I don't manually run X or things like that. From the Ubuntu log in screen, after installing OpenBox, I just choose an Openbox session. Then I right click the screen and spawn an X-Terminal from the openbox menu and run the java program.

I don't have that Ubuntu box handy, but I have another box that also exhibits the issue, The version output of that is:

Java version "1.7.0_151"
OpenJDK Runtime Environment (IcedTea 2.6.11) (7u151-2.6.11-0ubuntu1.14.04.1)
OpenJDK 64-Bit Server VM (build 24.151-b01, mixed mode)

I did see that in JRE8 that this issue doesn't occur either, I'm not quite sure what the interaction could possibly be where JRE7 has drawing issues with (from what we can see) the Intel DDX driver using SNA sans a compositor but with JRE8 it's fine. 

Comment 9 Chris Wilson 2018-04-05 21:26:20 UTC
My limited knowledge of openjdk does however include the snippet that the default render backend changed between 7 and 8. It can be set using

policytool -J-Dsun.java2d.xrender=True

which became the default in 8. So let me try setting that to False and you can try setting that to True!
Comment 10 Chris Wilson 2018-04-05 21:33:58 UTC
A bit of googling confirms that the right way to use it is,
java -Dsun.java2d.xrender=True -jar Test.jar

That way it prints out when enabling the XRender backend, sadly the converse is not true as it doesn't print anything for False so I don't immediately know if it disables the xrender backend. Setting it to False on openjdk-8 did not reproduce the glitch (assuming the trivial setup is enough in the first place).
Comment 11 Zachary Tahenakos 2018-04-05 21:39:14 UTC
Hey Chris,

So I was able to figure that out and test that. Indeed, if I set xrender to true, then things seem to work. This makes sense as to why JRE8 works fine and JRE7 doesn't, thanks!

Comment 12 Chris Wilson 2018-04-05 22:32:46 UTC
Disabling the render extensions makes the text fields disappear, sometimes from the button as well. So that's something.
Comment 13 Chris Wilson 2018-04-05 23:59:14 UTC
commit 846879ae2ec1050b72ac9ddb7c791300e22f6793
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Apr 6 00:54:33 2018 +0100

    sna: Fix the relocation dword for stippled_1_blt
    We were telling the kernel the correct location for it to fill the
    64b relocation, but we were writing the presumed offset into the wrong
    pair of dwords in the batch ourselves. For the frequent case where we
    used a new upload buffer, the kernel would perform the fixup and correct
    our mistake, but if we happened to reuse a buffer then we told the gpu
    to source the stipple from the wrong address.
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105886
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

fixed the issue that occurred for me with openjdk-8 and disabling RENDER. Hopefully this is the one you hit as well!
Comment 14 Zachary Tahenakos 2018-04-06 00:03:21 UTC
Hey Chris,

Thanks! I will give this a try tomorrow when I'm in the office.

Comment 15 Zachary Tahenakos 2018-04-06 17:19:00 UTC
Hey Chris,

That patch works for me on JRE7 without forcing xrender. I think we can close this bug now, thank you very much for your work on this!

Comment 16 Jani Saarinen 2018-04-09 06:02:20 UTC
Verified by commment #15. Thanks. Closing.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.