Re: QUARTZ: Patch 1 - Fix video rendering sizing/positioning bugs

[Alexandre Julliard]

a_villacis(a)palosanto.com writes:
> +        case WM_SIZE:
> +            TRACE("WM_SIZE %d %d\n", LOWORD(lParam), HIWORD(lParam));
> +            SetWindowPos(hwnd, NULL, pVideoRenderer->WindowPos.left, pVideoRenderer->WindowPos.top, LOWORD(lParam), HIWORD(lParam), SWP_NOZORDER);

Why do you want to resize a window that has just been resized?

-- 
Alexandre Julliard
julliard(a)winehq.org

QUARTZ: Patch 1 - Fix video rendering sizing/positioning bugs (try 2)

[Alex Villací­s Lasso]

Alexandre Julliard escribió:
> a_villacis(a)palosanto.com writes:
> > +        case WM_SIZE:
> > +            TRACE("WM_SIZE %d %d\n", LOWORD(lParam), HIWORD(lParam));
> > +            SetWindowPos(hwnd, NULL, pVideoRenderer->WindowPos.left, pVideoRenderer->WindowPos.top, LOWORD(lParam), HIWORD(lParam), SWP_NOZORDER);
>
> Why do you want to resize a window that has just been resized?

You are right. The extra SetWindowPos() is unnecessary and a result of 
copy/paste from WM_SIZING. Here is a new patch without the extra call.

BTW, please ignore for now the second patch that moves the blitting to 
the message loop. There is another bug in quartz that freezes playback 
after a few frames with certain AVI files. I am trying to chase it down 
right now. The bug report is at bug #8740 in bugzilla. The first patch 
has no effect on this bug, but the second one makes it harder for me to 
search for the root cause of the problem.
----------------------------------------

This patch is one that I should send anyway, before even thinking of
reimplementing video rendering in quartz.dll with DirectDraw.

Current video sink has bugs relating to window sizing and position.
One of the causes of this is that the windowproc does not handle the
WM_SIZE message, and there are cases where WM_SIZE is sent without any
WM_SIZING message (for example, when creating the window in the first
place). This leads to the video frame not being resized to the window
size in my test program (which resizes the frame correctly with native
quartz).

Another cause of problems is the code in VideoRenderer_SendSampleData
that comes after the comment:
/* Compute the size of the whole window so the client area size matches
video one */

This code moves around the window and resizes it, ignoring the values
specified in This->WindowPos, and then updates This->WindowPos with new
values. The net effect of this is that (in my test program) the frame
is not centered in the control canvas, as it should be, but instead it is
left-aligned. The rendering code has no business overriding size or position
of WindowPos outside the getter/setter methods. The fix is to SetWindowPos()
based on WindowPos, without modifying it.

One problem uncovered by this patch is that (at least on my computer) the
StretchDIBits() function causes the final frame to have a corruption in the
form of "tiles" formed by vertical and horizontal lines of corrupted pixels
whenever the destination rectangle is smaller than the frame size. I don't
yet know what is causing this corruption, since the shrinking code in
winex11drv seems to be correct. You can use my test program and any .AVI file
to verify this. This problem is independent of pixel bit depth, but the
spacing of the "tiles" is dependent of the size of the destination frame.

Changelog:
* Handle WM_SIZE in order to update blitting size in all cases
* Do not override WindowPos in rendering code



-- 
perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'