On 2015-06-11 12:20-0400 Jim Dishaw wrote: > >> On Jun 11, 2015, at 11:42 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> >> wrote: >> >> On 2015-06-10 21:44-0400 Jim Dishaw wrote: >> >>> [...]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. >> >> To Jim and Aaron: >> >> I didn't completely understand what Jim said above at first, and that >> motivated me to look up (via google searches) what Windows subsystems >> supported the important alpha blending and native (linear) gradient >> capabilities. It appears from what I skimmed that both GDI+ and >> Direct2D support those capabilities which is also consistent with what >> Jim said above. >> >> @Jim: could you please confirm I now have the correct overview? > > The GDI API only supports a limited gradient fill capability. Essentially it > can do gradients with a vertical or horizontal orientation. > > GDI+ supports horizontal, vertical, and diagonal gradient fills. It can also > do a “path gradient,” which is a closed shape with a gradient that changes > from an interior point to the edges. > > GDI has the ability to alpha blend a bitmap. Thus, to implement alpha > blending in GDI, the driver would need to draw to a bitmap, apply the alpha > blending (possibly sectioning the bitmap if the alpha value is not constant > over the bitmap), and blit the bitmap(s) to the window. Not a difficult > change, but how important is it to add? > > GDI+ and direct2d has alpha blending brushes and the ability to specify alpha > value in colors. > >> >> If that overview is correct, I am hoping we will end up with a driver >> that supports alpha blending and native gradient via the >> GDI/GDI+/Direct2D API's (only available for newer Windows platforms) >> and possibly (if Aaron decides to work on it) also for the >> GDI/GDI+/Uniscribe API's (available for a wider range of Windows >> platforms than GDI/GDI+/Direct2D). In the former case it does make >> sense to go with Direct2D support of alpha blending and gradient fills >> if there are some advantages to that API over the corresponding GDI+ >> API. Of course, if/when the GDI/GDI+/Uniscribe approach is >> implemented, it will need to use the GDI+ API to support alpha >> blending and native gradients for the driver, but I am fine with that >> from the overview perspective. > >> From what I can tell, Direct2D is much faster than GDI+ and easier to work >> with. > > It sounds like there will be three drivers > > wingdi: GDI only (and possibly an alpha blending capability) with ASCII and > UNICODE (if available) text rendering > wingdi+: GDI+ (includes alpha blending, maybe native gradients) with UNICODE > text rendering > wind2d: Direct2D (includes alpha blending, native gradients) with UNICODE > text rendering > > Fortunately, I think the three drivers will be able to share some code.
Hi Jim: Thanks for your responses above to my questions and comments. PLplot implements linear gradients at any angle, but from what you said it appears GDI+ does not have linear gradient capability at anything other than 0 deg and 90 deg. Therefore, it sounds like we will be forced to use the PLplot core software fallback for gradients for both the wingdi and wingdi+ device drivers. That's an acceptable limitation (for example, we use that fallback for -dev xwin) although the core software fallback gradient result typically looks pretty bad because of aliasing issues. Also note there is a choice whether to organize wingdi, wingdi+, and wind2d as separate, single-device, device drivers or as separate devices for a single device driver. That latter choice might make it a little more convenient to share code between those devices. I emphasize what approach you take for these three devices is completely your choice, but I thought I should at least point out that you do have that choice. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
