GDI+ Alternative - C++ Gauge

[Rocky 128]

Frit,I am highly interested in this wrapper API. Even if it makes AGG as slow as GDI+, it may be interesting from a technical perspective, to understand AGG better.Is it downloadable somewhere?Can you tell me where?Thanks,Eric

[martinboehme 493]

thanks for the info.> I have been told by many people over the years the biggest complaint they have with gdi+ screens beside it killing performance big time is the not so accurate movement of say the HSI needles etc.Recently, I wrote a GDI+-based ADI, and I noticed that the ILS needles didn't move quite as smoothly as I thought they should (and not as smoothly as the artifical horizon, for instance). My impression is that there is an additional issue here because the localizer deviation variable can only take on integer values between -127 and 127... and that's coarse enough to (just) be noticeable. I think the same problem could apply to HSIs since it's the same variable.I briefly contemplated writing some code that would take the coordinates of the localizer (accessible as token variables, IIRC) and of the plane and then use those to compute the deviation myself (with arbitrary precision)... but decided it wasn't really worth the hassle...MartinP.S. Great thread by the way, lots of useful info!

[Guest fturner]

>Frit,>>I am highly interested in this wrapper API. Even if it makes>AGG as slow as GDI+, it may be interesting from a technical>perspective, to understand AGG better.>Is it downloadable somewhere?>Can you tell me where?>>Thanks,>Eric>>Here's the link to the web site.http://www.point.com.mk/aggplus/Now it only covers about 70% of the functionality of GDI+.Frit

[Guest fturner]

Ok, lets look at it this way, and you have actually come across one shortfall of GDI+..... from all that I have researched, at the most GDI+ will only give you 0.25 pixel resolution. This means by playing with antialiasing etc, the most that needle is appearing to move is roughly 0.25 pixels. However, most folks say the best you can normally get is 0.50 pixels without some very extensive maths. Now in agg I can go down to 0.001 pixel resolution and even further but for simplicities sake lets stick to that for now.Now lets look at your VOR needle. The integer value can swing from -127 (-10 degrees) to 127 (+10 degrees) when your locked on a VOR. This gives you a resolution of 0.083 degrees per 1 "unit" of that variable.Ok, so in the below coloum I'm going to list the number and when Agg will move the needle and when GDI+ will move the needle. Lets give GDI+ the benefit of the doubt and say it will do 0.25 sub pixel resolution ;).Variable | Degrees | AGG | GDI+-------------------------------------------- 0 0.000 0.000 0.000 1 0.083 0.083 0.000 2 0.166 0.166 0.000 3 0.249 0.249 0.250 4 0.332 0.332 0.250 5 0.415 0.415 0.250 6 0.498 0.498 0.500 7 0.581 0.581 0.500 8 0.664 0.664 0.500 9 0.747 0.747 0.750 10 0.830 0.830 0.750As you can see Agg will attempt to "move" the needle every single time, where as GDI+ is unable to every 3 steps because of its limitations, and thats only IF your getting 0.25 sub pixel resolution. Its kinda of hard thinking sub pixel, but believe me, you will actually notice it.Anyways, hopefully that explains it a bit there ;).Frit

[martinboehme 493]

Thanks for the illustrative example... this assumes that one "unit" of offset translates into one pixel of movement on the ILS needle... which implies a gauge width of around 250 pixels. Since many gauges aren't quite as wide as that, the situation in reality would be even worse... so the limitation isn't the resolution of the ILS offset after all...> Its kinda of hard thinking sub pixel, but believe me, you will actually notice it.Oh absolutely, no question... that's why I'm so eager to try out AGG.Martin

[Guest JeanLuc_]

Bien sur, tu lance une telle perche! :-)You can't go wrong with AAG as compared to GDI+, both in speed and sub-pixel accuracy, except the lack of clipping for commercial applications. There are ways around, but this comes at the expense of additional work.Thank you for your confidence in TDXP Eric. It is not ready for prime time yet, but I'm definitely considering this. TDXP is relatively easy to use because it is designed to be a low level API. The drawing-flow is much like OpenGL:TdxpBegin(...)TdxpLine()TdxpPathNew()TdxpPathAdd(x,y)TdxpPathClose()TdxpDrawPath()TdxpFillPath()etc...TdxpRotationSet(angle, x, y)TdxpPathXXXXXX ()TdxpPathDrawRot()etc...TdxpEnd()very easy! (well, of course, I'm fluant with the API and it may turn out it is not so easy after all LOL )

[martinboehme 493]

JeanLuc,> Bien sur, tu lance une telle perche! :-)Je sais que ca c'est ta conversation prive avec Eric ;-), mais... "lancer une perche", qu'est-ce que cet idiome veut dire?> Thank you for your confidence in TDXP Eric. It is not ready for prime time yet, but I'm definitely considering this.You would consider releasing TDXP? Wouldn't this erode a lot of Reality XP's competitive advantage?Thanks by the way for the information on TDXP... I had always been wondering exactly what kind of technology was behind that name, but I was never really able to tell from the marketspeak on the Reality XP website ;-)Martin

