I logged into jano (solaris sparc 2.6) and set my display to point back at
gradgrind (solaris sparc 2.7). This happens with the promoted build 74.
I ran swingset2, and selected the colorchooser demo (the third one).
The animated pattern refreshed very badly - it disappeared for long
stretches of time. It seemed to repaint for a second if I covered the
swingset with another window, and then exposed it again.
Same thing with the java2demo: the demos don't refresh.
They just come up and stay the same the entire time.
This problem does not occur if I run locally on gradgrind.
It is partly the slow network, but only partly. When I use 1.3.1, the demos
refresh slowly, but they do refresh.
Whilst Swingset definitely has its own problems, I can verify that the 2D demo scenario
is helped immensely by the Xrender extension.
Remote displaying from Solaris 11 SPARC to Solaris 11 x86 with Nvidia card, 2D demo
using the X11 pipeline in AA mode reports 13fps for the Bezier animation. Switch
off AA and it goes up to 33 fps.
Now run again with the Xrender pipeline and BOTH AA and non-AA run smoothly at 33fps
So no performance loss at all for AA over remote X11 with Xrender.
I'm marking this fixed in the same build as the Xrender extension was integrated
in b97 under bug ID
6307603: [X11] Use RENDER extension for complex operations done in software
However note you do need to have access to that extension and turn it on with
-Dsun.java2d.xrender=True. It would be nice to enable that by default some day.
Unfortunately the fix for this proved to be harder
than anticipated. While some applications perform
better, many others don't. This will need
I've implemented a tentative fix which does caching of the
surface's pixels on the server side. This does improve performance
considerably but it still needs more tweaking and testing.
I've attached a diff+webrev based off mustang workspace
to this bugreport.
Reassigning to 2D at the request of hung@eng
The problem is that the the curve in the demo is rendered with antialiasing hint
turned on which prevents us from using remove offscreen acceleration:
we have to send the bits back and forth (read/modify/write).
This is the way we implemented remote X acceleration in merlin:
images reside on the server side so applications which do not use
2D api would benefit from it. Unfortunately this also means that those which
do use 2D (i.e. using antialiasing, compositing) would suffer: the performance
would be worse than in 1.3.1 (because of one extra read operation).
This is basically the same issue as described in bug
4464621: VolatileImage is very slow with transparent (AlphaComposite) colors
The performance in non-aa case is much better than in 1.3.1.
Run the BezierAnim demo from the Java2Demo remotely:
../../../bin/java -cp Java2Demo.jar java2d.demos.Arcs_Curves.BezierAnim
You can see that it refreshes very slow. But turn off AA (bring up instruments
panel at the bottom of the screen and deselect the first radiobutton)
and the demo will run very smoothly.
This could be easily seen by running Java2Demo and turning off AA - the
animation will start rendering much more smoothly.
There is not much we can do about this at this stage, so I'm lowering
the priority to P4.
It was decided to separate the two issues in this bug:
- poor performance of antialiasing/compositing in remote case
- the way this particular demo handles rendering, which causes
the refreshing problem to manifest.
Since a number of bugs related to the first issue have been closed
as a duplicate of this bug, I've filed another bug for the problem
4525465: SwingSet2/BezierAnimation demo needs to be updated
Turn off acceleration of offscreen images: