Poor graphic performance on java apps

[Carsten Haitzler (The Rasterman)]

On Mon, 10 Oct 2005 21:47:39 +0200 "Helge Fredriksen" <helgefr at online.no>
babbled:

> Hello,
> 
> I'm a java developer using the IntelliJ idea IDE. I had a dream once that I
> could switch to Linux, but it seems that the X is the bottleneck. The IDE
> (and also the Swing clients I'm developing) has really bad resposiveness
> compared to what I'm used to on Windows. 
> 
> Anyway I could tune the X system to speed it up, or is it hopeless? Any
> alternatives to X on Linux that supports Java Swing?
> 
> I'm using Fedora Core 3 and the standard Gnome desktop.

(all the people who love java with passion - look away now. this will be rather
offensive).

in recent months (the last 9 or so) i have had the opportunity to have to deal
with java applications from the point of view of a window manager... after a
lot of "why the f**k does this java app behave differently under twm, under
enlightenment 0.16, under kwin and udner x with no wm running?" with lots of
xmon protocol dumps. java literally was sending different protocol requests
where it should have been predictable...

anyway - my answer was found in going thru the newly released java source code.
in their awt abstraction that maps basic java gfx and windowing calls for awt
and swing onto x. i was shocked. i have never seen such a dogs breakfast of
dealing with x. it was hackery to the nth degree. they have so many nasty kinds
of hacks to try detect what wm u run - and in the case of a detected one,
literally behave differently when mapping/opening windows, handling their
events etc. it shows very little respect for icccm and window management and
they did only SPECIFIC case hacks. their general case assumptions are very poor
at best. if your wm is a new one and not detected yet (which is actually most
wm's as they only detect about half a dozen) you either have to try pretend to
be another wm, or live with broken java apps they do thigns like don't draw,
make their windows 4 times they size they should be etc. java's awt liked to do
things like ASSUME it can figure out the top-left cornder of the FRAME window
all the time. it likes to ASSUME single re-parenting on a wm's part if it isn't
100% correctly detected, and more.

this was in java's 1.4 codebase mind you. anyway - it didn't show a deep
insight into doing things right under x. i saw LOTS of round-trip requests
where it shouldn't be doing such things under x - or avoiding them like the
plague. anyway, the point here is, that given insight into the code i was
looking at, i would venture to extrapolate and say most of the x layer code for
awt (and thus swing) would likely have similar problems in many areas and thus
it's really java's problem of simply not having a well done gfx layer for
awt/swing.

this may have improved for 1.5 and later java releases, and sun may in future
make this better, but as it stands, using swing/awt under X works, on a good
say, with luck, but working optimally is something i would hazard a guess of
"no". eclipse is java, but doesnt use swing/swt. they build on top of gtk under
x and gtk definitely has a much better usage pattern for x.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多                              raster at deephackmode.org
Tokyo, Japan (東京 日本)