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.
Created attachment 138591 [details] Source
Created attachment 138592 [details] Corrupted Window
Created attachment 138593 [details] Good working window
Created attachment 138594 [details] Content missing in window
Apologies, I neglected to mention that this was tested on KBL hardware: CPU: Intel 3865-U GPU: HD 610 (8086:5906)
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?
Hmm, openjdk-7. Not trivially reproducing on openjdk-8, so I will have to go back in time...
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. -Zack
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!
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).
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! -Zack
Disabling the render extensions makes the text fields disappear, sometimes from the button as well. So that's something.
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!
Hey Chris, Thanks! I will give this a try tomorrow when I'm in the office. -Zack
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! -Zack
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.