> Then use direct draw. You have access to everything there.
Actually we are already using DirectDraw, but we aren't using it to
create surfaces since the DD surfaces don't solve the problem.
I'll spell out all of the alternatives that we are aware of and their
problems since we seem to be going around in circles.
There are no (public) Windows APIs that provide all of:
- direct access to pixels
- pixels live in VRAM (hw accel)
- pixels are persistent
CreateDIBSection:
direct access: YES
live in VRAM?: NO
persistent: YES
CreateCompatibleBitmap
direct access: NO
live in VRAM?: PROBABLY
persistent: PROBABLY
DD->CreateSurface(VIDEOMEMORY)
direct access: YES
live in VRAM?: YES
persistent: NO (SurfaceLost happens without warning)
DD->CreateSurface(SYSTEMMEMORY)
direct access: YES
live in VRAM?: NO
persistent: YES
DD->CreateSurface(OFFSCREENPLAIN) seems to be the same as VIDEOMEMORY,
except it isn't an error if there is no VRAM left - DD will simply
create the surface in system memory instead. Either way, you still
are prone to SurfaceLost messages.
What we need is DD->CreateSurface(prefer VRAM, but not required) that
automatically moves the pixels to system memory when the VRAM is needed
for other purposes rather than just throwing out the pixels.
There may be some non-public DirectDraw APIs to do what we need, but
we are still investigating. If anyone knows of any other APIs or
CreateSurface flags (or a way to trap the SurfaceLost condition for
VRAM surfaces), please send us a pointer...
...jim
===========================================================================
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".
