|
Replies:
8
-
Last Post:
Sep 26, 2007 8:36 AM
by: Dmitri Trembove...
|
|
|
|
|
|
|
Trouble Shooting High X-Server Load on Solaris
Posted:
Sep 16, 2007 9:52 AM
|
|
|
Hi,
I'm troubleshooting a fairly large application built on top of the NetBeans 6 platform that is causing the X-Server to chew up up a lot (30%-50%) CPU when all it seems to be doing is refreshing a blank (no data) Map (we're using Openmap) once a second. (I'm going verify that this week and ensure the entire app isn't getting repainted or revalidated once a second or more.) It is running locally and I'm running it with the -J-Dsun.java2d.pmoffscreen=true. (I've tried false as well.) The Java process is only taking 5% or so compared to the X-Server load.
In comparison, a similar application (uses OpenMap, but not built on NetBeans) we have uses only 2-5% total CPU with the map populated and updating more than once a second.
I've tried all the flags documented in the Java2D whitepaper (http://java.sun.com/products/java-media/2D/perf_graphics.html), but I haven't been as fortunate this time for a quick fix. (I did use the -J option to pass the VM option through the NetBeans exec to the VM.)
(BTW, this is a Sun Blade 2000 UltraSparc III+ with a GFX-450 Graphics card, running Solaris 8. It has 4 GB of memory and I significantly increased the shared memory segments from the defaults.)
To get some insight into what was going on, I used the X-Server proxy, xmon, to monitor the X-Event traffic to see what was going on and noticed that there seems to be a lot of X-Event traffic. I was expecting more bitmap type operations where the Swing's buffered image would be sent to the local X-Server rather than the nearly 2000 primitive draws per minute. It is almost as if Swing isn't double buffering.
I've also tried using the -J-Dsun.java2d.trace=<optionname>,<optionname> to get a log of the messages, but nothing was printed. (I've tried it on Java 5 and 6.) Does that work on the newer versions of the VM. (I need to run a test as well outside of the NetBeans app to see if the NetBeans platform is intercepting it somewhere.)
Does anybody have some suggestions on what might be going on?
Thanks!
Rob
--------------------------xmon summary---------------------------------------------
requests received (for about 1 minute):
code count name
1 9 CreateWindow
2 29 ChangeWindowAttributes
3 4 GetWindowAttributes
4 4 DestroyWindow
8 6 MapWindow
10 1 UnmapWindow
12 20 ConfigureWindow
14 4 GetGeometry
15 4 QueryTree
16 83 InternAtom
17 1 GetAtomName
18 129 ChangeProperty
19 11 DeleteProperty
20 326 GetProperty
23 2 GetSelectionOwner
24 317 ConvertSelection
25 4 SendEvent
36 1 GrabServer
37 1 UngrabServer
40 2 TranslateCoordinates
42 7 SetInputFocus
43 615 GetInputFocus
45 19 OpenFont
46 2 CloseFont
47 18 QueryFont
53 51 CreatePixmap
54 36 FreePixmap
55 81 CreateGC
56 2979 ChangeGC
59 2027 SetClipRectangles
60 48 FreeGC
61 2 ClearArea
62 497 CopyArea
66 1605 PolySegment
67 246 PolyRectangle
69 3 FillPoly
70 1615 PolyFillRectangle
72 490 PutImage
73 8 GetImage
78 2 CreateColormap
84 36 AllocColor
93 17 CreateCursor
94 2 CreateGlyphCursor
97 28 QueryBestSize
98 8 QueryExtension
101 1 GetKeyboardMapping
117 1 GetPointerMapping
119 2 GetModifierMapping
events received (for about 1 minute):
code count name:
6 81 MotionNotify
7 8 EnterNotify
8 8 LeaveNotify
9 11 FocusIn
10 12 FocusOut
12 11 Expose
17 1 DestroyNotify
18 1 UnmapNotify
19 2 MapNotify
21 2 ReparentNotify
22 13 ConfigureNotify
28 783 PropertyNotify
31 319 SelectionNotify
33 5 ClientMessage
errors received:
code count name
10 1 Access
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
|
|
|
|
|
|
|
Re: [JAVA2D] Trouble Shooting High X-Server Load on Solaris
Posted:
Sep 17, 2007 10:47 AM
in response to: Rob Ratcliff
|
|
|
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 trying the Java2D
flags.
Thanks,
Dmitri
Rob Ratcliff wrote:
> Hi,
>
> I'm troubleshooting a fairly large application built on top of the NetBeans 6 platform that is causing the X-Server to chew up up a lot (30%-50%) CPU when all it seems to be doing is refreshing a blank (no data) Map (we're using Openmap) once a second. (I'm going verify that this week and ensure the entire app isn't getting repainted or revalidated once a second or more.) It is running locally and I'm running it with the -J-Dsun.java2d.pmoffscreen=true. (I've tried false as well.) The Java process is only taking 5% or so compared to the X-Server load.
>
> In comparison, a similar application (uses OpenMap, but not built on NetBeans) we have uses only 2-5% total CPU with the map populated and updating more than once a second.
>
> I've tried all the flags documented in the Java2D whitepaper (http://java.sun.com/products/java-media/2D/perf_graphics.html), but I haven't been as fortunate this time for a quick fix. (I did use the -J option to pass the VM option through the NetBeans exec to the VM.)
>
> (BTW, this is a Sun Blade 2000 UltraSparc III+ with a GFX-450 Graphics card, running Solaris 8. It has 4 GB of memory and I significantly increased the shared memory segments from the defaults.)
>
> To get some insight into what was going on, I used the X-Server proxy, xmon, to monitor the X-Event traffic to see what was going on and noticed that there seems to be a lot of X-Event traffic. I was expecting more bitmap type operations where the Swing's buffered image would be sent to the local X-Server rather than the nearly 2000 primitive draws per minute. It is almost as if Swing isn't double buffering.
>
> I've also tried using the -J-Dsun.java2d.trace=<optionname>,<optionname> to get a log of the messages, but nothing was printed. (I've tried it on Java 5 and 6.) Does that work on the newer versions of the VM. (I need to run a test as well outside of the NetBeans app to see if the NetBeans platform is intercepting it somewhere.)
>
> Does anybody have some suggestions on what might be going on?
>
> Thanks!
>
> Rob
>
> --------------------------xmon summary---------------------------------------------
>
> requests received (for about 1 minute):
> code count name
> 1 9 CreateWindow
> 2 29 ChangeWindowAttributes
> 3 4 GetWindowAttributes
> 4 4 DestroyWindow
> 8 6 MapWindow
> 10 1 UnmapWindow
> 12 20 ConfigureWindow
> 14 4 GetGeometry
> 15 4 QueryTree
> 16 83 InternAtom
> 17 1 GetAtomName
> 18 129 ChangeProperty
> 19 11 DeleteProperty
> 20 326 GetProperty
> 23 2 GetSelectionOwner
> 24 317 ConvertSelection
> 25 4 SendEvent
> 36 1 GrabServer
> 37 1 UngrabServer
> 40 2 TranslateCoordinates
> 42 7 SetInputFocus
> 43 615 GetInputFocus
> 45 19 OpenFont
> 46 2 CloseFont
> 47 18 QueryFont
> 53 51 CreatePixmap
> 54 36 FreePixmap
> 55 81 CreateGC
> 56 2979 ChangeGC
> 59 2027 SetClipRectangles
> 60 48 FreeGC
> 61 2 ClearArea
> 62 497 CopyArea
> 66 1605 PolySegment
> 67 246 PolyRectangle
> 69 3 FillPoly
> 70 1615 PolyFillRectangle
> 72 490 PutImage
> 73 8 GetImage
> 78 2 CreateColormap
> 84 36 AllocColor
> 93 17 CreateCursor
> 94 2 CreateGlyphCursor
> 97 28 QueryBestSize
> 98 8 QueryExtension
> 101 1 GetKeyboardMapping
> 117 1 GetPointerMapping
> 119 2 GetModifierMapping
> events received (for about 1 minute):
> code count name:
> 6 81 MotionNotify
> 7 8 EnterNotify
> 8 8 LeaveNotify
> 9 11 FocusIn
> 10 12 FocusOut
> 12 11 Expose
> 17 1 DestroyNotify
> 18 1 UnmapNotify
> 19 2 MapNotify
> 21 2 ReparentNotify
> 22 13 ConfigureNotify
> 28 783 PropertyNotify
> 31 319 SelectionNotify
> 33 5 ClientMessage
> errors received:
> code count name
> 10 1 Access
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Trouble Shooting High X-Server Load on Solaris
Posted:
Sep 17, 2007 12:10 PM
in response to: Dmitri Trembove...
|
|
|
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.
Just to clarify my understanding though, where is the filled rectangle
generated? Is it an off-screen buffer/pixmap on the client side that is
sent to the X-Server or is it done with primitives sent to the X-Server?
And, what input settings cause it to change from client to server. (The
pmoffscreen=false does help quite a bit when remoting the GUI over X.)
Thanks!
Rob
Dmitri Trembovetski wrote:
> 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 trying the Java2D
> flags.
>
> Thanks,
> Dmitri
>
>
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Trouble Shooting High X-Server Load on Solaris
Posted:
Sep 18, 2007 9:48 AM
in response to: Rob Ratcliff
|
|
|
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 pixmap), we have to read the pixels from the
pixmap to the client, modify then and write them
back.
It's worse if you have a gradient: then the rendering
will be done scanline by scanline - this is the
way our software pipeline does it.
Consider rendering your gradient to a BufferedImage
instead and then copying it to the back-buffer.
If the gradient fills whole component area (and is not
translucent), the BufferedImage can be opaque
(and make sure that isOpaque() property of the component
is true)
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.
In the local server case, have you tried setting
this env. variable: J2D_PIXMAPS=shared . It may help.
And, you can always programmatically set
-Dsun.java2d.pmoffscreen=false in your application (just
make sure you set it before any gui is initialized).
Thanks,
Dmitri
Rob Ratcliff wrote:
> 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.
>
> Just to clarify my understanding though, where is the filled rectangle
> generated? Is it an off-screen buffer/pixmap on the client side that is
> sent to the X-Server or is it done with primitives sent to the X-Server?
> And, what input settings cause it to change from client to server. (The
> pmoffscreen=false does help quite a bit when remoting the GUI over X.)
>
> Thanks!
>
> Rob
>
>
> Dmitri Trembovetski wrote:
>> 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 trying the Java2D
>> flags.
>>
>> Thanks,
>> Dmitri
>>
>>
>
>
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Trouble Shooting High X-Server Load on Solaris
Posted:
Sep 19, 2007 8:20 AM
in response to: Dmitri Trembove...
|
|
|
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 we're trying to get it to run
without excessively loading up the local X-Server
I think we should probably add a -nonFancyMode flag to our app where it
doesn't use translucent panels or gradient shading on machines with
older graphics cards or when remoting the app.
> 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)
> And, you can always programmatically set
> -Dsun.java2d.pmoffscreen=false in your application (just
> make sure you set it before any gui is initialized).
That's a good idea. In the past, we've put that in the scripts, which
would detect whether the display variable was set to the local display
or the remote display. We also had to put in logic to detect certain
graphics cards since they responded differently as well.
BTW, (you all might have considered this already) it might be nice to
have a command line setting like -bestSettings where the Java2D layer
could attempt to automatically measure and configure itself with the
most optimal settings for lowest overall load (Java Application+XServer)
and graphics responsiveness at least for the client and server running
on the same box. It can take some time to manually figure the optimal
combination of environment variables and command line settings to create
the best performing application especially when it seems that different
X-Server/graphics card tends to require different settings. (For
instance, on certain Linux boxes, it was more efficient to use
pmoffscreen=true even when remoting the application from the Solaris box
when on a fast network.)
Thanks again!
Rob
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Trouble Shooting High X-Server Load on Solaris
Posted:
Sep 19, 2007 9:22 AM
in response to: Rob Ratcliff
|
|
|
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 we're trying to get it to run
> without excessively loading up the local X-Server
> I think we should probably add a -nonFancyMode flag to our app where it
> doesn't use translucent panels or gradient shading on machines with
> older graphics cards or when remoting the app.
Yes, that would be a good idea. It doesn't even have to be
automatic - one can add an option for the user to switch at
runtime.
>> 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.
>> And, you can always programmatically set
>> -Dsun.java2d.pmoffscreen=false in your application (just
>> make sure you set it before any gui is initialized).
> That's a good idea. In the past, we've put that in the scripts, which
> would detect whether the display variable was set to the local display
> or the remote display. We also had to put in logic to detect certain
> graphics cards since they responded differently as well.
>
> BTW, (you all might have considered this already) it might be nice to
> have a command line setting like -bestSettings where the Java2D layer
> could attempt to automatically measure and configure itself with the
> most optimal settings for lowest overall load (Java Application+XServer)
> and graphics responsiveness at least for the client and server running
> on the same box. It can take some time to manually figure the optimal
> combination of environment variables and command line settings to create
> the best performing application especially when it seems that different
> X-Server/graphics card tends to require different settings. (For
> instance, on certain Linux boxes, it was more efficient to use
> pmoffscreen=true even when remoting the application from the Solaris box
> when on a fast network.)
I think it would be very hard to determine such best settings.
The main issue is that each application may behave differently -
so we couldn't do it just once during the installation of the jre,
for example. And, of course, people can use different DISPLAY from
the one that the jre was installed with (happens all the time
with server boxes). To do something like this every time during
startup would have a startup time impact.
In general we rely on that the developers know better about what
their application does and how it behaves. Any heuristics we
could come up with will help some and hurt others - this was proven
many times already.
But the developer can have (like you suggested) a "no fancy mode" in
the application appropriate for the conditions, or key off the user
input.
Thanks,
Dmitri
>
> Thanks again!
>
> Rob
>
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Trouble Shooting High X-Server Load on Solaris
Posted:
Sep 20, 2007 8:56 AM
in response to: Dmitri Trembove...
|
|
|
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 at how this can be done in
j2se/src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ,
see _isDisplayLocal method
(now that we're open source and all =)
Thanks,
Dmitri
Java2D Team
Dmitri Trembovetski wrote:
>
> 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 we're trying to get it to run
>> without excessively loading up the local X-Server
>> I think we should probably add a -nonFancyMode flag to our app where it
>> doesn't use translucent panels or gradient shading on machines with
>> older graphics cards or when remoting the app.
>
> Yes, that would be a good idea. It doesn't even have to be
> automatic - one can add an option for the user to switch at
> runtime.
>
>>> 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.
>
>>> And, you can always programmatically set
>>> -Dsun.java2d.pmoffscreen=false in your application (just
>>> make sure you set it before any gui is initialized).
>> That's a good idea. In the past, we've put that in the scripts, which
>> would detect whether the display variable was set to the local display
>> or the remote display. We also had to put in logic to detect certain
>> graphics cards since they responded differently as well.
>>
>> BTW, (you all might have considered this already) it might be nice to
>> have a command line setting like -bestSettings where the Java2D layer
>> could attempt to automatically measure and configure itself with the
>> most optimal settings for lowest overall load (Java Application+XServer)
>> and graphics responsiveness at least for the client and server running
>> on the same box. It can take some time to manually figure the optimal
>> combination of environment variables and command line settings to create
>> the best performing application especially when it seems that different
>> X-Server/graphics card tends to require different settings. (For
>> instance, on certain Linux boxes, it was more efficient to use
>> pmoffscreen=true even when remoting the application from the Solaris box
>> when on a fast network.)
>
> I think it would be very hard to determine such best settings.
> The main issue is that each application may behave differently -
> so we couldn't do it just once during the installation of the jre,
> for example. And, of course, people can use different DISPLAY from
> the one that the jre was installed with (happens all the time
> with server boxes). To do something like this every time during
> startup would have a startup time impact.
>
> In general we rely on that the developers know better about what
> their application does and how it behaves. Any heuristics we
> could come up with will help some and hurt others - this was proven
> many times already.
>
> But the developer can have (like you suggested) a "no fancy mode" in
> the application appropriate for the conditions, or key off the user
> input.
>
> Thanks,
> Dmitri
>
>
>>
>> Thanks again!
>>
>> Rob
>>
>
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Trouble Shooting High X-Server Load on Solaris
Posted:
Sep 25, 2007 2:14 PM
in response to: Dmitri Trembove...
|
|
|
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 listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Trouble Shooting High X-Server Load on Solaris
Posted:
Sep 26, 2007 8:36 AM
in response to: Rob Ratcliff
|
|
|
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 listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
|
|
|
|
|
java.net RSS
