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 X-Server
load goes down to more normal levels (like 5-10%).
Why would that be on a local box? Seems like shared memory would be more
efficient? (using sun.java2d.pmoffscreen=true for both cases)
That would be my assumption as well. Not sure why would
that not be the case.
My current theory now as to why the "server" setting lowered the CPU
time of the X-Server is that the additional communication traffic became
the bottleneck, which throttled the amount of requests per second that
the X-Server had to service. I've switched back to "shared" since the
graphics tended to restore faster after something like an overlapping
window obscured part of the screen.
I guess it makes sense.
Also, I tried rendering the most expensive paint operation into an
off-screen buffer and then painted the buffer. The time to execute the
When you say off-screen buffer, what do you mean? A BufferedImage
or an image returned by create[Compatible]Image()?
paint method was reduced from 250 ms or more to around 90 ms, but the
X-Server CPU required did not change. Does the X-Server participate at
all when graphics are rendered in an off-screen buffer? If so, is there
If you're rendering to a BufferedImage then X server is not involved.
It only gets involved when you copy this image either to the screen
or to a surface backed by a Pixmap (opaque VolatileImage, BufferStrategy,
and - prior to jdk7 - opaque images created with create[Compatible]Image).
It is copied to a Pixmap/Window using X[Shm]PutImage. If such
image is translucent we first get the pixels from the destination
surface using XGetImage, then do the compositing on the client side
with our software loops, and then ship the pixels back with XPutImage.
Also, if such BufferedImage can be cached in a pixmap (if it's opaque
or 1-bit transparent), it gets copied to a pixmap and then all copies
from this image happen from that cached pixmap. It gets updated when
the original image gets rendered to.
The only thing you can do is disable the caching by setting
the acceleration priority property of an image to 0.0f. But I doubt
that this would help your case.
a way to have it not participate? I would think that painting a rendered
pixmap shouldn't be all that expensive. Buffered images are already
compatible with the system's graphics now right? (The original paint
method painted a sequence of perhaps 30 30x90 images/icons.) It is
still a little unclear to me where the various rendering/drawing
operations take place for the local X client-server model. Is there a
good reference to look at for this. (I guess I could download the VM
source now and peruse that if I had some spare time.)
It would really help if you could produce a simple test case
which resembles what your application does..
Thanks,
Dmitri
We are also going to try Solaris 10 just to see if it behaves the same
way. We'll give dtrace a try as well to see if that illuminates what is
going on.
Thanks,
Rob
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
