Re: Errors locking offscreen surface if application heap is large
- From: DmitriAtSun@xxxxxxxxxxxxxxxxx <DmitriAtSunnewsgroupsnospam@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 16 Mar 2006 14:49:22 -0800
Hello Phil,
sorry for long silence, I was swamped with other stuff.
Here's a response to your earlier questions regarding our memory
usage.
The Java VM will reserve the entire memory region specified by the
-Xmx command line parameter, which sets the maximum amount of memory
available for the VM to be used as heap (for my test I used -Xmx1500m) so
it has a contiguous part of the address space to work in.
But it only commits the memory for -Xms (which is the the amount of
memory used for heap at startup, in my case I use -Xms1500m), and
whatever other expansion the program requires.
The heap is then broken up (by the JVM) into 3 mmapped regions: the young
generation, the old generation, and the permanent generation. (one
can see those (on Solaris or Linux) with the pmap command).
With another JVM option it's possible to print out the current
memory mappings.
Here's the output on my system (Dell Inspiron 700m, 500m of ram, Intel
852 chipset, fully patched Windows XP):
{Heap before GC invocations=4 (full 0):
def new generation total 106368K, used 103850K [0x02990000, 0x09cf0000,
0x09cf0000)
eden space 94592K, 99% used [0x02990000, 0x085ed348, 0x085f0000)
from space 11776K, 78% used [0x085f0000, 0x08efd678, 0x09170000)
to space 11776K, 0% used [0x09170000, 0x09170000, 0x09cf0000)
tenured generation total 1417856K, used 10750K [0x09cf0000, 0x60590000,
0x60590000)
the space 1417856K, 0% used [0x09cf0000, 0x0a76f8b8, 0x0a76fa00,
0x60590000)
compacting perm gen total 12288K, used 10708K [0x60590000, 0x61190000,
0x64590000)
the space 12288K, 87% used [0x60590000, 0x610053c0, 0x61005400,
0x61190000)
No shared spaces configured.
{Heap after GC invocations=5 (full 0):
def new generation total 106368K, used 104K [0x02990000, 0x09cf0000,
0x09cf0000)
eden space 94592K, 0% used [0x02990000, 0x02990000, 0x085f0000)
from space 11776K, 0% used [0x09170000, 0x0918a318, 0x09cf0000)
to space 11776K, 0% used [0x085f0000, 0x085f0000, 0x09170000)
tenured generation total 1417856K, used 19949K [0x09cf0000, 0x60590000,
0x60590000)
the space 1417856K, 1% used [0x09cf0000, 0x0b06b4f0, 0x0b06b600,
0x60590000)
compacting perm gen total 12288K, used 10708K [0x60590000, 0x61190000,
0x64590000)
the space 12288K, 87% used [0x60590000, 0x610053c0, 0x61005400,
0x61190000)
No shared spaces configured.
}
"Phil Taylor" wrote:
interesting problem.
DX7 still should have good debug output, have you turned the debug level all
the way up? DX7 you may still need to do this via the ini file, its been so
long since I worked with DX7 exclusively I cant recall.
just as an FYI, Surface.GetDC does a lock. If you comment out all your
GetDC/ReleaseDC code, does the failure go away? That would isolate this to
Well, the failure representation is that some stuff doesn't get
rendered. If I comment out Get/ReleaseDC, not much will be rendered.
Also, we use GDI for rendering to the screen. We use DirectDraw
for rendering to off-screen surface[s], which is then blitted
to the screen.
In some cases where the DirectDraw in DX7 functionality is not sufficient we
need to lock the offscreen surface and do the rendering using our
software loops.
the DX-GDI interface. If so, one possible solution is to rewrite all your
text painting code to use D3D.
At this point this is not possible, unfortunately (partly because of
the pixelization quality, and stability issues with D3D drivers).
We do have a pipeline which utilizes Direct3D for rendering (which is also
based on DirectX7),
but even with this pipeline we have to lock the plain offscreen
surfaces for some things (like copying the contents of our image in
system memory in some cases), and some other things which can't be
accelerated with D3D7 (like our implementation of LCD antialiasing,
which requires shaders => DX9).
Interestingly, when using our Direct3D pipeline, the locking of the
texture surfaces doesn't fail, but locking of D3D-target surface
(plain surfaces with D3D target property set), which is served as a
back-buffer
still fail.
Do you ever issue simultaneous locks?
You mean, for the same surface? No, we don't.
Thanks,
Dmitri
.
- Follow-Ups:
- Re: Errors locking offscreen surface if application heap is large
- From: DmitriAtSun@newsgroups.nospam
- Re: Errors locking offscreen surface if application heap is large
- Prev by Date: Re: combining two meshes
- Next by Date: Re: Errors locking offscreen surface if application heap is large
- Previous by thread: combining two meshes
- Next by thread: Re: Errors locking offscreen surface if application heap is large
- Index(es):
Relevant Pages
|