[Guest JeanLuc_]

"lancer une perche": c'est comme pour les pecheurs, ils lancent la perche (la ligne avec l'amecon) et les poissons mangent. Donc, quand on lance une perche, c'est pour fairer le poisson, et on s'attend a ce que le poisson morde.Back to english: you are right this is why I'm evaluating the possibility, while not having taken a decision yet.We have invested a cummulative total of 1 1/2 year work on TDXP now (more than 4000 hours) and the new DLL is even faster a little more than current TDXP v5.x implementation (as found in the actual product line).There are shortcomings (noted above) that are only caused because a line is a line, and if it were drawn as a "rectangle" instead (thickness), its width would expand as the drawing surface enlarges, at the expense of additional drawing time not necessary for most screen/gauge sizes in nowadays computers. In turn, faint lines in Jet Line 4 are not an API limitation, but a design decision to use lines (width coverage 3 pixels max) instead of thick lines (rectangles).Thank you also for your feedback on the lack of "marketing" about TDXP! Inspite of many information on the website, it seems the market reads "GDI+ = smooth" while I'd prefer it reads "TDXP = fluid" ;-)There is some information in the product pages:http://www.reality-xp.com/products/JL2/tour/features.htmhttp://www.reality-xp.com/products/SN3308/index.htm(and I realize the pictures are ageing now)One of the most noticeable feature of TDXP equipped aircraft, is that there is no need for an "EFIS refresh rate slider" to balance sim performance with EFIS performance: it is so fast that it can draw 18 times a seconds X number of EFIS without much FPS hit on FS in most cases. Actually, our latest Flight Line T and N use an extension of TDXP for bitmaps, and it shows it is drawing/compositing faster than standard SDK based layered gauge bitmaps.But enough talking for now, let me bring new products with TDXP to the market with FSX first!

[Guest fturner]

>"lancer une perche": c'est comme pour les pecheurs, ils>lancent la perche (la ligne avec l'amecon) et les poissons>mangent. Donc, quand on lance une perche, c'est pour fairer le>poisson, et on s'attend a ce que le poisson morde.>>Back to english: you are right this is why I'm evaluating the>possibility, while not having taken a decision yet.>>We have invested a cummulative total of 1 1/2 year work on>TDXP now (more than 4000 hours) and the new DLL is even faster>a little more than current TDXP v5.x implementation (as found>in the actual product line).>>There are shortcomings (noted above) that are only caused>because a line is a line, and if it were drawn as a>"rectangle" instead (thickness), its width would expand as the>drawing surface enlarges, at the expense of additional drawing>time not necessary for most screen/gauge sizes in nowadays>computers. In turn, faint lines in Jet Line 4 are not an API>limitation, but a design decision to use lines (width coverage>3 pixels max) instead of thick lines (rectangles).>>Thank you also for your feedback on the lack of "marketing">about TDXP! Inspite of many information on the website, it>seems the market reads "GDI+ = smooth" while I'd prefer it>reads "TDXP = fluid" ;-)>>There is some information in the product pages:>>http://www.reality-xp.com/products/JL2/tour/features.htm>http://www.reality-xp.com/products/SN3308/index.htm>>(and I realize the pictures are ageing now)>>One of the most noticeable feature of TDXP equipped aircraft,>is that there is no need for an "EFIS refresh rate slider" to>balance sim performance with EFIS performance: it is so fast>that it can draw 18 times a seconds X number of EFIS without>much FPS hit on FS in most cases. Actually, our latest Flight>Line T and N use an extension of TDXP for bitmaps, and it>shows it is drawing/compositing faster than standard SDK based>layered gauge bitmaps.>>But enough talking for now, let me bring new products with>TDXP to the market with FSX first!>Without the need of using refresh rate sliders is one reason I will use Agg for my work, as it is the same for it because of its performance. I ran 15 instances of the PFD and I did not have any drops in smoothness from any of them... I even windowed the PFD and expanded it to full 1600X1200 res on a 2nd monitor and this old notebook ran it smoothly with no hiccups.Sorry guys, didn't mean this thread to become an advertisement for TDXP.Frit

[badderjet 181]

