[mythtv] PPC and OsX quartz renderer

[Nigel Pearson]

> I used opengl a long time until 0.22 (if I remember correctly), now there
> is a shift of -1,-1 of the video picture which leaves permanent lines on
> right and bottom corner. Very nasty.

Annoying, but probably easily fixed,
with something like the following (untested):


VideoOutputOpenGL::MoveResize()
{
    QMutexLocker locker(&gl_context_lock);
#ifdef Q_WS_MACX
    // Apple OpenGL is offset vert/hor by one pixel, so...
    display_video_rect.moveLeft(1);
    display_video_rect.moveTop(1)
#endif
    VideoOutput::MoveResize();
}


> Also the output window does not
> properly ineract with osx window manager: on "apple+tab" the input focus
> changes to the next application but the opengl output stays on top.

Yes, I'm still thinking about that one, along with the Apple-Q probs.



Another OpenGL problem: if the window has decorations
(i.e. the buttons and title), that is not taken into
account in the rendered overlay's offset.



> Also the current quarts renderer
> implementation doubles some code to calculate the desired dimensions. I
> guess this is because the Quartz renderer offers the functionality to use
> a resizeable window or even render inside a dockbar icon.

Yes. Some duplicated code was moved into the
base classes a while back (changeset 19417),
but because of the multiple output streams,
there is some duplication.



> I never tried
> that feature and I don't know if that worked at any time ...

The icon doesn't animate on recent OSes, but apart from
that and some breakage late 2008, they have all worked
since Jeremiah write that tricky code (October 2004).


Set your window to something like 800x600 and set
"Use GUI size for TV playback" and "Use Window Border"
(or German equivalents) in Appearance,
turn on the other three output widgets in TV Playback,
and experiment!



> since mythtv
> is a "fullscreen application", isn't it?

On dedicated Linux machines, usually.
On Mac OS or Windows, not so much.


I wanted to keep those other widgets around if possible.
Plus, I wanted to eventually add similar multiple streams
to Linux for those PC cases that have little touchscreens,
and for output to FireWire devices (e.g. cameras, DVD rec.)





> So my patch makes use of the calculations from VideoOutWindow (and breaks
> the scaleable window for sure). The 2nd patch "hooks"
> ToggleAspectOverride() that makes W-key and any video aspect changes
> going. I am not sure if that is thread safe.


The W key is by default mapped to TOGGLEFILL,
and thus calls ToggleAdjustFill().

Cntl+W (or Apple+W on Mac OS X),
is the one that calls TOGGLEASPECT,
which calls ToggleAspectOverride().

I have never used this forced aspect feature,
so have not missed it, but part2 looks gut.,
so I just applied it to trunk, and will try
to backport to 23-fixes tonight, Christoph.





It is the original patch, or the later part1,
that I am still wrestling with, though.
It breaks W (ToggleAdjustFill() zoom modes) for me.



Mostly, the patch scales all four output rects from
windows[0].GetDisplayVideoRect(), which is a problem
when they are all possibly different shapes and res.

What I don't understand is why it fixes the embedded
widget's location and size, because for several months,
the window ordering has obscured the guide behind the
paused (recordings) or still playing (Live TV) output,
for me.





> Also I am wondering why an aspect change doesn't pass
> VideoOutputQuartz::VideoAspectRatioChanged() !!!!

I think that is only called when the video stream data
changes aspect. Depending on your TV network provider,
that might never happen!

--
Nigel Pearson, nigel at ind.tansu.com.au| All science is       |
Telstra Net. Eng., Sydney, Australia | either Physics       |
Office: 9202 3900    Fax:  9212 6348 | or stamp collecting! |
Mobile: 0408 664435  Home: 9792 6998 |    - Rutherford      |