Sign in to follow this  
Guest fturner

GDI+ Alternative - C++ Gauge

Recommended Posts

Hi folks,I was going through my hard drive tonight cleaning stuff up and I came across a project I was playing with end of last year/beginning of this year.Basically, its an alternative to drawing "vector" gauges other than GDI+, and from the trials I was doing.... it is WAY smoother, WAY faster, and VERY crisp... even in the virtual cockpit.Its called Anti-Grain Geometry, and believe it or not, FSX is actually using a modified version to draw 2d objects.Here's the website to there http://www.antigrain.comAnd here's a link to a VS2003 gauge example I've created that also builds up the fonts as well http://www.cfstudios.com/files/airbus.zipHope you enjoy this and feel free to message me if you have any questions. Also, you can post questions etc under the developers forum at http://www.cfstudios.com/forumAll in all, I ask that you give credit where its do when using any of the work provided by anyone else. Of course we all know that some commercial folks won't but thats just the nature of the beast I guess.Have fun.Frit

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Hello Frit,I know AGG, I also had a look at it as an alternative to GDI+. IMO, the documentation is quite bad, and it makes the library very difficult to understand. This is why I gave up because I had no much time to spend on this...Compared to this, GDI+ is very well documented by Microsoft and is very easy to understand.I will have a look at your sample and at the forum you're pointing, hoping it will help me in understanding better this great library, which indeed looks faster than GDI+. BTW, don't you think the AGG rendering looks very similar to Reality XP? Interesting... Eric

Share this post


Link to post
Share on other sites

It took a bit to get to understand how it works, but I found the demos you get with it to be very helpful.Also to note, I needed to make a change to the concat function in AGG 2.4 to make things a little easier to build display lists so to speak. Its in the file agg_path_storage.h in the inc folder and I've marked it with FWT:. I don't have any of realityxp's stuff, but I have been told by others that do, that the AGG produced screen are at least as smooth as their stuff. I know I've done timing on how long it takes for agg to produce a full CRT screen worth of information like the SD on an airbus and the measured time to render was so small it barely registered.Once you get the hang of how agg works, its a breeze and I actually found it easier to do than GDI+.Frit

Share this post


Link to post
Share on other sites

I didn't look very deepply into AGG, and I hope I will have the time to do it, but I have been looking for a clipping function and I couldn't find any. Do you know if it exists? Maybe I didn't search enough...Thanks,Eric

Share this post


Link to post
Share on other sites

The built in clipping in AGG only uses a rectangle, but another person has added functions into AGG to do fancier clippings, but I don't think its free for commercial use.To by pass it, I've actually built several planes up then blitted the layers together as my example shows a basic way of doing that as well.Frit

Share this post


Link to post
Share on other sites

I find the AGG rendering to be rather anorexic in appearance to be honest. It tends to overdo the anti-alias to the point where thin lines are practically transparent.

Share this post


Link to post
Share on other sites

I tried it a while ago and found that the quality wasn't much better than GDI+ and it was only slightly faster. Perhaps I was doing something wrong? The font support was poor as well.

Share this post


Link to post
Share on other sites

>I find the AGG rendering to be rather anorexic in appearance>to be honest. It tends to overdo the anti-alias to the point>where thin lines are practically transparent.I had that problem at first but once I started setting the line thickness to 1.5 and/or offset the line by 0.5 pixels that cured the problem, and I was able to get very fine lines that where very crisp.Frit

Share this post


Link to post
Share on other sites

Thanks. We've had a gauge programmer looking deeply at AG for many months. I'll make sure he sees your example! ;)

Share this post


Link to post
Share on other sites

Yeah, I looded at this too, but frankly don't really see the cost/benefit trade-off compared to GDI+ in terms of learning curve vs. performance. I think the key is just proper programming, whatever API you use. Using GDI+ for the sim itself would be to slow, but for gauges, I think this is a bit of 'overoptimization' at work really.

Share this post


Link to post
Share on other sites

