|Also, I thought, but could easily be mistaken, that Greg had enabled
|off-screen h/w rendering (e.g., set Options rendering mode to hardware
|prior to pass objects to Render->WriteImage)
>> That's what I'm looking for. However I tried this, and I get the same
>> timings w/ and w/o rendering mode = hardware. Greg, if you implemented
this,
>> did it get committed?
I put code in there to read the image buffer back from the window, but it
requires
an X window and has obscuration problems, I think.
>> I didn't expect to see a difference because a grep of the DX source
finds
>> no mention of PBuffers. AFAIK, GLXPbuffers are the only way to do
HW-accel
>> off-screen rendering on X (SGI, and possibly Sun). GLXPixmap rendering
isn't
>> hardware-accelerated from everything I've read.
>> If I were to give it a go, how much trouble do you think it'd be to add
>> PBuffer rendering support. One key point is that PBuffers aren't X
>> Drawables (like Windows and Pixmaps), so I'm guessing this'd boil down
to
>> how well the X drawing functionality in DX is abstracted behind a DX
>> "drawing interface".
With less than 5 minutes thought, I'd guess it'd be pretty easy.
Basically,
the renderer is divided into a graphics API independent front end, and a
API-dependent back end. Different back ends used to be run-time loaded for
different platforms, but now OpenGL is always used. This code is *really*
ugly.
More specifically, you'd want to modify the Render module to look for a
"rendering mode" option like is done in the Display module. It ought to
call
something that imitates _dxfAsyncRender, but which returns an image.
Your imitation _dxfAsyncRender (call is _dxfOffScreenRender?) would pass
sonething in to _dxfCreateRenderModule that indicates off-screen rendering
-
"offscreen,www,hhh" where www and hhh are the image size (from the camera
input
to the Render module) should do. You'd modify _tdmParseDisplayString
to parse it, and modify the tdmParsedFormatT structure as necessary). You'd
modify _dxfCreateRenderModule to recognize off-screen rendering from
examining its
parameterl, and do the right thing. Don'tworry about _dxfNewPortHandle - it
doesn't
look at its parameters anymore, I don't think. You'd still call
_dxfCreateWindow,
but first you'd store the image width and height in the globals structure.
With all
the wacko de-referencing macros used in here, I guess it'd look like this:
(Note that
there's odd nesting in the current code so that the newly allocated globals
pointer
can be dereferenced through the DEFGLOBALDATA and DEFPORT macros)
/*
* In dxfCreateWindow....
* Allocate globals
*/
if (globals = (...) tdmAllocateZero(sizeof...
DXErrorGoto...
if (IsOffScreenRendering(format))
{
DEFGLOBALDATA(globals); /* sets _wdata = &globals->win */
DEFPORT(portHandle);
PORT_HANDLE = portHandle;
STEREO...
STEREO...
SORTLIST = _dxfNewSortList();
PIXW = format->width; /* PIXW is defined as _wdata->w */
PIXH = format->height; /* PIXH is defined as _wdata->h */
if (! _dxfCreateWindow(globals, NULL))
goto error;
if (! _dxf_INIT_RENDER_MODULE(...))
goto error;
.
}
else
{
/*
* As before...
*/
DEFGLOBALDATA(globals);
DEFPORT(portHandle);
...
}
Now modify _dxfCreateWindow to look for NULL winName, and if found, skip
all the
X stuff and just call _dxf_CREATE_WINDOW(globals, NULL, PIXW, PIXH) (make
sure
DEFGLOBALDATA has been called so PIXW and PIXH make sense). In
_dxf_CREATE_WINDOW
look for winName == NULL and do GLXPbuffer stuff rather than GLX stuff.
While
you're at it, modify _dxf_DELETE_WINDOW to delete GLXPbuffer stuff rather
than
GLX stuff if appropriate.
Now way back in dxfOffScreenRender, you'll have to fake out the X
event/interactor
interface to just render a damn picture. Finally, _dxfSaveHardwareWindow
ought to
retrieve the final image.
Faking out the X event/interactor interface to just render a damn picture
might be
a little tricky, but not hard. I've got to go now, but if you haven't been
scared
off yet (and having diddled the module ID stuff, I know you are pretty
intrepid) let
me know and I'll help.
Greg