Well I've just tried that gage and it's indeed perfectly smooth here. Resized it to various sizes etc. and barely any loss in quality, if at all. Have not checked out any of the code yet tho.Guess I shall count myself to those who now 'will have a look at AGG'... :-hahGreat thread here, keep it up.Etienne :-wave

[WarpD 824]

I ran the AggPlus demo and perused it's code.It has no clipping capability... not even the most basic of rectangular areas.It's text rendering is 6x slower than GDI+.

[WarpD 824]

>There are shortcomings (noted above) that are only caused>because a line is a line, and if it were drawn as a>"rectangle" instead (thickness), its width would expand as the>drawing surface enlarges, at the expense of additional drawing>time not necessary for most screen/gauge sizes in nowadays>computers. In turn, faint lines in Jet Line 4 are not an API>limitation, but a design decision to use lines (width coverage>3 pixels max) instead of thick lines (rectangles).>JL, the problem is that a line isn't actually a line in graphics rendering. Everything down to a single point is scaled in graphics rendering.The fact you ignore this makes your gauges practically translucent in appearance at higher screen resolutions. As I stated, I own your JL4 gauges and stopped using them because they are physically impossible to follow without severe eye strain at higher screen resolutions.

[WarpD 824]

Ok... I sat down with the AGG library and the AggPlus library.I use VC++2005, which was a problem at the start. First, I had to go in and make code changes to declarations that were 'valid' in VC++6 but are no longer 'valid' in VC++2005. Thus source code change, right off the bat. Then once I got it to compile I attempted to run it.... it failed with an error that it couldn't locate the MSVCRT80.DLL. Interesting since the sucker's on my hard drive where it belongs. So, I gave up on the demo and decided to see what it would take to convert a current GDI+ gauge over to AggPlus. First issue was locating all the different header files that were spread through several subfolders. Not a friendly beginning. Second issue was that there are several basic (and I do mean basic) routines used in the gauge that AggPlus doesn't support.... like DrawPolygon. Huh?? It doesn't support rendering a polygon?? You're kidding, right? I mean, this is most definitely not rocket science here. The next thing it didn't offer support on... basic rectangular clipping. Yeah, that's right... zip, zilch, nada. Look, rectangular clipping is absolutely the simplest clipping method out there... how can it be so hard to support in AggPlus?Sorry, while it's a start... AggPlus is not yet ready for 'prime time' usage.

[Guest fturner]

>Ok... I sat down with the AGG library and the AggPlus>library.>>I use VC++2005, which was a problem at the start. First, I>had to go in and make code changes to declarations that were>'valid' in VC++6 but are no longer 'valid' in VC++2005. Thus>source code change, right off the bat. Then once I got it to>compile I attempted to run it.... it failed with an error that>it couldn't locate the MSVCRT80.DLL. Interesting since the>sucker's on my hard drive where it belongs. So, I gave up on>the demo and decided to see what it would take to convert a>current GDI+ gauge over to AggPlus. First issue was locating>all the different header files that were spread through>several subfolders. Not a friendly beginning. Second issue>was that there are several basic (and I do mean basic)>routines used in the gauge that AggPlus doesn't support....>like DrawPolygon. Huh?? It doesn't support rendering a>polygon?? You're kidding, right? I mean, this is most>definitely not rocket science here. The next thing it didn't>offer support on... basic rectangular clipping. Yeah, that's>right... zip, zilch, nada. Look, rectangular clipping is>absolutely the simplest clipping method out there... how can>it be so hard to support in AggPlus?>>Sorry, while it's a start... AggPlus is not yet ready for>'prime time' usage.>Then don't use it, use Agg directly. Its not hard at all if you know C++ coding, and thats pure C++ coding, NOT microsoft's version of it.Its obvious Agg is too complicated for some folks, and I would not recommend it to a casual programmer who does not have a fairly solid back ground in coding. If you can't hack it, then don't slam it down and say no one should use it at all.Frit

[WarpD 824]

>Then don't use it, use Agg directly. Its not hard at all if>you know C++ coding, and thats pure C++ coding, NOT>microsoft's version of it.>>Its obvious Agg is too complicated for some folks, and I would>not recommend it to a casual programmer who does not have a>fairly solid back ground in coding. If you can't hack it,>then don't slam it down and say no one should use it at all.>>Frit>>I don't think that after 25+ years of writing software professionally that I could be considered even remotely a casual programmer. I was a professional software developer before there was a degree in anything computers.I'm not certain why it is if someone posts a dissenting opinion that it is perfectly acceptable to attempt to insult and/or discredit them.If you don't want an opinion on something... don't post about it where people can respond. Simple as that. Otherwise, accept that people will agree/disagree and allow them to do just that without making it personal.