Not to be a stickler in the mud, but having such a negative attitude towards something new is not gonna get you anywhere.I have done the testing.. ie did the entire gauge in GDI+ and also generated the entire gauge using AGG and there is a HUGE difference in performance. We are talking milliseconds difference between them.... in fact, I even coded alot of the gdi+ gauge in assembler to try to improve its performance over AGG and despite shaving off a few milliseconds, it could not do it.Also, one thing that GDI+ will never be able to do is sub pixel processing.... at least to the level AGG can. There is no way you will ever get a GDI+ gauge to be liquid smooth as AGG can be because GDI+ just doesn't have the subpixel accuracy...Frit

Share this post


Link to post
Share on other sites

Hi Eric!well, from French to French, je comprends l'insinuation, mais pas de lezard, TDXP et AAG sont bien deux choses differentes ;-)Back in english, AAG is WAY faster than GDI+ and TDXP is even WAY faster than AAG. Unfortunately, AAG licensing aggreement prevents commercial use for the most part.AAG also provides a Liang Barsky clipping. You will find this interresting although there are many web sites about this. TDXP uses a faster approach for viewports, and a near no-cost approach for the entire drawing surface.Hope this helps!

Share this post


Link to post
Share on other sites

>Hi Eric!>>well, from French to French, je comprends l'insinuation, mais>pas de lezard, TDXP et AAG sont bien deux choses differentes>;-)>>Back in english, AAG is WAY faster than GDI+ and TDXP is even>WAY faster than AAG. Unfortunately, AAG licensing aggreement>prevents commercial use for the most part.>>AAG also provides a Liang Barsky clipping. You will find this>interresting although there are many web sites about this.>TDXP uses a faster approach for viewports, and a near no-cost>approach for the entire drawing surface.>>Hope this helps!>>>Actually, I think you need to re-read the license on AGG..... it CAN be used for commercial use with no payments. Its the enhanced clipping system that needs to be negotiated.After trial runs with several people who tried Agg to realityXP stuff, AGG won hands down in the VC.Sheesh, why am I defending this LOL! I know for my commercial projects I will be using AGG, as its the only "free" system out there ;).Frit

Share this post


Link to post
Share on other sites

