0

I have been banging my head against this problem for weeks, so I thought it was time to look for some outside help :-)

I have a WPF application with a main window that includes a whole bunch of controls that use binding. One of the controls is a SharpGL control, which I mention because it may be relevant.

The bindings all work on my laptop, and on other high spec machines, but don't work reliably (or sometimes at all) on lower-spec machines (my laptop is a hyperthreaded quad, one of the failing test machines is dual core). If I increase the frame rate of the SharpGL control on my laptop, the bindings will stop working. Equally, if I slow it down enough they start to work on the dual core machine (but the SharpGL control is too slow to be usable for what I need).

The last thing that may be worth noting is that I can make the problem go away by handling the PropertyChanged event and manually updating the bindings, but that then I'm not doing binding anymore and it is horrible!

So I guess I really have several questions:

1) Has anyone seen an issue like this before? Any thoughts on how to solve it? Could it be directly related to the presence of the SharGL control? 2) Is it possible for a control (in this case the SharpGL control) to fail in such a way that it somehow stops the bindings from updating on all of the other elements? 3) Is it possible for the Draw event raised by the SharpGL control, and handled in my code, to load the UI thread enough that there is simply not enough time available for the binding updates to occur?

Thanks in advance

Mike Nash

Mike Nash
  • 1
  • 1
  • 1
    did you try removing the SharpGL control and testing to verify if it is actually that control that is causing the issue? – czuroski May 07 '15 at 12:53
  • Someone reported a potentially related issue here: http://stackoverflow.com/questions/22209166/opengl-more-vertices-slower-performance/22209363#22209363 . – goobering May 07 '15 at 13:10
  • Thanks for the quick replies. I'm already using vertex buffers, so I don't think that the issue is related to how I've written the SharpGL code. I can probably improve the performance of the OpenGL drawing handler a little more, but that just feels like postponing the inevitable (i.e. as I add more stuff, the problem will reappear). – Mike Nash May 07 '15 at 13:56
  • If I remove the SharpGL control then yes, the problem goes away, but equally so does most of the high-speed overhead on the UI - the control is calling the drawing handler at around 20fps. So, having gotten rid of both the drawing code and the control, I can't be sure whether the issue is load or simply a bug in OpenGL. – Mike Nash May 07 '15 at 13:57

1 Answers1

0

I was having a similar problem once but not with sharpGL it was with a custom class of colors I made that once in a while the bindings would stop working if another action related to the binding was issued.. I solved it by using triggers instead of direct binding... not sure if it would help in your case...

Dark Templar
  • 1,130
  • 8
  • 10