It will be better to move VBO creation and binding on vertexbuffer.c. (its why GetMemory didn't provide VBO id before, no need for that) Have you planned to use ti for index buffers too ?
That was my first idea(just bind the vertex buffer in GetMemory and return the offset), but the problem is that dx apps may split vertices on multiple buffers. They may store the position in buffer 1 and the colors of vertices in buffer 2. GetMemory is called when the FVF or declaration is converted into strided data. The strided data contains pointers to the vertex data which may come from many different VBs. I have to bind the VBO the data is stored in when I pass the data pointer to gl in LoadVertexArrays. This is perfectly ok for GL(and not a performance issue), but I need the VBO number in the strided data to know where each data comes from.
The vertex conversion is slow, and it turned out that if the app Locks the Buffer every frame then drawStridedSlow is faster Converting + drawStridedSlow. Because of that VBOs and the conversion aren't used for vertex buffers in system memory and vbs with WINED3DUSAGE_DYNAMIC are not loaded into a vbo.
For that problem i had a prototype who remembered too many lock (in small times) and active the no-VBO flag :)
I considered the same thing, considering that the app may be bad-behaved and set bad flags. Remembering the application's behavior seemed to be better.
However, I noticed that even well behaved apps(e.g. battlefield 1942) don't keep all the geometry they use in a map in vertex buffers at all time. Instead they load the area around the player, and load new stuff and throw away the old while the player moves through the map. As a result wined3d gets a bunch of IWineD3DVertexBuffer::Lock calls sporadically. Depending on the behavior of the player that is different. E.g. if a sniper stays at one place all the time there isn't much reload, but if he's flying a plane there is constantly new data. I couldn't think of any good heurisitics which could detect all that stuff, so I decided to rely on the flags set by the app. After all, the application developers know best what happens, and D3D8 and D3D9 apps are quite well-behaved compared to DDraw / D3D7 apps.
(Even if we can find a good way to handle the bf1942 and hl2 cases perfectly, who can say if we won't find a game which does something perfectly valid and fools our algorithms)
The same problem applies to textures and render targets, btw. For textures it can be solved quite well, render targes are more tricky.
Stefan