just read the license again, and my memory is aging! you are right and this is a good to go. I was wrong."After trial runs with several people who tried Agg to realityXP stuff, AGG won hands down in the VC."You got my attention! I really wonder what you refer to "win"? with what Reality XP product do you compare and under what comparision context?By the way, TDXP is being ported to a standalone DLL now with a documented API. With the latest build, DRAWING and BLITTING a 500x500 bitmap with a reasonably complex rendering (nearly twice as complex as the Jet Line 4 PFD in terms of clipping/number of elements drawn) takes roughly 4.2ns per pixel on average on a Core Duo 2Ghz (and roughyl 4.8ns per pixel on average on a P4 2.8Ghz.Let me know what you get with AAG. I may scrap all to the trashcan and use it instead if it is indeed faster.Please help!

Share this post


Link to post
Share on other sites

I hear you, I'm just saying that IMHO, the benefits are not going to be all that noticable, compared to the level of effort required. I mean, once you resize that gauge down to 41x41 pixels, you aren't going to see the difference. Now for something bigger then maybe so for some special effect.I think it's awesome that you have learned it. Actually, I hope they develop it more. I may use it in a game program.

Share this post


Link to post
Share on other sites

>just read the license again, and my memory is aging! you are>right and this is a good to go. I was wrong.>>"After trial runs with several people who tried Agg to>realityXP stuff, AGG won hands down in the VC.">>You got my attention! I really wonder what you refer to "win"?>with what Reality XP product do you compare and under what>comparision context?>>By the way, TDXP is being ported to a standalone DLL now with>a documented API. With the latest build, DRAWING and BLITTING>a 500x500 bitmap with a reasonably complex rendering (nearly>twice as complex as the Jet Line 4 PFD in terms of>clipping/number of elements drawn) takes roughly 4.2ns per>pixel on average on a Core Duo 2Ghz (and roughyl 4.8ns per>pixel on average on a P4 2.8Ghz.>>Let me know what you get with AAG. I may scrap all to the>trashcan and use it instead if it is indeed faster.>>Please help!>>As for performance, I can only go by what others have told me for comparisons with other products (that are NOT free). I began the development using Agg on a 1.5Ghz HP Notebook and the rendering of a completely function airbus PFD was very, very liquid smooth even in the VC on this notebook.Look, guys.... I'm not here to debate whether this system is better than any other. I just showed it here as an alternative, because frankly GDI+ sucks and I have yet to see a very smooth implementation even with the top guns out there. If TDXP is so fantastic and it kills Agg, all the world to you, but I know I won't be using it cause its gonna cost me for a commercial product no doubt. Also, have you shown and allowed the community to use your code freely to produce smooth graphics????I had Agg working at drawing gauges in 2 nights, and had the text glyphs working shortly after. With my sample code I show how to use Agg and in a very easy way..... and I was even nice enough to show how to and build functions to build text based paths.If you haven't had success or think its a waste of time to use Agg, all the power to you...... this is a take-it-or-leave-it alternative that I have offered to the community.....But I will NOT be drawn in to arguments has what is better or worse or what ever. If your interested, ask questions and I'll do my best to answer them.... if you can only critize or feel you have to compete in any way, then please take it else where.Frit

Share this post


Link to post
Share on other sites

#### internet with total lack of "feeling". Hard to understand intents of the poster through a couple lines of text isn't it?let me say it again:>Let me know what you get with AAG. I may scrap all to the>trashcan and use it instead if it is indeed faster.This is a sincere question, really. You sparkled my interest with a couple of your comments above, and I've even written some details of the TDXP performance that have been confidential so far.I'm not feeling to compete, and I'm asking questions because I'm interested.AAG is one (if not the) of the best drawing API and is free. Way better than GDI+ (subpixel precision, like TDXP, and better rendering pipeline - faster). You can't get better than this. TDXP has been a compiled source code in each product using it (ala AAG), and is now a standalone DLL (ala GDI+). I've not said it will be free or if it will cost something for third party vendors licenses (and I've not even said license will be available to third party vendors). The experience you are relating from others is interesting and makes me want to know more in order to take, like you are suggesting, sound decisions about API of choice. ~4ns per pixel is very fast though (in the range of 10 to 15 CPU cycles per pixel on average, for line/polygon/clip/fill drawing + final blit of the surface on a display as complex as twice the JL4 PFD).Like posted below, it won't make almost any difference for 41x41 pixels screens. However, with 8 of them in a VC (typical Boeing panel with 6 EFIS and 2 CDU), this adds up. The sole advantage of TDXP in this respect, is that in freeing the CPU as much as possible as compared to other APIs, it permits loading the CPU with more complex algorithms at the same time (like TAWS/WX Radar or complex system simulations) while not taking much of the CPU from FS for its own business.Keep us posted the more you advance with AAG if you will. We are all ears big open! it is never too late to improve our products with new and innovative ideas!! thank you for sharing your discoveries so far!!

Share this post


Link to post
Share on other sites

Sorry, if I misunderstood you. I've run the airbus PFD, the ND and the SD on this old machine and the only thing that seems to hold it back is FS itself.I've run timers on renderings with the SD and from the time it clears the buffers, renders the entire scene and blits the resultant bitmaps was around 0.00006 milliseconds..... which is 0.06 nanoseconds according to the timer but I found that hard to believe it could calculate that fast.... and that was running the PFD and ND as well. All I can say is its very scary how fast agg works, and probably the main reason it works so well in the VC.I guess the only way we could determine which is quicker is doing the identical same gauge, but set 1 up to use Agg and set the other up to use TDXP. Now the draw back to Agg is its clipping abilities as in agg its only rectangular, and if using the addin for clipping, performance is hit big time. I decided to take the more creative approach and layer segments of the drawings by building the bitmaps with agg and at the end, blitting them together onto a final bitmap. Works great, but where the edges are with the blitting you don't really get any antialiasing.There is a gauge file already compiled for folks to try out. Its a basic attitude indicator. To use it, copy the airbus.gau file over to the gauges folder and set up the panel.cfg with the following in the gauge line.airbus!PILOTPFDIt will also work in the VC.Frit

Share this post


Link to post
Share on other sites

But having to change the thickness or the position to get proper clarity is a workaround. Requiring a workaround is an indication of a flaw.Like I said... AGG just isn't that impressive. Nor is JeanLuc's RXP of which I purchased the JL4. I never use it because it is impossible to read on my screen.If the rendering routine results in lines that appear so thin that at 1600x1200x32 they're practically non-existant... there's a problem. AGG does this... as does the RXP JL4. I won't even mention 2048x1536x32... ;) No matter how smoothly that line scrolls across the screen, if it's so faint it's impossible to focus on easily.... it just doesn't matter, especially in an aircraft. ;)

Share this post


Link to post
Share on other sites

Yes, great contribution, and much appreciated.I really was just throwing out my opinion that in the end, other things are going to limit you to the point that for MOST things, you don't really need the higher power of it for gauges. Just my opinion, and if I really need more I can always go lower. I guess I was just turned away by the lack of clipping as well.Anyway, glad you got it to work for you. This TDXP is totally new to me though.

Share this post


Link to post
Share on other sites

Hello Jean-Luc,From French to French, j'etais sur que tu allais reagir a mon post, j'attendais ta reponse ;-)Back to English... Jean-Luc, all this discussion shows that you should license your TDXP renderer. Even if it is paying, I am sure many gauge developers (like me) would be interested in getting it for high perfromance gauges, and all the FS world would benefit from it.@Frit: I had a quick look at your code, and it appears my first feeling was right. AGG is fast and powerful, but much more complex than GDI+ in the coding part. I would be able to write the same PFD with half of the lines of code you wrote. I am sure AGG is a good alternative, but I still think it has a steep learning curve compared to GDI+.Maybe TDXP is the best solution, if it is easy to use...Eric

