GDI+ Alternative - C++ Gauge

[Guest fturner]

>>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.I too have been programming for over 25 years professionally. The only posts I have seen from you in this entire thread has been nothing but negative..... so how else is someone suppose to look at what you say. Its too complicated.... it doesn't do lines at high resolutions... and so on and so on.....I'm not being insulting, I'm just saying fact :). What you say I'm taking personally... think again LOL! I just don't want other people who may look at you as a guru thinking that agg isn't even worth the effort, which is the message you are giving everyone.So again, if you don't like it or can't hack it, then don't bother with it.... don't bother me none :), but don't sit here and try to convince everyone else it isn't worth because you don't know about this new thing. If you don't think its any good, then go ahead and prove it... go in there and prove with code samples etc that agg isn't worth it or won't do what your saying..... and prove that gdi+ is way better etcHave fun!Frit

[WarpD 824]

>I too have been programming for over 25 years professionally. >The only posts I have seen from you in this entire thread has>been nothing but negative..... so how else is someone suppose>to look at what you say. Its too complicated.... it doesn't>do lines at high resolutions... and so on and so on.....>I never said it's too complicated. I believe you have me confused with someone else's post. I have indeed said it isn't written with game graphics in mind.>I'm not being insulting, I'm just saying fact :). What you>say I'm taking personally... think again LOL! I just don't>want other people who may look at you as a guru thinking that>agg isn't even worth the effort, which is the message you are>giving everyone.No... see... fact isn't in a statement like "can't hack it". That's a statement that implies it is above my abilities or knowledge.>>So again, if you don't like it or can't hack it, then don't>bother with it.... don't bother me none :), but don't sit here>and try to convince everyone else it isn't worth because you>don't know about this new thing. If you don't think its any>good, then go ahead and prove it... go in there and prove with>code samples etc that agg isn't worth it or won't do what your>saying..... and prove that gdi+ is way better etc>I don't have to prove a thing. I already have gauges completed with GDI+. They work, work well and have no frame rate impact. I attempted to convert one of them using AGG and found that the AGG code would require a few weeks worth (at the least) of effort to bring it to the same level of functionality that GDI+ currently offers.The AGG and AggPlus code simply doesn't support to the same level as GDI+. Your posts here imply it's a great replacement. While it is indeed faster in most aspects (text is 6x slower), it is not a great replacement because it requires some significant time investment to bring it up to a level where it supports full GDI+ functionality. High end gauges use such items as draw/fill polygon and clipping. A lot. These are not insignificant items.As well, considering text rendering in AggPlus is 6x slower... if your gauge is mostly text (FMC as example)... you get absolutely no performance improvement, rather it gets worse.AGG and AggPlus hold promise... but they are not yet ready for 'prime time' in FS.

[Guest Patrick_Waugh]

Another good concept to keep in mind I was taught in my doctoral program while evaluating research.There is the concept of clinical vs. statistical significance.For example, a study might make the claim that a given drug does indeed cause weight loss to the 99th percentile of certainty (ie statisically significant). However, we might look closer at the research as see that the actual weight loss achieved averaged only 0.5 lbs! Thus, the results are not clinically significant.So, in the case of evaluating the software, while it might, for example, give you a sub-pixel rendering resolution of 0.001 (which sounds a bit high to me actually) ultimately that might not really be "Clinically significant" in a gauge that is pixelated at 256 x 256 and then sized down to 41x41 on the actual panel.Now for some gauges that are graphics intensive and larger it may indeed save some processor time and look better... I don't know I haven't seen it in action, so I can't wait to have a look at your sample that you have graciously put up for others to benefit from your work.If I was going to use something this low-level, I'd probably just write my own render pipeline anyway so it does what I want, and I can use it in any other project I create easily. Maybe when I learn some more about shaders. I've seen some really cool stuff done with Ogre though.

[WarpD 824]

