Horde3D

Hey all.

I'm messing around with various GUI options. One uses webkit to render into a user defined buffer, which then gets used as a texture. I've got this pretty much setup now (using awesomium to test with, will try and change that to use Valve's CEF at some point).

Anyway, I'm hitting performance bottlenecks when it comes to rendering the webkit view into the texture. Basically I call mapResStream->write->unmapresstream like the example someone posted recently for flash, only the render performance is pretty horrific.

It looks like the render buffer is allocated every update (every call to mapresstream). Is there a better way to do this? It really only needs to keep a single buffer and constantly render to that. Is it ok to mapresstream once and render to it every update? Or is there some locking/unlocking semantics there?

So basically, whats the fastest way to keep a writeable texture buffer around.

Hi.

Which resolution / format is your texture? What is your target OS? Latest SVN version?
For a normal 2D texture Horde's mapResStream/unmapResStream should be reasonable fast.
It gives you back a pointer to a big enough data block (allocated only once and resized to fit when needed) and you memcpy into the buffer. Afterwards (unmapResStream) the GL texture object gets new data through glTexImage2D (which depending on the driver is faster than glTexSubImage2D).
So you should normally see tex uploads in the range of > 1 GB/s which should allow you to update some FullHD BGRA8 texture with 60fps.
For the GL case you could avoid the memcpy and let unmapResStream use a pointer provided by you, but in the DX context this would fail and I doubt that memcpy is the bottleneck.
We use the mapResStream quite a lot for dynamic texture uploads (video, animated textures) and there was no need for optimizing it (using PBOs for example).

Well, its doing a 1024x1024 texture right now. I think the bottleneck is that its allocating the new buffer at every call to mapresstream. When it really just needs to allocate once and let me fill it in via the webkit interface.

I do wonder if there isnt something else fishy going on though, because the flash UI thing does pretty much the same deal.

To understand correctly: you mean Renderer::useScratchBuf deallocates/allocates a buffer on every upload?
This should not be the case, unless your texture dimensions are constantly growing (which should not be the case either).
Maybe you do something fishy with the pointer you get from mapResStream? Maybe sizes don't match, so you corrupt memory?

Youre right, I was reading it wrong, it doesnt allocate every frame. So the performance must be going somewhere else. Hmm.

You didn't set the read parameter of h3dMapResStream to true, did you? Because that would of course result in a performance decrease.

No, pretty sure it was only writeable. I think its something else. Will post more when I revisit it later.

In your newest video you have a small bar at the right side - is that already Awesomium (check the left side in the video)? How long did it take you to integrate that? It looks awesome by the way.

How much of a bottleneck is this right now? Adding a constant fullscreen webbrowser to a game does not sound like the fastest thing ever, even without your current problems.

Hey johannes,

Nope, that bar is my own little gui thing. But its a disaster of code, which is why I was looking at using awesomium again. I'd used it before with ogre and it worked pretty well there. It also works pretty well for the wolfire guys.

I've got awesomium integrated so I can switch it on with a #define, but right now its simply unusable. Framerate loss is just way too high. But my old tests with the exact same code under Ogre didnt have anywhere near as harsh a framerate penalty, so I'm guessing that there's something I'm doing wrong with the texture creation/update. It would be nice to fix it, but I'm trying to make headway with the game itself right now.