openGL and multitouch


#1

Hmmm … I just enabled the openGL renderer in a touchscreen environment (win8) and the touches drop out.

The *real mouse still works, but all touch events are ignored. If I use standard windows graphics rendering, touches are fine.

Can’t imagine why that would be. Jules?


#2

Might need some custom handling to forward the events - GL uses a special HWND to hold the GL surface, and presumably it’s getting in the way of the touch events… The window’s created in OpenGLContext::NativeContext::createNativeWindow


#3

Gave this a shot but couldn’t get to the bottom of it.

I’ sure you are right though, that touch events are getting caught by the openGL component and not forwarded.

I see where that window is created, but couldn’t figure out a way to set the HWND to forward those events (there are some specific ways you have to set this up when using openGL ES on Android, but I didn’t see anything for windows).


#4

I’ll be getting a MS surface in a couple of weeks, so will probably sort this out then… Can’t really do much in the meantime!


#5

Yeah that’s what I figured.

Really, I"ve been impressed at how fast the graphics are rendering on Windows now, they’re getting better.
Still prefer the mac, but glad windows makes me want to drive toothpicks through my eyeballs a little less that it used to. :mrgreen:

Can’t wait to compare to the speeds with openGL active again.


#6

hi jules .

I met the same situation except that my environment is Win7 device with a touch screen.

Through debugging , I found that createNativeWindow use a dummyComponent instead of the component translated to it as argument . This make GL component peer use the dummy component to check touch events whether hit the itself . Of cause touch events are ignored because of the wrong component .

Then I used argument instead of dummyComponent in createNativeWindow , touch events worked . Is there any risk ? Why using dummyComponent ?
Can I make this change to our product ?

By the way , our company has paid for JUCE.

You can find createNativeWindow function below .

Before :

    void createNativeWindow (Component& component)
    {
        Component* topComp = component.getTopLevelComponent();
        nativeWindow = createNonRepaintingEmbeddedWindowsPeer (&dummyComponent, topComp->getWindowHandle());
        updateWindowPosition (topComp->getLocalArea (&component, component.getLocalBounds()));
        nativeWindow->setVisible (true);
        dc = GetDC ((HWND) nativeWindow->getNativeHandle());
    }

Change to :


    void createNativeWindow (Component& component)
    {
        Component* topComp = component.getTopLevelComponent();
        nativeWindow = createNonRepaintingEmbeddedWindowsPeer (&component, topComp->getWindowHandle());
        updateWindowPosition (topComp->getLocalArea (&component, component.getLocalBounds()));
        nativeWindow->setVisible (true);
        dc = GetDC ((HWND) nativeWindow->getNativeHandle());
    }

Thanks !


#7

Hmm. The dummy component is used because otherwise it wouldn’t be possible to have a top-level window that is itself an OpenGL component - only child components could be used like that.

I’d suggest that if your hack works, then use it as a temporary fix. I’m going to need to fix this exact issue properly for a side-project of my own anyway very soon, so it’ll definitely get sorted out!


#8

In my case , the only OpenGL component is on the top , and I use popups window instead of child components to show on the top of it if they are necessary. So it 's working by now .

I do treat this change as a temporary fix , and will update when you fix it.

Thanks a lot .


#9

Thanks Jules, for getting all the openGL multitouch stuff sorted out. It is functional now, however …

I’ve enabled openGL rendering a few times lately on my windows machine, and it is dramatically slower than the native renderer. Not sure what’s going on there. On mac, openGL is much faster of course.

Anyone else been comparing on Win8? Could this be something to do with the multitouch system?


#10

[quote=“aaronleese”]Thanks Jules, for getting all the openGL multitouch stuff sorted out. It is functional now, however …

I’ve enabled openGL rendering a few times lately on my windows machine, and it is dramatically slower than the native renderer. Not sure what’s going on there. On mac, openGL is much faster of course.

Anyone else been comparing on Win8? Could this be something to do with the multitouch system?[/quote]

There seems to be a lot of variation on Windows - on my win8 machine the GL renderer’s faster. But the multitouch system’s not going to make any difference to GL - the two things are unconnected.


#11

Haven’t tinkers with this very much, but realized that it is actually pinting fairly quickly still, but slowing down all the mouse interactions.

My guess is just that since the PC I’m on doesn’t have much video memory, setting it to use GL ends up trying to paint faster. Perhaps the native renderer is smart enough to slow down the painting when resources get slim, and openGL tries to just power through.

not really sure, but an ongoing thing to look at I suppose.