I have an opengl window in an activex component that is loaded in internet explorer.
There is NO flickering in the opengl window, the flickering occurs in things like tooltips, menu items and such. Sometimes the shadows of the menu items and tooltips flicker. It even happens on tooltips and menu items in a separate IE window.
If i comment out swap buffers, the flickering stops, but of course there is no display. I am wondering if i might need a different window style?
Has anybody noticed this kind of behaviour? And does anybody have any idea of how to fix it?
As an aside, our QA lead said that she gets the same kind of effect when using shockwave3d, in the demos when she switches to opengl rendering she gets the flicker, but when using dx it goes away.
Problem showed on winxp, NVIDIA GeForce4 MX440, and S3 Graphics Super Savage [IXC 1179]
[This message has been edited by bumby (edited 12-03-2003).]
Opengl and GDI arent always friends, but it mostly depends on the driver… the flickering is from that the drivers swaproutine doenst take in account overlapping windows ( at lease i think so)…
I thought it might be a driver issue…s3 is not very good.
I was able to correct the flicker by reducing the Hardware Acceleration in the display control panel to the setting that says “disable all but basic accelerators”
No, with this you shut off hardware OpenGL and the Microsoft software OpenGL uses its own routines to swap buffers, which is noticed by the other 2D GDI tooltip stuff.
Tooltips need to be taken away and redrawn on swap buffers otherwise they wouldn’t know how to refresh the background.
To make things worse, this is not working correctly with these fancy, time consuming, resource eating, pseudo shiny transparency and shadows things (I love it ).
The main problem is that GDI knows nothing about back buffers. So if an OpenGL renders something in the backbuffer, swaps and a tooltip needs to be redrawn on top of it, shadows and transparency stuff will regenerate with the frontbuffer contents the tooltip has saved away before. But these are at least one frame old.
It’s an OS problem, there’s even a WinXP tooltip bug which ruins the contents of the tooltips when OpenGL is running. Look here: http://support.microsoft.com/default.aspx?scid=kb;en-us;814135 <add conspiracy theory here>
[This message has been edited by Relic (edited 12-04-2003).]
I know its some time ago, but we are experiencing something of this problem or at least that’s what it seems. What is happening is, if tooltips are on then the OpenGL graphics flash and are effectively unusable. Reducing the Hardware Acceleration, even in the registry, is no solution as you pointed out.
Am I correct in understanding what you are suggesting is “Tooltips need to be taken away and redrawn on swap buffers”?
Or is there some other solution? Strange thing is in our software implementation the problem is only apparent on some systems, typically Compaq EVO and some Dell. I think the common factor between the effected systems is they are gennerally lower cost with integrated graphics on the MOBO.
Yeah, it seemed to mainly happen on onboard chips, flicker on the nvidia mx card was solved by updating a driver…funny enough, i think i actually went back to an older version of the driver…30.82 i think. Unfortunately i didnt have access to the other systems that had the problem, so am not sure if a driver update would fix those.
I’ve tried combinations of drivers old ones new ones and borrowed ones (I’m being funny now). In this case the systems use Intel but I guess it has for sure has cropped up elsewhere on budget systems. Basically the site has a tonne of systems and this problem is prevelant on all the systems that have these characteristics. We’ve tried all the tooltip fix (workaround) tips, shadowing on cursor etc. but none of these seem to work. Before heading into programming in a fix, I’d like to know a bit more about the problem to try and ensure that other problems do not arise as a result of fixing it.
You can’t use tooltips with shadows or fancy blending effects on top of double buffered HW accelerated animated(!) OpenGL windows, because the repaint function of the tooltips stores the wrong contents (the image at the time it pops up) which don’t fit the part animated around it when it finally restores itself.
This is because it doesn’t know of back (or right!) color buffers and doesn’t send a repaint to the OpenGL window for this region but tries to repair itself and fails miserably.
Standard windows don’t have this problem, because they send repaint messages. You could use those instead.
You cannot use tooltips on animated OpenGL windows and expect them to not flicker and repaint correctly. Period.
I wouldn’t expect an OS fix from a vendor pushing their own 3D API.
Depending on the 2D driver’s supported capabilities (backing store for tooltips) some implementations have flickering tooltips, some will not repaint the animated background correctly as I explained. You’re stuck on an OS caveat with tooltips.
You could program your own tooltip windows class which sends standard repaint messages to the underlying windows when it’s removed.
