Hi Rob,
Rob Ratcliff wrote:
Dmitri Trembovetski wrote:
In the local server case, have you tried setting
this env. variable: J2D_PIXMAPS=shared . It may help.
Oddly enough, when we use shared, the X-Server load goes up quite a
bit (on the order of 30-50%), whereas when we use server, the
Hi,
Dmitri Trembovetski wrote:
In the local server case, have you tried setting
this env. variable: J2D_PIXMAPS=shared . It may help.
Oddly enough, when we use shared, the X-Server load goes up quite a
bit (on the order of 30-50%), whereas when we use server, the X-Server
load goes down
Just thought I'd mention it - you can probably detect if the
display is local or remote programmatically:
get DISPLAY env variable via System.getenv() and
then check if there's an intersection between
the addresses of the host you're displaying to
and the local host.
You can peek
Hi Rob,
Rob Ratcliff wrote:
Hi Dmitri,
Dmitri Trembovetski wrote:
But in short, you'll need to minimize the amount of
rendering which is not supported by the X protocol if
you're expecting your application to be used in remote
X situations.
It may be used remotely, but currently
Hi Rob,
OK, I understand it better now. If your application does
translucent (alpha compositing) or anti-aliased rendering -
both not supported by the X protocol - we have
to perform the rendering using our software loops.
But since Swing's back-buffer lives on the server
(in a
Hi Dmitri,
I think we're understanding the problem more now. We think that a
repaint of the blank map is causing a repaint of an overlapping panel
that sports translucent gradient shading and vice-versa. So we're going
to take that out of the equation and see if the X-Server responds better.
Hi Rob,
what java version are you using? We have made some improvements in
jdk7 so that we don't send extra requests to the server.
Although looking at the requests it appears that the top
ones might belong to AWT, not 2D - which would explain
why you didn't see any difference when
