Hi guys,
by comparing the "new" equations (http://www.winehq.org/pipermail/wine-devel/2009-December/080391.html) and the old ones (http://source.winehq.org/source/dlls/gdi32/bitblt.c) you'll find the following differences:
eM11: identical eM21: identical eDx: identical
eM12: identical eM22: plg <-> rect swapped eDy: identical
It isn't obvious at the first look, but the only difference is that in eM22 plg and rect are swapped. By taking a bit closer look at ...
http://source.winehq.org/source/dlls/gdi32/bitblt.c#L1040
... and comparing the equations for the X-component (eM11, eM21) and the Y-component (eM12, eM22) you'll notice that this must be right, the current equation violate the symmetry - no need to calculate, you can see that with the naked eye ;)
The correct equation for eM22 should be:
xf.eM22 = (rect[1].x*(plg[2].y - plg[0].y) - rect[2].x*(plg[1].y - plg[0].y) - rect[0].x*(plg[2].y - plg[1].y)) / det;
Could someone please test if this change alone is sufficient to fix the issue? Should be way easier to get that upstream than all the other "no-op" changes.
Regards, Sebastian
Am 16.06.2014 04:07, schrieb Michael Mc Donnell:
Hi Alexander
On Wed, Jun 11, 2014 at 5:36 AM, Alexander Almaleh sashoalm@gmail.com wrote:
I just realized that it would be impossible to write an automated test for PlgBlt now, because Wine has a second, unrelated but, for which I already wrote another email to wine-devel. It's titled "BitBlt doesn't honor the rotation specified by SetWorldTransform". So even with my fixed PlgBlt, Wine's version would still not work correctly, until that second, unrelated bug is fix. That's why I submitted a Windows project where I compare my patched PlgBlt, and Wine's PlgBlt under Windows.
I do not understand how that would stop you from writing an automated test? You can use todo_wine to show how the code is supposed to work. You can then cross compile the test and upload it to the Wine TestBot. The Wine TestBot will run your test on Windows and report back if it is correct. The automated test can then be applied to the wine source tree. Once your patch with the fix is ready you can submit it together with a patch that removes the todo_wine.
Bearing that in mind, what is your advice? Bruno Jesus already wrote that he can confirm my code runs in Windows. Should I just explain how I reached the formula for the XFORM matrix?
I think you will need to be able to explain why the old code is wrong and explain why yours is better. Explaining what the formula is might be a good way to *help* explain it. It is important that your code does not break anything. You have found one example where your code works better but it might break other examples.
I see Nikolay Sivov, the author of the function, has already given you feedback earlier [1]. He will probably be one of the people you need to convince. When he said:
"P.S. I don't see your point on inlining determinant expression."
He probably means you should rewrite your equation to use the determinant, unless you have a very good reason, in which case you need to explain it. I personally think you might be able to fix his code instead of replacing it.
Good luck, Michael
[1] http://www.winehq.org/pipermail/wine-devel/2009-December/080392.html