GlovePie replacement ?

[CyberVillain]

No they will not... You can choose between a few different and WPF will still be among those you can use for developing Metro apps

[bobv5]

I have to ask, what is it programmer guys like so much about .net? I do a little programming, but it's all C on bare metal. The idea of running what look like native apps, in a virtual machine, just seems insane. From a hardware guys perspective .net is an absolute nightmare. (I admit I am very biased, in the recoil simulator I am working on, I am using a 16bit, 16 Mhz microcontroller, and it seems stupidly, excessivly, powerfull. I'm also hoping to do at least a little bit of the code in assembly language. Perhaps I am just masochistic?)

Is it even possible to write windows GUI apps in pure C or C++?

PS, sorry for going off topic a little, but it didn't seem worth starting a new thread.

[brantlew]

You are right. When you're programming close to the metal there's nothing better than good ol' C because you can control exactly what is going on and typically the scope of the project is such that you can keep it all in your head at once.

But once the application reaches a certain level of complexity it becomes difficult to keep all the pieces in your head and bugs start creeping in. This is especially true once you start getting into big multi-threaded apps and event driven GUI applications.

The biggest reasons I like run-time sandboxes like .NET or Java is because of memory management and graceful exception handling. That's where all your problems in C code stem from and I have spent untold weeks putting in debug statements and writing log files just to catch some incredibly obscure memory race condition in multi-threaded network and data servers. You put all these statements in to try to isolate the bug, wait 2 weeks for it to occur, and then POW! - your server throws a null pointer exception and is gone! That was 15 years ago and I would have loved to have a good managed environment back then.

Another reason I like something like .NET is as a GUI scaffold. You can write GUI's in C but sheer magnitude of code you have to write (without scaffolding) is overwhelming. These big libraries may be big and unwieldy but they save you untold weeks of time reinventing and debugging the wheel.

[bobv5]

Yup, I can understand that. I supose I'm just annoyed that no matter how much hardware I shove in a PC build it always feels a bit slow.

[WiredEarp]

@ bobv5: I love the fact that I can write in either VB.NET OR C# and its basically the same, just a bit of syntax differences (ok, other differences as well, but its very easy to go from one to the other). On top of that, its WAY easier than writing stuff in C++, even with MFC support. You can write guis in straight C/C++ no problem (I think lots of earlier Windows stuff was done just this way), but it seems a waste of time nowadays. If you need super performance, you can just call an optimized routine (that you have written in whatever) from your slow VB.NET program etc. Therefore, I see absolutely no need to write stuff directly anymore to do all the GUI/events etc.

I know what you mean about slow tho, I used to be totally this way from my days programming in DOS. There was a big shift I had to go through, from coding everything myself and caring about every bit of performance, to leveraging other peoples code and getting users to buy better hardware. At the speed PC horsepower is progressing, its often cheaper and more efficient to just upgrade hardware than to optimize once you reach a certain point (if your code is designed badly, no hardware will make it perform/scale well).

Also as Brantlew says, garbage collection and exception handling etc makes life much easier.

[cybereality]

There are also frameworks you can use with C++ that make GUI stuff easier, like Qt or wxWidgets. Its not like you have to do everything from scratch. But yeah, still nowhere near as easy as using the designer with C#.

[CyberVillain]

There are also frameworks you can use with C++ that make GUI stuff easier, like Qt or wxWidgets. Its not like you have to do everything from scratch. But yeah, still nowhere near as easy as using the designer with C#.

No real developer use the designer Bleh its crap.. WPF is so nice the XAML format is almost as nice as xHTML/CSS3....

edit: Lol, performance, its always about performance.. Cpp for normal kind of apps are not faster at all (The kind we are talking about here).. Managed directX (the kind you used in games for managed languages) are about 5-15% slower then its none managed counterpart, so games still have a performance boost using none managed languages. Performance is often not the issue, in my line of work (Working as an architect for enterprise business apps) scalability and maintainability is the real issue, and you just dont get that with C/Cpp. .NET is the way for those apps.. Its the same case for many client apps written in Cpp they would have been as good in .NET probably better...

edit2: Missed brantlew and WiredEarps answers before writing mine.. They pretty much nail why .NET is more scalable and maintainable...

[WiredEarp]

