I would like to limit this bug to the first problem mentioned: that of
the GUI being slow under remote display through ssh. The other issues
should be decomposed into other bug reports if necessary. Actually, I
believe other bug reports for those issues already exist, and I will
reference them below.
The second problem listed in the Description, that of windows being sized
very small when first shown is also described under other bug reports.
It is likely to be a window manager interaction. See, for example, 4429511.
I talked to ###@###.###, and he pointed me to a couple of bugs reports
in the 2D category: 4374153 and 4398828. They both describe the other two
problems: slow GUIs and parts of the GUI not being painted. It sounds like
this bug has essentially been resolved. I'll let 2D close it as a duplicate
as they see fit.
I don't believe this is a duplicate of 4374153 and 4398828.
(btw, they're already fixed in 1.3.1).
Problem with repainting is most likely to be the famous
4244833: Painting of JMenus have deteriorated
As for the slowness - we don't do anything different for
ssh case versus 'normal' remote case, so this is most likely
a result of Java2D sending pixels intensively back and forth
(since it uses a lot of 2D apis - compositing, antialiasing).
Unfortunately I don't think this is fixed in 1.4. Java2Demo
types of applications would likely not to benefit from the
remote X acceleration work done for Merlin, since
the main part of that work was storing images in Pixmaps
on the server side. This will improve copying images to the
screen and solid color rendering as we use X requests for doing that.
For compositing, antialiasing and such (operations which
require read-modify-write) we'll have first read the
image to client, modify the pixels and then put the
image back to server, while in 1.3.x the images were stored on
the client side, so the operation required one less
transaction over the wire.
Thus said, it's important that Swing-type applications (like
SwingSet2, for example) benefit from the work in 1.4 hugely.
In this sense, Java2Demo is not a 'typical' swing application.
SwingSet2 runs just fine with and without ssh (I've tried
solaris<->solaris and solaris<->linux). Users are
encouraged to try 1.4 (beta 2 is currently out).
I'm marking this bug fixed in Meriln as typical swing application
show decent performance when run through ssh.
For the 2D rendering in remote X there is another bug
4488401: Antialiasing/Compositing is slow on remote display