Opened 14 years ago

Closed 13 years ago

#1432 closed defect (fixed)

Window redraw problem -- current svn

Reported by: gkruse@… Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description (last modified by Nigel)

After the mythui changes went in, mythfrontend no longer will redraw on mac os x. The main window loads and remains blank. If you "scrub" over the myth window using another window it will redraw.

Change History (7)

comment:1 Changed 14 years ago by Nigel

Description: modified (diff)
Version: head

The problem Geoffrey mentions is from the QtPainter? code (i.e. mythfrontend -O UseOpenGLPainter=0). I suspect that we just need to setWFlags() to a different repaint strategy, but I am at a loss to explain why it has changed since we started using libmythui. Sadly, I don't have time to investigate very much.
There is also a different problem I see with UseOpenGLPainter=1. The transitions work beautifully on my 1.3GHz G4, but some of them don't render at all. e.g. selecting Setup fades nicely to the 6 displayed sub-items, but selecting General displays nothing. We are in General, and Escape gets me back to being able to scroll through those items. Very strange. But that probably is a case for another Trac ticket!

comment:2 Changed 14 years ago by Nigel

With more recent SVN, both problems are still manifest. Tried all the window flags I could find, QtPainter still never paints or repaints unless forced. Reverting to [9155] goes back to working state (i.e. no need to drag another window over it to repaint), so I will have to investigate this file by file.

comment:3 Changed 14 years ago by awk@…

Changing the inheritance for MythMainWindow? to inherit from the base QWidget instead of QGLWidget and also removing the call to setAutoBufferSwap (a protected QGLWidget method) fixes the problem for the standard QtPainter? but also breaks (severely) the OpenGLPainter.

My suspicion is that mixing/matching GLWidgets and 'standard' widgets in a Mac OS X window is not feasible - there are some real tricky OpenGL and window buffering problems if you try this.

If the plan is to transition to OpenGL fully then this may be a non-problem once the other problem with submenus Nigel mentions is resolved.

comment:4 Changed 13 years ago by Nigel

I still don't have a solution for this. Googling reveals "It is now possible to open a QPainter on a QGLWidget as if it were a normal QWidget." But they are talking about Qt 4.1 or later. It is possible that there are bugs in earlier versions, but I am not confident enough about the problem to ask the TrollTech? guys.
I have looked at qgl.cpp in the Qt source to see if there is anything that QGLWidget overrides from the parent QWidget class that could cause buffering or clipping problems on the Mac, but nothing jumps out at me.
I am basically stumped. The only thing I have left to try is pasting random methods from qwidget.cpp into mythmainwindow.cpp to see if any of those fixes it.

comment:5 Changed 13 years ago by Nigel

(In [10545]) Add the ability to patch the myth source code. Includes a nasty patch for the window refresh problem. See #1432

comment:6 Changed 13 years ago by Nigel

(In [10545]) Add the ability to patch the myth source code. Includes a nasty patch for the window refresh problem. See #1432

comment:7 Changed 13 years ago by Isaac Richards

Resolution: fixed
Status: newclosed

(In [10552]) Make the opengl part of mythui compile-time optional (is turned on for X11 only now).

Involves nasty cheating to workaround moc not doing ifdefs.

Might want to do a distclean, but it worked for me without it. Apologies if I break the osx-packager.pl script.

Fixes #1432 and #1946.

Note: See TracTickets for help on using tickets.