Hi Jim, Alan et al Some (rather late) input into all this. GDI is the oldest windows rendering API in use. Its major disadvantage is that it does not support antialiasing so the out put is not very good, however it does support hardware acceleration. GDI+ was the successor. It gives you antialiasing but does not support hardware acceleration. Direct2D is I think a split off from DirectX. if I am not mistaken then a significant portion of that functionality is available within DirectX9 which was probably available on XP, but I am now pushing the limits of my knowledge. DirectX (and by extension Direct2D) supports hardware acceleration. I think antialiasing is supported in Direct2D, but not in older versions of DirectX. I know most of this stuff because on Windows wxWidgets uses GDI for its wxPaintDC, but GDI+ for its wxGraphicsContext - which was the difference between the wxDC and wxGraphicsContext backends of PLPlot. I've never used either directly. I have used DirectX9 once (actually by mistake, I should really have used a more modern version). If you want to go down this route you need to get your head around the COM model - which is basically object oriented C. If you are interested let me know (this model might be useful for PLPlot memory management). I then used a bit of Direct2D, which was neither easier nor harder than DirectX and there are come crossover functions needed I think so you end up learning both. I actually started writing a wxDirect2DFrame class that allowed rendering to a wxWindow with Direct2D, but once I got it good enough for that project I never finished it off.
Regarding text, uniscribe has as noted earlier been superseded by directText, but I don't know how far back such compatibility goes. I do have some code that I once wrote intending to push into PLplot (but again never finished) that took uniscribe as a layout engine and then used FreeType for the actual glyph rendering. It should be noted that we are a little unfair to FreeType. FreeType is not a layout engine it is a rendering engine - it just renders the glyphs it is told to from the font files you tell it. The layout engine needs to do things like decide text direction. My concept was that if we had the Uniscribe layout engine on Windows and Harfbuzz on Linux then Freetype could do the rendering on both to give the same style. Anyway if that code is any good to you then let me know and I'll send it over. In terms of what we "should" do. I agree that we probably should still support XP. However, that is probably like us trying to support Ubuntu 5. Maybe a more modern system would be more beneficial in the long run. Perhaps we could leave the wingcc for legacy use, but develop using Direct2D for the new system (call it wind2d or something) rather than deliberately choosing to use a system that is becoming depreciated. Phil Phil On 14 May 2015 at 21:35, <hexa...@comcast.net> wrote: > Alan, > > That makes sense to me. I can see how the configure/build time checks make > sense to affect which support to attempt compile-in. E.g. if one were > building with an older compiler on an XP host, you wouldn't want to try to > link in Direct2D support. OTOH, what I actually had in mind was runtime > detection to use the most effective version available on the target > platform. > > Thanks, > > Aaron. > > > Sent from XFINITY Connect Mobile App > -----Original Message----- > > From: ir...@beluga.phys.uvic.ca > To: hexa...@comcast.net,j...@dishaw.org > Cc: Plplot-devel@lists.sourceforge.net > Sent: 2015-05-14 15:00:20 GMT > Subject: RE: [Plplot-devel] Using Window's raw API for shapes and text > > On 2015-05-14 15:51-0000 hexa...@comcast.net wrote: > >> Alan, >> >> One potential downside of the newer Direct2D/DirectWrite APIs is that they >> aren't supported on Windows XP. I know I have users of my >> application still using XP. I can't tell without some more research, but I >> think Windows 10 even supports GDI/GDI+. >> > > Hi Aaron: > > Since Windows XP is an important requirement for you, then it appears > (again from my rather superficial google searching) that to render > unicode text with raw Windows API you must use GDI in combination with > the predecessor to DirectWrite which is Uniscribe > . > > Jim's later post in this thread said he would start with GDI so I > expect once he replaces the plfreetype approach for rendering unicode > text with raw Windows API for doing the same task he will be moving to > GDI/Uniscribe (if his reference to "GDI" did not actually > already mean GDI/Uniscribe). And I am pretty sure from my reading that > GDI/Uniscribe is supported for Windows XP and all later Microsoft > versions. > >> If the case for using Direct2D/DirectWrite is compelling enough, maybe >> they could be supported in addition to GDI and only used if the >> detected OS is > WinXP? > > I think this is a good idea once it is confirmed that the GDI/Uniscribe > approach works fine. From my reading the advantages of > Direct2D/DirectWrite are considerable (e.g., vector graphics rather > than bitmapped). And it should be straightforward to provide > CMake code to test whether Direct2D/DirectWrite is available, and > if so, provide the user the option to use Direct2D/DirectWrite > rather than GDI/Uniscribe. > > But with regard to Jim's enhanced version of drivers/wingcc.c it > it seems to me the implementation order should be > > 1. GDI/plfreetype. This approach will give the wrong glyph > order for the Arabic, Hebrew, and Hindi "peace" words > in example 24 and may have trouble finding the appropriate > fonts for all those languages, i.e., certain glyphs will > be missing. > > 2. GDI/Uniscribe (i.e., completely replace the use of the plfreetype > API with Uniscribe API). Once implemented, the GDI/Uniscribe > combination should be tested by running example 24 and confirming that > it produces correct results (i.e., all Peace words present and having > the correct glyph order (i.e., as demonstrated at > . > > 3. Add the additional possibility (depending on a macro set by the > CMake logic referred to above) of using the Direct2D/DirectWrite API > instead of the GDI/Uniscribe API. (Again with a check that example 24 > works properly.) > > Note, we want to get rid of all use of plfreetype so if Jim's > reference to his driver already using GDI actually referred to > GDI/Uniscribe, then he should ignore 1 and start with the example 24 > test recommended in 2. above. > > 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 > __________________________ > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel > ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