Haven't had the need to use WPF, but the .NET designer isnt _crap_. Its easy to use and you can whip up a Windows app very quickly.
WPF may well be much better (especially for graphical stuff and 'new look' applications) but that doesn't make the old style designer worthless.
What are some good reasons to change? If its going to make things quicker and easier, I might give it a try for my next app...

Well written C++ can be both very scalable, and very maintainable, if designed correctly (I find OOP is great for preserving maintainability for big projects). However, for the vast majority of the stuff people want to write, .NET is way less hassle than those older languages. The slight difference in performance is not usually important, especially when taken against the decreased coding time. No writing header files is one of my fave improvements...

[CyberVillain]

No header files, but you should always decouple with an interface and a IoC pattern (Inversion of Control). (Thus you still need to have your definitions in a separate file, like head files)

Well, your talking about the Win32 API for .NET right (WinForms)? It has the same problem has the Win32 Api for Cpp, its very hard to design flexible and dynamic GUIs. You have to use that crap dock and anchor stuff.... Its so much easier in WPF..

If you want to stack controls that you do not know their individual size you just do

<Stackpanel Orientation="Vertical">
<Control1></Control1>
<Control2></Control2>
<Control3></Control3>
</Stackpanel>

If you resize the window each control will respond correctly automatic.. This was a PAIN in WinForms, so its not just for graphic intense software that you gain advantages changing from WinForms to WPF. Also the databinding is so much nicer in WPF than in Winform. This opens up a entire new world with MVVM (Model View ViewModel)... Theres no data grid included with WPF like in winforms though, so if you are doing a business app you need to buy a third party one (Or use a open source if its a private project)

[WiredEarp]

Sounds interesting, might give it a go next time. Although I think you can do automatic resizing like that with the old style IDE by putting the controls inside a container element. Dock and anchor is definitely a lot better than nothing however (old days you had to resize everything yourself!).

Re the databinding, it sounds like it actually might be worth using. I'm very old school (I predate VB 1.0 with SuperBase4) so I haven't used data aware stuff since I tried it years back and didn't like it (I found those old data bound controls, including datagrid, were shite... but perhaps thats because I always want to change some things about them and have to end up doing stuff to work around how they work by default). Sounds like I should look into WPF for my next project. Is the GUI designer better than the old one or is it basically the same (drag controls from toolbox onto form, double click to edit code etc), or do you have to manually like your code to the controls like you did using dialogs in C++?

Definitely the old designer fell down when it came to dynamic, resizable stuff - which is so much more important nowadays with web apps and devices with different screen sizes and resolutions.

[CyberVillain]

I started coding back in the day (1987) so i know what youre talking about
I wrote an entire wrapper lib for WIN32 to get it more like WPF (I even had XMl defintions for the screens)...

TwoWay binding is the poop (Lol the forum wont let me type ****), if you cant do it with databinding its the controls fault (Mainly third party ones) not Databinding as a pattern.. Have a look into Caliburn micro, its THE framework for MVVM under WPF.

http://caliburnmicro.codeplex.com" onclick="window.open(this.href);return false;

Its convention based, so if you have a Dropdown with name Customers

<Dropdown x:Name="Customers" />

and on your ViewModel you have a property

public IEnumerable<CustomerViewModel> Customers { get; set; }

it will auto magically bind against that. And if you have a property

public CustomerViewModel SelectedCustomer { get; set; }

it will auto magically bind against that if you select an item in the dropdown

If a convention isnt there or you dont like the default ones you can add your own to the bootstrapper of the framework

If you change from datatype IEnumerable<T> to BindableCollection<T> it will even listen to changes both on the collection and properties on the items in the collection, so if you remove an item or change the property that binds to the Text property of the dropdown item it will update the view with zero effort from you..

edit: Forgot to mention the designer, I do not use it myself i like doing my view in xaml instead, but what I heard its lightyears better than the one in winforms.. Still has its drawbacks though...

[WiredEarp]

Sounds very interesting, I guess I'll give it a shot next project I do, just to get some experience with it so I can judge it fully. It does sound like its taking a lot of the donkey work out of things...

[cybereality]

Well, I will certainly want to investigate this further. Sounds like it could be useful stuff to know.

So can you use all this stuff with the Express version of Visual Studio, or do you need to pay?

[CyberVillain]

Caliburn micro is a open source framework so it will work... i work at a company thats gold membership partner with MS which means we all get access to every singel ms program.. very nice

[CyberVillain]

