EVALUATION
This is due to the fact that we don't use Shared Memory Extension in 1.4
and we did in 1.3.x .
When 1.3.1 is run with NO_AWT_MITSHM env variable set to false
the rate drops below 1.4.
We probably won't be able to add shmem support in this late stage.
There is a workaround, though.
###@###.### 2001-08-16
We've been able to work on performance for all unix
platforms in beta3.
The highlights:
- store images in pixmaps anytime DGA is
not available, even in local case which imroves
performance of apps using swing.
The 'pmoffscreen' property controls this and can be used
to override the default.
- a new method X11SurfaceData.isDgaAvailable
is introduced. Returns true if we can actually
use dga (i.e. we can dga_grab the drawable and we have
a lib for this framebuffer)
It returns false on Linux and Solaris x86 as well as in remote
case on any platform so we'll use pixmaps in these cases.
- caching of X images on per-surface basis (may be changed
later to per-screen)
- Use of MitShMem extension:
- use mitshmem ext for rendering to the screen or
server (non-shared) pixmaps (similar to the way it was used in
1.3.x and prior).
The NO_J2D_MITSHM env variable disables use of mitshm.
- use Shared Mem Pixmaps for storing images
which are often read from.
By default all images first created as normal pixmaps,
which potentially means that they might be stored
in vram. If we detect that the image is
often read from (using Chet's new heuristic)
the image is punt to a Shm Pixmap.
Unfortunately there is no way to find if a pixmap
is stored in a vram, so we need this punting
to avoid problems with modern Linux X servers similar
to ones we have had on Win32 with compositing.
Env variable J2D_PIXMAPS=shared/server
overrides the default and forces use of either shared or
'normal' pixmaps.
After spending some quality time with Linux
I've traced a bug in Linux XFree86 4.0 X server. Rendering to a
16-bit shared pixmap may result in x server crash.
I wrote a pure c program which demonstrates this.
It renders a line (by XDrawLine) which touches the last
pixel of the pixmap - it's that simple.
Interestingly, we ourselves render the line just fine (if it's
transparent, for example). The crash doesn't happen
if I increase amount of shared memory allocated for
the image - so it looks like they have problems caclulating
scan line stride similar to ones I had earlier.
Note that by default Solaris OS has about 1M limit for a shared
segment, which is not much.
Use '/usr/sbin/sysdef -i | grep SHM' to find out your machine setup.
On Linux: '/usr/bin/ipcs -m -l'
To change the default settings on Solaris,
modify system's settings in /etc/system : add, for example,
the following lines, then reboot:
set shmsys:shminfo_shmmax=10000000
set shmsys:shminfo_shmmni=200
set shmsys:shminfo_shmseg=150
###@###.### 2001-09-24
|
Java