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 <j...@dishaw.org> 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
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to