Bug 67865

please launch the application using:

java -Dsun.java2d.xrender=false -jar proto.jar

(-Dsun.java2d.xrender=false is default for Java-7 and lower, its there just to make sure you are hitting the old rendering paths in case you run experimental Java-8 builds).

Oh, that looks peculiar indeed.

Can you help me with this?

=0 cantiga:~$ java -Dsun.java2d.xrender=false -jar /tmp/proto.jar 
Exception in thread "main" java.lang.UnsupportedClassVersionError: PalmeStarter : Unsupported major.minor version 51.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
	at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
Could not find the main class: PalmeStarter. Program will exit.
=1 cantiga:~$ 

I'll try on a fedora SNB machine very shortly.

Created attachment 83780 [details]
demo application compatible with Java <=6

sorry, compiled the original demo-app for Java7+.

as far as I know, text rendering is performed using bit-masks (seemed to be the most efficient way to render client-side text back in 1996 ;) ).

Heh, just because it was efficient in 1986, doesn't make it any less efficient today! (Intel at least still retains hw support for the blitter.) You just need extremely high resolution displays to truly appreciate bitmap fonts. ;)

Quick test on an uncomposited SNB laptop with the java6 proto.jar doesn't reveal any issues. Which kernel are you using?

I was using 3.11rc4 on an uncomposited xfce desktop.

... just verified: on my machines it is reproduceable even with really old java versions (Java 5 from 2003)

Still happy here. Let's try a debug=full log and see if anything pops up.

Here it is http://93.83.133.214/fulldebug_log.7za

The testing started after the first VT switch. Probably reading the log is easier towards the end (after a few VT switches more), as I was able to minimize the painting caused by non-related areas (such as the grid, which seems to paint horribly slow with debug=full).

Clemens, any chance for an update on whether this occurs? I'm wondering if this is not the same as bug 66990

Definitely worth checking against:

commit a048f436a0210d076fc844404bf56b8b7fcb4b7b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Oct 2 14:59:11 2013 +0100

    sna: Only delete unused io buffers
    
    Before deleting the io buffer, we need to check that it is not active.
    Currently we check that it is not pending use in the current batch, but
    we also need to double check that it does not have outstanding use by
    the GPU. Failing to do so could mean overwriting the data prior to it
    being read by the GPU, a very small race but often hit!
    
    Reported-by: Vedran Rodic <vrodic@gmail.com> # and many others
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66990
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Possibly:

commit 2cf2312372ebde4168ae1e66a97d5c6b8daff1c3
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Oct 17 17:14:13 2013 +0100

    sna: Fix computation of clip boxes for stipple uploads
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=67865
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

2cf2312372ebde4168ae1e66a97d5c6b8daff1c3 fixed the issue :-)

Thanks for your patience.