GDI+ Alternative - C++ Gauge

[Guest fturner]

>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

[Guest JeanLuc_]

#### 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!!

[Guest fturner]

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

[WarpD 824]

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. ;)

[Guest Patrick_Waugh]

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.

[Rocky 128]

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

[martinboehme 493]

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

[Rocky 128]

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

[martinboehme 493]

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

[martinboehme 493]

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

[Rocky 128]

Martin,I can't answer your question because I didn't dig enough into AGG. I was just reacting according to the post from WarpD, who was saying the lines were almost invisible in very high resolution.As I know GDI+ very well, I can just tell you that it calculates the line width according to the resolution. Hopefully you will soon have the opportunity to see screenshots of the project I am working on, and you will see what I am talking about.Eric

[martinboehme 493]

Eric,OK, thanks for the clarification. I'll have to check for myself then. But even if it doesn't support this feature, it shouldn't be too much of a problem to put a layer on top of AGG that transforms the line widths...> Hopefully you will soon have the opportunity to see screenshots of the project I am working on, and you will see what I am talking about.Hm... sounds good. What are you working on? Or is that a secret?Martin

[Rocky 128]

I'm sorry to say it is still confidential, even if some people on this forum already know about it ;-)I'll tell you more as soon as I can.Eric

[martinboehme 493]

> I'm sorry to say it is still confidential, even if some people on this forum already know about it ;-) I'll tell you more as soon as I can.OK, thanks... looking forward to hear more (knowing your work, I expect it will be good..)Martin

[Guest fturner]

As for line thickness.... you need to scale it based on resolution, which again is an easy thing to do, either at the pixel level, path level or even the entire bitmap level... its your choice.There is an wrapper api out there that wraps around agg and gives you the same commands as gdi+, and in fact, all it requires for your code is to link to its library instead of gdi. When I looked at it, the performance was about the same as gdi+, but the big benefit is you get agg's sub pixel accuracy.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. They couldn't hand fly accurately with that, but when they talked about AGG and RXP gauges, they couldn't believe how accurate they could hand fly the plane because of that sub pixel accuracy.Frit