If you guys give me an Ok and that we agree on a name for the Software/Project I can design the basic architecture and create a Github repository. With basic architecture I mean interfaces and core projects and put together the softwares main API, also setup WPF with caliburn micro and give it some basic functionality (Like input/output configuration possibilities etc)...

[cybereality]

Well my original idea for a name was "ioVR", which I guess is my first pick.

A lot of other good stuff is taken. Maybe we could do something with these words:

Open, Scriptable, Programmable, Input, Output, Peripheral, Virtual, Reality, Device, Driver, Interface, Controller.

Also, before we setup a git repo, we should talk more about the general architecture and how it would work. I am very much in favor of a plug-in style architecture, where each device would have its own DLL that could just be dropped into a folder and show up in the program. That way people can add their own devices themselves (possibly proprietary stuff, under NDA, etc.). I assume you can call functions in a DLL from C#. Or is there a better way to handle this?

One last thing, I am currently in the research stages for a DirectX9 3D driver. The first step of this was to just make it output for stereo 3D, but down the line I'd like to add stuff that interfaces with peripherals, for example for real 6DOF headtracking (not mouse emulation) and stuff like that. Do you think we should combine these projects into one, or should they be two different things just highly compatible. Is there a way we can make this peripheral driver have some sort of API that could be hooked into from external programs (like this 3D driver I want to make)?

