I can't figure why there should be coordinate translations on a StretchBlt, in theory it should just stretch the surface from a to b. This is way more complicated than it should be.
Are you referring to how software filter works?... because only that filter uses coordinate translation before calling StretchBlt.
That translation is also applying offset if e.g. image is centered on larger screen. Since same coordinate conversion was used in few places in the engine (also in mouse routines) I decided to pick these conversions out into translation class.
...As for why this conversion is performed on every function call - that is an interesting question... That code is rather old, I wrote it when implementing free display modes. Back then I did not understand everything there well, so I was experimenting, moving functionality between renderer and filter classes, and could leave something silly there by mistake...
All this depends on whether that function may receive differently sized bitmaps and different coordinates in arguments. If they are always guaranteed to be of same size and position, then it is better to use precalculated rectangles instead.
Try commenting OnSetNativeSize() and see the result, it should look right (check also what happens on fadescreen).
But I can confirm that not calling OnSetNativeSize() makes the issue go away. Cannot understand why yet though.EDIT: Ummmm.... actually.... it "works" because when you comment OnSetNativeSize out, Direct3D fails to initialize, and one of the other renderers initializes instead (OpenGL has priority in the latest build), which do not have same problem.
OnSetNativeSize sets _srcRect variable which is important for successful work of a renderer.
UPD: There is either something wrong with direct3ddevice->StretchRect call, or the complex issue which depends on several effects.
For example, if I make it always stretch to same native size (1:1) then it draws it correctly with no pixels missing.
The fraction of "lost" pixel also varies. If stretching is 1:2, then mistake equals to half of pixel, if it is 1:3 and higher, then it's more (until only a tiny part of pixel remains).
