Created attachment 23929 [details]
I noticed that problem when using a Java AWT based chat applet, it was extremly slow up to the point where it was really annoying to use.
I created a small stand-alone test-case which can be executed with:
in the same directory where the file IntelPerfTest.class is located.
If you don't want to use the precompiled class file, feel free to compile the source with "javac IntelPerfTest.java".
Please scroll a bit arround or resize the window.
I guess part of the problem is the strange way Java renders non-antialiased text, uploading a 1-bit image, and using that as stipple.
This will be replaced by Java7 hopefully, however it shouldn't be *that* slow anyway. (worked well with EXA and XAA).
Created attachment 23930 [details]
test case's source
Created attachment 23931 [details]
small code excerpt how java blits glyphs
just noticed that the demo is much more responsive when a composition manager is used - its still slow but useable.
Without one, its very slow - real world applets are hardly useable anymore.
We don't intend to fix this in UXA ourselves. If you're drawing unantialiased text in 2009, your software fails. If you're not using Xft or cairo for text drawing in 2009, your software fails even harder (it would perform fine if you were).
We would consider applying patches if they were posted.
Well first of all this is not "my" software. It has been written ~15 years ago and worked well since then on all acceleration architectures.
However the problem is not isolated, it appears that fallbacks in general seem to be really expensive - way more than they are when using EXA.
So I am just an angry consumer, whose software has been broken, wondering why OpenGL on his intel chip is still too slow to play any games on it at serious resolutions (as it has always been), while on windows it does about 3 times the fps.
> We don't intend to fix this in UXA ourselves.
I don't intend to fix it either. This UXA stuff is "yours".
on Jan 22, 2017 at 01:34:55.
(provided by the Example extension).