Also, can we use LuaJIT ( http://luajit.org/luajit.html" onclick="window.open(this.href);return false; )?

[CyberVillain]

A plugin structure is my plan, they do not have to be in a seperate dll though.. the core ones for example will be in the a coreplugin dll... Ill just find all dlls in programfolder/plugins and get all the classes that implements the interface IIOPlugin (Or what we will name it)

I do not now if we wanna add that dx stuff directly? Maybe two programs that communicate using shared memory or something...
About Lua i was thinking about using this one http://luaforge.net/projects/luainterface/" onclick="window.open(this.href);return false;

[bobv5]

Found this site. Maybe somebody wants to try it.

http://acronymcreator.net" onclick="window.open(this.href);return false;

RADICLE ReAlity Device Interface ControlLEr
PADDINg ProgrAmmable Device Driver INterface
bIOnIC Input Output Interface Controller
REDIRECT REality Device InteRfacE ConTroller
INDIRECT INput Device InteRfacE ConTroller
PARTICLE ProgrAmmable RealiTy Interface ControlLEr
PeRVeRtED PRogrammable Virtual REality Driver

[cybereality]

PeRVeRtED PRogrammable Virtual REality Driver

HahahahHAHAHAhAHahah!!!!

[cybereality]

I do not now if we wanna add that dx stuff directly? Maybe two programs that communicate using shared memory or something...

Yeah, it might make sense to keep them separate. Do you think we could find a way to expose a sort of standard gamepad, that developers could support in games. Sort of like the way you can use a Xbox 360 pad for PC games, except we would have a generic VR controller (with some standard set of functionality). That way I can just support this "VR Controller" in my app, and other developers could potentially do the same. The controller would respond with its capabilities, for example it could say if it were 3DOF, 6DOF, 9DOF, etc. how many buttons it has, etc. I guess we would need some more specific ways to handle gestures for something like the Kinect. Not sure the best way to handle that.

[PalmerTech]

Don't know if you already knew about this, or if it is even useful: http://en.wikipedia.org/wiki/VRPN" onclick="window.open(this.href);return false;

From what I understand, it makes it easy to use different VR tracking devices to control the same software.

[Johnny-Mnemonic]

Don't know if you already knew about this, or if it is even useful: http://en.wikipedia.org/wiki/VRPN" onclick="window.open(this.href);return false;
From what I understand, it makes it easy to use different VR tracking devices to control the same software.

Of course it is useful!
It is standard that supported by many tracking systems, OptiTrack, Polhemius and many other supported natively.

One of the great benefits that you can use it via network, so trackers can be connected to one physical computer and you can run game / simulation on the other.

For example, great free-to-use VRPN Server for Kinect:
http://projects.ict.usc.edu/mxr/faast/

[cybereality]

Maybe a stupid question: does this VRPN do everything we need to do here? Are we re-inventing the wheel...

[PalmerTech]

Maybe a stupid question: does this VRPN do everything we need to do here? Are we re-inventing the wheel...

Hah, you tell me! Like Mnemonic says, it is definitely useful (It is what we use at my work, hooked up to a combo Phasespace/Kinect tracking system), but as far as I know, it does not support any commercial games. Perhaps all you have to do is add some kind of abstraction layer between VRPN and a gamepad/keyboard/mouse emulator? Or have it hook into DirectX directly?

[brantlew]

I think it makes a lot of sense to take a GOOD look at VRPN before we push forward with a design choice. I would go so far as to implement one or two devices into VRPN (like the Sparkfun or Vuzix - both of which we have code for) just so that we can speak intelligently about it. Now it may turn out to be too complex and high-concept or even inadequate for our problem - but then again, I'm sure there were several smart people that spent at least a semester or two thinking deeply about this problem and it could be enlightening to understand what they came up with. Because what we have now is not much more than a basic scope understanding and a "napkin-design" and I'm certain that there are dozens of issues that we will encounter that could change our design choices drastically.

[WiredEarp]

CyberReality: Maybe a stupid question: does this VRPN do everything we need to do here? Are we re-inventing the wheel...

Yep, my thoughts exactly (said this way earlier in this thread).

For myself, VRPN does most of what it sounds like we are going to do, and it can be tied together with scripting or code to do what I need. A GUI is useful for many people who don't want to code, but for myself, it doesn't really seem to be necessary.

The only thing I really need GlovePIE for is TrackIR support, so if I could get the code modules to do this (out of Freetrack source maybe?) then I'd just use VRPN and some code to develop my interfaces. With VRPN, you can easily hook it into DirectX, mouse, emulator, etc, just by developing modules to do this and translating the calls from VRPN to the modules.

[brantlew]

A few thoughts on VRPN after digging around for a few minutes:

- It is primarily designed to convert a large number of specific input devices into a smaller set of generic device "types". Client apps (primarily graphics) can then register handlers for one of these generic devices. So for example if your game is written to accept data from a generic VRPN "tracker", you can easily switch out the actual tracker device from Vuzix to TrackIR etc... and the application will not know the difference.

- That's a pretty nice concept and reminds me of how CyBerReality wants to standardize VR API's, but it's really only half the equation as far as we are concerned. What does not seem to be included or designed for is device emulation. Right now it seems that client applications are expected to be written with a VRPN interface. As a result you can't "hook" into existing games and control them via mouse emulation or TrackIR emulation.

- There are some great features that we have not even discussed which are already built into the framework that would be beneficial: things like clock-synchronization, input recording and playback, and (of course) device type generalization.

- There may be baggage left over from the fact that it's a NIX style project. For example its all IP socket based. Nice clean design but more overhead than is strictly necessary. Would need to evaluate performance and design impact.

- Overall I think VRPN offers a good starting point that would help structure and guide the design. However it seems as though we would need to come up with an elegant way to extend it to include device emulation as well as scipting.

[CyberVillain]

A few thoughts on VRPN after digging around for a few minutes:

- It is primarily designed to convert a large number of specific input devices into a smaller set of generic device "types". Client apps (primarily graphics) can then register handlers for one of these generic devices. So for example if your game is written to accept data from a generic VRPN "tracker", you can easily switch out the actual tracker device from Vuzix to TrackIR etc... and the application will not know the difference.

- That's a pretty nice concept and reminds me of how CyBerReality wants to standardize VR API's, but it's really only half the equation as far as we are concerned. What does not seem to be included or designed for is device emulation. Right now it seems that client applications are expected to be written with a VRPN interface. As a result you can't "hook" into existing games and control them via mouse emulation or TrackIR emulation.

- There are some great features that we have not even discussed which are already built into the framework that would be beneficial: things like clock-synchronization, input recording and playback, and (of course) device type generalization.

- There may be baggage left over from the fact that it's a NIX style project. For example its all IP socket based. Nice clean design but more overhead than is strictly necessary. Would need to evaluate performance and design impact.

- Overall I think VRPN offers a good starting point that would help structure and guide the design. However it seems as though we would need to come up with an elegant way to extend it to include device emulation as well as scipting.

Nice finds! It sounds like what whe should do is create a VRPN Input plugin in our software since their goals are not exactly the same. The biggest goal (For me at least) is to get Headtracking and body tracking into games that does not support it...

[WiredEarp]

Since there is VRPN already for most of the major input devices, it sounds like its the OUTPUT devices that need work. IE, we need a good mouse emulation class, a good TrackIR emulation class, etc. An GUI designer could then provide the ability to 'glue' these interfaces together, just like GlovePIE does with its GUI. The only difference, is this one would be leveraging the existing power of VRPN etc.

I was anti the IP socket bit of VRPN at first myself (seems like its just adding hassle for a single PC system) but thinking about it I dont believe it will cause any performance problems or latency, and it provides the useful ability to run everything on different systems as required.

[bobv5]

To get an idea of the latency of using IP system, type this in a command prompt--

ping 127.0.0.1

That will make the computer test how how much latency is on the loopback connection to itself. On mine it is too small to measusre- 0ms. I would guess all machines give a similar number.

I know that is not sending any actual data, but still gives an idea of latency.

I definetly think this should be able to take vrpn inputs, even if it is alongside other inputs, (freetrack, wiimote etc). It seems silly to be going against the work other people have done to standardise this stuff.

[brantlew]

@WiredEarp: Right, the input channels already exist. The output is where the design is lacking.

@bob5: "ping" granularity is far too coarse to judge application latency but yes - local computer IP transmissions are generally very fast in terms of human awareness, but still a couple orders of magnitude slower and more CPU intensive than more direct communication channels. However, those differences only amount to much when we run the channel at something like 60Hz or 120Hz. But even that rate is relatively slow in machine terms so it's unlikely that the IP latency would have any noticeable effect. I think you could certainly prototype and develop using the existing communication model and then (if necessary) change it as a future optimization.



Just to be clear - I'm not whole heartedly on the VRPN band-wagon yet. There is a ton of code and design that we could reuse from that project so I think we should seriously consider a true VRPN extension, but implementation-wise, it may turn out to be a square-peg / round-hole kind of deal. But even if it didn't work out I think we would benefit from understanding and probably incorporating many of their design concepts instead of home-brewing from scratch.

[cybereality]

I think looking at VRPN in more depth (I only browsed the page a bit), and even implementing it as an input, will be important for this project. Certainly they have support for a wide-range of devices I can only dream to afford. However, I don't think it completely solves the problem. First off, a big factor is device emulation, which VRPN doesn't provide. Mouse and keyboard stuff is trivial, but there is probably more complex stuff here (like TrackIR emulation, etc.). Then there is the issue if we want to support different trackers (like Sparksfun IMUs, etc.) and oddball custom stuff people come up with. Basically the type of stuff GlovePIE is good for, but more community driven. So I think there is space for something like this.

However, I feel like this is not exactly the same as the DirectX driver thing I have been talking about (which I was calling ioVR). So I am going to continue to work on that on my own for the time being. It is more of a 3D driver with bonus features like head-tracking, force-feedback, and stuff like that. Maybe after I am further along we can merge the projects somehow. Its just really ambitious, and I don't want to make this GlovePIE replacement project any harder than it needs to be. But I will certainly still be open to contributing, as I feel there will be a lot of overlap.

[CyberVillain]

I think we have to go for an agile approach on this project, to think about every little possible turn that CAN happen we never going to see a software. If we build the main architecture with modularity in mind it will be fine to add features like this later. To me VRPN in nothing more then a input plugin as far as our software is concerned.

[WiredEarp]

Exactly CyberVillain: use VRPN on the input side... on the output side, develop stuff with a modular standard, so that other people can extend it later - then the GUI is the important thing to tie all the pieces together. If its developed right, you could actually let people bind against your input/output side with their own code, OR use the GUI designer. IE, you could just expose methods and functions etc for people to use in their own stuff, or those who don't have coding expertise or the need to 'build it in' to their own software' can use the GUI component.

@ CyberReality: instead of merging projects, if this one is developed right (modular is the way to go IMHO) then you can just call what you need from your system without having to even merge the codebases (you could just call the routines directly).

[brantlew]

I don't think we are trying to bloat the design with features right now. If anything we are doing the opposite - just trying to come up with a set of requirements, a basic design, and structure the project so that we don't do more work than is necessary.

It seems like everybody is in agreement about a modular approach for the raw device I/O functions, but the logical design of the engine - the part that polls and handles device input and sends output has not really been discussed. It is just one big main() loop poller? Do we have one thread per device? How does the script engine fit in? Does it run in it's own thread? How integrated is the GUI into the engine - in other words: can the script engine run without a GUI? Is output synchronous our asynchronous?

And most importantly - do we make all of these fundamental decisions on a brand new engine, or do we use the pre-existing VRPN engine to start with and build off of that? My personal choice would be to evaluate how the VRPN engine could satisfy our requirements. Probably just implementing a simple mouse emulation module for VRPN would illuminate most of the technical issues and tell us whether it was a good or bad choice.

(Microsoft makes mouse emulation easy http://msdn.microsoft.com/en-us/library ... 85%29.aspx)



edit: @Wired and CV: are you proposing we create a separate process that just accepts socket input from VRPN or are you proposing that we extend the VRPN I/O engine to support emulation output as well as socket?

[CyberVillain]

To me right now our software is totally standalone from VRPN we just write a inputplugin which uses the VPRN API (sockets or whatever).. i think we make the engine as a dll that a gui can host (or a windows service or whatever). I think the first version should be really easy, just a lua engine that ties together the plugins with the lua script.. for the first version a single threaded poll system with a main loop is fine (just like glovepie).. if we go to fancy from the start it will never be released, ive seen too much open source go that way, and dont get me started on total conversions for games, when was the last time yoy saw a completed TC :/

If a plugin needs its own thread for polling the comport (sparkfun razor etc) it can create its own thread from a threadpool that the engine supplies... most plugins can probably work singlethreaded though eg when you call Mouse:setDirectX(TrackIR:getYaw()) from script the mouse plugin and trackir plugin will do their thing then and there

[WiredEarp]

I agree with pretty much everything you said, ESPECIALLY the bit about not making it too fancy. lua sounds like a good way to tie it together.

'The perfect is the enemy of the good' is one of my fave lines. Its always better to have something good and working, than something perfect that is never completed...

[CyberVillain]

I agree with pretty much everything you said, ESPECIALLY the bit about not making it too fancy. lua sounds like a good way to tie it together.

'The perfect is the enemy of the good' is one of my fave lines. Its always better to have something good and working, than something perfect that is never completed...

Yeah if its something i've learned after years in this business its just that, another thing is that requirements will always change along the way, so always build your solution with that mind

[brantlew]

Looked over the VRPN code a little bit more. My quick 1 hour evaluation gives me the impression that it's written "ok". Not a work of art, but not a bone-headed mess either. There is some complexity in the form of generic device classes, but not so much that it gets bogged down within layers of a class hierarchies and over-abstraction.

The I/O model is disappointing to me - a lot more simplistic than I had imagined. It pretty much uses a polling/sleep loop at the top with calls into various API's. There may be mult-threaded blocking reads at lower levels, but either I did not follow it deep enough or those reads are buried within vendor API calls. A lot of the valuable code is not in the device polling (which is easy) but in the handling of atypical states like device disconnects, auto-reconnects, and device failure states. That's the type of stuff that nobody implements on the first try and which takes a lot of time and testing to get right.

I know I am in the minority but I'm not very enthusiastic about the pure polling model. For one - it's problematic if you have potentially blocking I/O operations. The polling rate can become highly variable and you may end up missing updates from devices if you cannot sustain a fixed rate. I think I have heard people complain about this on poorly designed mouse look games when the frame rate drops too low. The game starts losing mouse events. The other problem is that it unnecessarily steals the CPU from the game for no reason. Maybe that's a non-issue with quad processors these days but it's generally a poor coding practice. In my opinion this application is a "text-book" case for an interrupt-driven producer/consumer multi-threaded app.

Another observation. As far as I can tell GlovePie is multi-threaded. Not for every device but it definitely spawns threads to handle certain devices - maybe just for blocking I/O. Fire up a few Wiimotes and you can see the thread count increase accordingly.

[WiredEarp]

From a technical and personal point of view, I hate polling, it just seems inefficient, I want the computer to know exactly when i press a key, not when its loop gets around to reading its state. However, I've learnt that what I like, and what works easiest in reality are often different. I avoided polling when I did my sim in DirectX5, but I know lots of games use polling for input. Therefore, it obviously can work well enough. Its good to try and anticipate every problem, but there is a simple way to avoid the problems you have stated - by not having the problem causing issues in the first place (low frame rate, blocking operations, etc). Every FPS issue can be solved with optimization, hardware, and time, and if threads avoid you bringing everything to a halt, its not bad to use them to avoid problems without recoding for the perfect code.

Personally, I'd go with what is (polling) for now, and revisit it later once you have collected some data on the disadvantages of the polling system. I don't think it would be too hard to build a better system, just that its might not be necessary.