Share this post


Link to post
Share on other sites

Ed,> But having to change the thickness or the position to get proper clarity is a workaround. Requiring a workaround is an indication of a flaw.[snip]I have to admit I haven't tried AGG myself... but I find the examples I saw here very convincing:http://www.antigrain.com/doc/introduction/...oc.html#toc0005(Scroll down to "Lines Rendered with Anti-Aliasing and Subpixel Accuracy", for example. Even the lines with subpixel width look very clear on my dispaly. I find the spiral very convincing, too.)> If the rendering routine results in lines that appear so thin that at 1600x1200x32 they're practically non-existant... there's a problem. AGG does this...I think the problem may be that even straight single-pixel lines can be hard to make out at that kind of resolution... Have you tried taking a screenshot, then blowing it up to see what the image really looks like?I guess the solution to this is probably that line width (in pixels) should scale with the size of the gauge (in pixels). On a 1600x1200 display, this would result in a greater line width than on 1024x768 (which makes sense, since the gauge occupies more pixels). Strictly speaking, this should be done anyway so the lines are always proportionally the same width relative to the size of the display...Anyway, the proof is in the pudding... So I guess I'll just have to try out AGG myself.MartinMartin

Share this post


Link to post
Share on other sites

Hello Martin,You're absolutely right, the line width should scale with the size of the gauge, and GDI+ does this !!GDI+ maybe slower than AGG, but it is better on this point ;-)Eric

Share this post


Link to post
Share on other sites

Frit,fascinating stuff... Thanks for doing that sample gauge, I'll have to try it out. Came across AGG a while ago, had a look at it, and it looked good, but never got round to trying it out. Now you've convinced me that I'll have to take a look at it...> I've run timers on renderings with the SD and from the time it clears the buffers, renders the entire scene and blits the resultant bitmaps was around 0.00006 milliseconds..... which is 0.06 nanoseconds according to the timer but I found that hard to believe it could calculate that fast....I find that hard to believe, too ;-) I think your measurement is going wrong somewhere... At a clock rate of 4 GHz, one clock cycle is 0.25 ns... so AGG is rendering the scene in a quarter of a clock cycle? I'm willing to believe it's good, but not that good... ;-)But AGG certainly sounds like an interesting proposition. I see a SVG parser is included, too... that might be interesting for complex display elements... you could design those in an SVG editor.Thanks for the info!Martin

Share this post


Link to post
Share on other sites

Eric,wow, that was a quick answer... ;-)So does this mean that AGG doesn't support transforms the way GDI+ does, or is line width simply not scaled when you apply a transform?BTW, thanks for your A320 and F-16 gauges!Martin

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this