PDA

View Full Version : A new OpenVG have launch



tomsoft
01-06-2008, 02:08 AM
This is new high performance OpenVG have launch;
You can see: www.hygraphics.com (http://www.hygraphics.com)
or download from: http://www.hygraphics.com/download/ging ... elease.rar (http://www.hygraphics.com/download/gingkoVG/OpenVG%20Release.rar)

This is first edition.

tomsoft
01-08-2008, 05:17 AM
I have update the URL: http://www.hygraphics.com/download/ging ... elease.zip (http://www.hygraphics.com/download/gingkoVG/OpenVG%20Release.zip)

mfabbri
01-09-2008, 01:13 AM
This is new high performance OpenVG have launch;

On my old P4, 80ms/frame (without blit) for a 480x640 Tiger (with 16x AA?) isn't so 'high performance'.
On the same example, Rasteroid 3.1 (16x AA) is 200% faster than GingkoVG.
AmanithVG SRE (Software Rasterizer Engine, not yet released) is 400% faster (with analytic pixel coverage AA*, 256 levels) and 500% faster (with 16X AA) than GingkoVG.

* not the analytic pixel coverage antialiasing algorithm used by Agg/Freetype that can't handle intersections or multiple edges inside a pixel, but a new original one that is able to deal with all such degenerations.

Regardz!

tomsoft
01-11-2008, 03:34 AM
First I will say "thanks" for mfabbri---thanks his test. :P
This is my first edition for OpenVG. I have test hybird OpenVG, It is 200% fast more than the gingkoVG, but. for more flowery, I use 64xAA for gingkoVG(I use box filter for AA), I think it may be slow. The amanithVG I already test, it fastest, but it get help from OpenGL.
As mfabbri say: I know my gingkoVG is not enough "fast", so I will work hard for improve the performance. I hope the final version will all based on hardware accelerating.

I update my WEB with english. Thanks mfabbri.

mfabbri
01-11-2008, 06:35 AM
So, you're designing an OpenVG chip, now it's more clear to me the reason of the multisampling AA choice, and the 64x multisampling also explains the GingoVG performance on my P4 machine (~80ms, without blit).
Anyway, AmanithVG SRE (software rasterization, without OpenGL) takes 16ms to render the tiger (without blit) using a 256 levels AA (analytic pixel coverage estimation). Probably, this kind of algorithm isn't suitable for the hw.
Let me say that a fast polygon scan conversion routine is a key point, but not the only one, to achieve a fast OpenVG implementation, at least a software one.
Find good algorithms to perform path->polygon, stroke->polygon conversion (balancing timing and total output points, without compromise the visual quality), implement smart caching systems to store reusable data, are just two examples routines that you can look at.

Good luck with your project,

tomsoft
01-11-2008, 06:52 PM
Yes. "Let me say that a fast polygon scan conversion routine is a key point", professionally! :D
Now at gingkoVG, We use scanline arithmetic to render a picture, and I translate a curve to series lines(because hardward design reason), But I think it not good idea, so I may want improve my arithmetic.
Like my web said, this edition OpenVG is only for development, But now, I think provide a "faster" edition is necessary to end users.

Thanks your advice.

mfabbri
01-11-2008, 11:30 PM
"Let me say that a fast polygon scan conversion routine is a key point", professionally!
Hehe, i've spent 3 years of my life in OpenVG drivers development, so i'm a professional. ;)


Now at gingkoVG, We use scanline arithmetic to render a picture
Floating point or integer arithmetic ?


and I translate a curve to series lines(because hardward design reason)
I think that every OpenVG implementation (hw or sw) translates curves to series of straight line segments.

tomsoft
01-12-2008, 12:55 AM
Powerful~~~ I have only few months(less than 4 months) in OpenVG development, but I have one year in adobe FlashPlayer development; Admire your ability~~~

"Floating point or integer arithmetic ? "
Integer arithmetic.

"I think that every OpenVG implementation (hw or sw) translates curves to series of straight line segments. "
Translate curves to series of straight is my first idea, I think it is simpleness arithmetic for hardware. But i found the gingkoVG spend too many time at edge process, FlashPlayer support Quad-Bezier, I think it may be good idea, but I not sure, Can you give my any idea?

Thank you again~~~

mfabbri
01-12-2008, 01:42 AM
Translate curves to series of straight is my first idea, I think it is simpleness arithmetic for hardware. But i found the gingkoVG spend too many time at edge process, FlashPlayer support Quad-Bezier, I think it may be good idea, but I not sure, Can you give my any idea?
If you really use a 64x multisampling for the AA, I believe that your bottleneck is on the pixels not on the edges. Anyway, are you sure that the Flash Player rasterizer doesn't decompose quad-bezier to line segments ?

You can try to use something like that: vtm.pdf (http://alice.loria.fr/publications/papers/2005/VTM/vtm.pdf)

tomsoft
01-12-2008, 07:26 PM
Thanks~~~
Yes, you maybe right. Pixel process is one of bottlenecks at 64 x AA;

I am sure FlashPlayer doesn't decompose quad-bezier to line segment(FlashPlayer can support Line and curve ----only quad-bezier), But I think it maybe low performance at every line process, and other side cure translate to line segment is necessary when use OpenGL/hardward accelerate. So I can not sure this is good idea at OpenVG.

Thanks your advice. :)