>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.My 21" monitor in 1600x1200 mode has exactly 1600 physical pixels across and 1200 physical pixels down. Each individual pixel is either on (with a color) or off (black). No matter how much math you toss out... you will always, always display exactly the physical number of pixels in the screen resolution.On the AGG website is a .gif file comparing a set of GDI+ rendered lines versus a set of AGG rendered lines. The only significant difference between the two is the color resolution being used to smooth the line's curvature. Other than that, they use the same pixel count. Literally. I know... I overlaid them one on top of the other. Sub-pixel is a term to describe the algorithm used for the color resolution in the resampling and smoothing, not a physical item. If you compare the two line outputs, you can clearly see that the AGG lines are using far more color variations to render the same line, thus appearing to have a smoother look. Yet it is using the same area (size). If you take them and place them side by side and then increase their size 500% you can clearly see the colorations. In fact, when you do that... the GDI+ line retains it's actual color whereas the AGG line starts to lighten to a grayed version because of it's increased color range. You can see physical 'stripes' of lighter grays showing in the lines at this point, but not in the GDI+ lines.Now, imagine how that looks in a VC when the user zooms in. Yep... zebra stripes.Basically subpixel resolution is a modification of the Bresenham formula for rendering a line. It offers a variable sampling rate to provide deeper color resolution when rendering the anti-aliased line. It does NOT actually use more pixels.>>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.This isn't correct... well, it is and isn't. The +-10 degrees is in lateral movement, not radial. Thus the resolution is based on how many pixels you allocate between the min value position and the max value position. If you set it up so you have 257 pixels from min to max... then you would get 1 pixel per possible value of the VOR deviation needle. Even AGG can't get a clearer resolution on that. However, to ensure you retain that would require that the gauge size be such that you never drop below the 257 pixels. Otherwise, you're no longer running at a resolution large enough to physically render each position individually. If you need 257 pixels for full size... a half sized image would be 128.5 pixels. If you're working with a radial movement, to ensure you have unique coordinates for every possible value from 0 to 359 would require a radius of approximately 2000 pixels.The use of AGG does not provide more resolution than you already have. It only provides for a deeper color depth in your anti-alias of the rendering. No more, no less. Using it has it's price, and I want to ensure everyone understands that it's got issues just like any other graphics API. They all have their issues. Now, if you want to tout AGG as being faster... ok, no question (except text). It also probably has a better algorithm for image resampling for scaling. But to be honest, it is not doing exactly what you're implying with this post's example. There are no 'sub-pixels' on anyone's monitor. Never were, never will be.

[martinboehme 493]

No question... there ain't no such thing as a "subpixel"... show me a monitor that has them and I'll buy it. ;-) But there is such a thing as "subpixel resolution", and it's useful... (at least to me).Consider the case where we want to draw a square with one-pixel sides, and those sides are aligned exactly with the pixel boundaries. Let's say we want the square to be drawn at a brightness value of 200, on a black background. This is the image we get: 0 0 0 0 200 0 0 0 0(Sorry, can't get the pixel columns to align... how do I switch to a monospaced font?)Now let's say we shift the square right by half a pixel. This is the result that we have now: 0 0 0 0 100 100 0 0 0(One way to get to this result would be to render the image at double the resolution originally, then average over blocks of 2x2 pixels.)Some people call this "antialiasing". Some call it "subpixel resolution". No matter what you call it, the interesting thing is: Moving the object that you're rendering by less than a pixel results in a change in the resulting image... and a useful change at that, because it gives us information about the position of the object to a resolution of better than a pixel. Say we got this image: 0 0 0 0 50 150 0 0 0No prizes for guessing where the square is now...The useful thing is that our eyes are pretty good at interpreting these kinds of "subpixel effects", too. Why? Well, our eyes have limited resolution too -- the retina is made up of discrete light-sensitive cells, after all -- and so we have the same "subpixel effects" going on in our eyes all the time.(Side note: These effects are also used in computer-based image analysis. At work, I'm currently working on building an eye tracker -- a device that measures where you're looking -- and we can measure the position of the user's pupil in the camera image to a precision of better than one pixel.)The nice thing is that there's an objective definition of the result that an ideal "antialiasing" or "subpixel rendering" algorithm should produce. It's the result that you would get by drawing the object at infinite resolution, then laying a pixel grid over it and determining what percentage of each pixel is covered by the object we want to render. That percentage then corresponds to the brightness value that should be assigned to the pixel.(Side note to any signal processing gurus who may be lurking in the wings: Yes, this is just a simplified illustration. Yes, I'm using a rect window here, which will lead to leakage and oscillations in the spectral domain. Maybe I should be using a sinc... possibly windowed using a Blackman window... hey, what's this I read in the AGG documentation about sincs and Blackman windows? Hmmm... ;-) )Pretty much the same thing happens, by a physical process, when we take a picture of an object using a digital camera -- if there are hard edges in the object, those will show up as "antialiasing" in the camera image. In fact, we can use this as a "gold standard" for a rendering algorithm: The result of rendering any object should ideally be the result we would have obtained by taking a picture of the same object using a good digital camera. (Talk about "photoreal" ;-) ) Of course, any rendering library, such as GDI+ or AGG, will only implement an approximation of this "ideal"... but the closer it is to the ideal, the better the quality of the rendering. How GDI+ and AGG stack up in this comparison, I don't know...Martin

[martinboehme 493]

Hey guys, this has been a great thread... please don't turn it into an argument about who has been programming professionally for longer. ;-) Ed gave us an open, no-holds-barred account of his opinion and experiences with GDI+ and AGG... and Frit, I think you interpreted that as a dismissal and overly negative putdown of your enthusiasm for AGG, which I don't think is how it was intended. At least I didn't interpret it that way...Frit, Ed, thank you to both of you for sharing your experiences with AGG and GDI+. I've learned a lot from this thread -- and I hope there's plenty more to come!Martin

[Rocky 128]

