The recent addition to struct wingcc_dev:
PLGraphicsIn gin;
Serves no purpose (other than to break backwards compatibility)
and shouldn't be propagated. It was only thrown in there because xwin.c has
something similar.
I would like to try wingdi.c but dont have a baseline file to run a patch
against; if you could shoot me the full file (wingdi.c) I could try it.
The cursor coordinate transformations need a ScreenToClient adjustment, I
think this works:
GetClientRect(cursorwnd, &rcClient);
ScreenToClient(cursorwnd, (LPPOINT)&Message.pt);
gin->pX = Message.pt.x;
gin->pY = (rcClient.bottom - rcClient.top) - Message.pt.y;
gin->dX = (PLFLT) gin->pX/ (PLFLT) (rcClient.right - rcClient.left - 1);
gin->dY = (PLFLT) gin->pY/ (PLFLT) (rcClient.bottom - rcClient.top - 1);
When the window is created, it really has no business becoming the
foreground;
We would like to see it, though:
//
ShowWindow( dev->hwnd, SW_SHOWDEFAULT );
BringWindowToTop( dev->hwnd );
I think, instead of buying into UNICODE/TCHAR ansii, just convert to
unicode where needed and call the W functions. Why keep it complicated.
Also, I think the pointer #ifdef/#endif for 64 bits can just use the
64-bits version now for either compilation.
On Wed, Jun 10, 2015 at 6:44 PM, Jim Dishaw <[email protected]> wrote:
> I have two questions on driver behavior that I’m trying to figure out.
>
> In the new wingdi driver I have implemented text rendering using the GDI
> interface. The current implementation honors the height specified in
> chrht. I have measured the heights both on the screen and when printed via
> wingdi using the windows print function. The heights on the output device
> matches chrht; however, they appear smaller than the other device outputs
> (e.g. ps). Should I scale the fonts up?
>
> When printing, the output matches the content on the screen exactly. If
> the background is black on the screen, it is black on the print version.
> When I compare to the ps driver, it appears the colored background is
> suppressed. Should I do the same when printing from the wingdi driver?
>
> Attached are two patch series for wingdi. The driver is still in an alpha
> state, so I don’t recommend applying to master or any branch that is
> important. There is still some issues with the multiple EOP that will
> require a keypress after a redraw event (e.g. resize, printing). Also, I
> have forced debugging, so there is a fair amount of output on the console.
> Most of the examples appear to render correctly. The driver does not
> support alpha blending or native gradient fills. I’m not sure if it is
> worthwhile to add these features in this driver, particular with a Direct2D
> version on the horizon.
>
> Also this version of the driver is non-unicode to make a lowest common
> denominator driver. I’m going to add unicode support because that appears
> to be the standard used by all the maintained/newer drivers.
>
> Any feedback is greatly appreciated.
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Plplot-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
