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 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.
Also, I tried rendering the most expensive paint operation into an off-screen buffer and then painted the buffer. The time to execute the 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 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.) 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".
