tags:

views:

50

answers:

0

Hi,

I'm working on a simulator which relies on OpenGL to display symbols, maps, moving items... as layers/textures.

We are investigating different options to introduce multitouch support in the simulator.

WPF is one of the options, as it could provide interesting productivity factors for GUI development. A prototype has been built but it does not meet our performance requirements.

I'm looking for a way to improve performance or for any advice which could put us back on the right track.

The current system is based on

  • A main/hosting application written on C++ and OpenGL which drives (start, schedule, stop...) the WPF part and provides context informations

  • A WPF app with multitouch support which reacts accordingly to the main context and to user input

  • A COM component for communication beetween the Main/hosting app and the WPF app

  • Multitouch inputs managed by a specific abstraction layer (handles TUIO or proprietary events)

The host app scheduler ask the WPF app for a capture/bitmap every xx ms (xx < 50-60ms usually) and adds this bitmap as an OpenGL texture (glTexImage2D) to render the simulation window.

The current way the WPF renders its bitmap relies on RenderTargetBitmap. The rendering time is about 500ms which is at least 10 times slower than we would like it to be and consumes too much CPU (WPF uses the software pipeline in this case).

So, my questions would be :

  • Is there a way to render the bitmap of a WPF window much faster while keeping all its features (transparency for instance) ? I'm aware of the gdi32 API but it does not seem to support things like transparency and I don't know if we can gain any performance

  • The current architecture does not look like an optimal choice as two "rendering" are performed (the rendering of the WPF app itself and the rendering of its bitmap). Would it be possible WPF to render once in some virtual memory space which could be directly read by the Main/hosting app ?

Thanks to anyone willing to share thoughts on this matter :)

Fabrice Aupert