I fully agree with Martin. Frit and Ed both gave us all very valuable information and opinions, and now everyone is free to make its own opinion.I just add that:1) Frit shouldn't take AGG critics personnaly. Frit, even if you're convinced that AGG is the best solution for vector graphics, don't take the critics against you. As Martin said, we are all very happy about the information and the sample you have provided here, and I thank you for this.2) Noone should criticize an open source development that is provided to the community for free. You are free to use or not use AGG and AggPlus. If you like them, use them, and if not, don't use them. As we say "take it or leave it", but you don't need to kill a free product with critics, just say you don't want to use it.This is only my opinion (as a former freeware add-on developer).Eric

[WarpD 824]

>Hey guys, this has been a great thread... please don't turn>it into an argument about who has been programming>professionally for longer. ;-) >>Ed gave us an open, no-holds-barred account of his opinion and>experiences with GDI+ and AGG... and Frit, I think you>interpreted that as a dismissal and overly negative putdown of>your enthusiasm for AGG, which I don't think is how it was>intended. At least I didn't interpret it that way...>>Frit, Ed, thank you to both of you for sharing your>experiences with AGG and GDI+. I've learned a lot from this>thread -- and I hope there's plenty more to come!>>MartinThe point of my posts is to ensure that people clearly understand it is not a GDI+ replacement. It's a graphics API, it renders faster than GDI+, but it is not a replacement. Even the AggPlus library isn't good enough to be called a replacement. It has too many critical functions missing.So... rather than everyone trying to bully me out of the discussion... how about you realize that there are limitations and problems with the API being suggested and that if no one bothers to state them, there will be quite a few people getting the wrong ideas.Regarding the post above this one and sub-pixel resolution. What is continually forgotten is that for an entire image such as 'real life'... certainly sub-pixel resolution has advantages... for a single green/white/red/blue line drawn diagonally across a CRT... it usually ends up fading out the brightness of the line making it harder to visualize. Consider that most of the AGG information on their website references image processing... not line rendering.

[martinboehme 493]

> The point of my posts is to ensure that people clearly understand it> is not a GDI+ replacement. It's a graphics API, it renders faster than> GDI+, but it is not a replacement. Even the AggPlus library isn't good> enough to be called a replacement. It has too many critical functions> missing.Absolutely. I still intend to evaluate it because if it's good enough for some of the things I want to do and does those things faster than GDI+ does -- great! If it turns out AGG doesn't suit my purposes -- well, I'll still have learned something. Seems you did just this and came to the latter conclusion -- thanks for sharing your insights.Thanks also for pointing out the speed issue with text -- that seems to be a major caveat, maybe there's a workaround (pre-render the font to a bitmap, that kind of thing...), maybe not... and even if there is, maybe it's just too much of a hassle to justify doing it.In the end, the good thing is that I get to choose... I can use AGG for those things that it's good at, and GDI+ for the things that _it_ is good at. And if Jean-Luc decides to make TDXP availabe, we'll have even more choice.About subpixel resolution... agreed, there are some cases where it doesn't help a lot, and ultimately, what counts is whether it looks good -- and helps us fly the aircraft! In some situations, I find subpixel resolution can be a very helpful -- I find my pitch control is better on ADIs that do subpixel rendering, and I'm grateful that GDI+ and AGG let us implement these kinds of gauges.Martin

[Guest fturner]

Guess Microsoft has made a big mistake then cause Agg isn't ready for prime time usage in FS.Oh well.... it looked like it had promise :(.Frit

[Rocky 128]

What are you talking about? Can you tell us more?Do you mean AGG is not usable in FS because of some strange reason?I'm surprised because your PFD is working fine in FS...Eric

[n4gix 4,947]

>Regarding the post above this one and sub-pixel resolution. >What is continually forgotten is that for an entire image such>as 'real life'... certainly sub-pixel resolution has>advantages... for a single green/white/red/blue line drawn>diagonally across a CRT... it usually ends up fading out the>brightness of the line making it harder to visualize. >Consider that most of the AGG information on their website>references image processing... not line rendering.That last sentence is an important point. Note that ACES chose to use AG for what? ...image processing... It is used in their scenery render loop. ;)Gentlemen, I have thoroughly enjoyed this discussion, and have benefited from the knowledge gained. Thanks to everyone!

[Guest fturner]

>What are you talking about? Can you tell us more?>Do you mean AGG is not usable in FS because of some strange>reason?>>I'm surprised because your PFD is working fine in FS...>>Eric>I have had no problems rendering whatever I wanted in FS using Agg, including loading bitmaps onto polygons and using agg to transform them using its capabilities, but the experts have said its not ready for prime time usage in FS as stated above. Microsoft also uses Agg in FSX to handle some of their 2d object processing.Frit

[Rocky 128]

I am sorry to insist, but this is not very clear to me. Maybe my English is not good enough :-(...What do you mean by "not ready for prime time usage in FS"? Do you mean it is not usable?I understand MS uses AGG for whatever image processing, but I don't understand why it prevents us from using it for vector gauges. Where is the problem?Thanks,Eric

[martinboehme 493]

Frit,I'm not worried, because I'm not shooting for the prime time... Weekday afternoon programming is good enough for me. ;-)Martin