Results 1 to 10 of 10

Thread: A new OpenVG have launch

  1. #1
    Junior Member
    Join Date
    Jan 2008
    Location
    China
    Posts
    6

    A new OpenVG have launch

    This is new high performance OpenVG have launch;
    You can see: www.hygraphics.com
    or download from: http://www.hygraphics.com/download/ging ... elease.rar

    This is first edition.

  2. #2
    Junior Member
    Join Date
    Jan 2008
    Location
    China
    Posts
    6

    Update the URL


  3. #3
    Junior Member
    Join Date
    Jul 2006
    Location
    Rimini, Italy
    Posts
    18

    Re: A new OpenVG have launch

    Quote Originally Posted by tomsoft
    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!
    Michele Fabbri - Mazatech Srl

  4. #4
    Junior Member
    Join Date
    Jan 2008
    Location
    China
    Posts
    6

    Thanks mfabbri

    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.

  5. #5
    Junior Member
    Join Date
    Jul 2006
    Location
    Rimini, Italy
    Posts
    18
    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,
    Michele Fabbri - Mazatech Srl

  6. #6
    Junior Member
    Join Date
    Jan 2008
    Location
    China
    Posts
    6

    :)

    Yes. "Let me say that a fast polygon scan conversion routine is a key point", professionally!
    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.

  7. #7
    Junior Member
    Join Date
    Jul 2006
    Location
    Rimini, Italy
    Posts
    18

    Re: :)

    Quote Originally Posted by tomsoft
    "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.
    Michele Fabbri - Mazatech Srl

  8. #8
    Junior Member
    Join Date
    Jan 2008
    Location
    China
    Posts
    6

    :)

    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~~~

  9. #9
    Junior Member
    Join Date
    Jul 2006
    Location
    Rimini, Italy
    Posts
    18

    Re: :)

    Quote Originally Posted by tomsoft
    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
    Michele Fabbri - Mazatech Srl

  10. #10
    Junior Member
    Join Date
    Jan 2008
    Location
    China
    Posts
    6
    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.

Similar Threads

  1. Kernel launch time
    By biren in forum OpenCL
    Replies: 1
    Last Post: 04-03-2013, 07:36 AM
  2. OpenGL + OpenVG
    By wdyu2002 in forum OpenVG and VGU
    Replies: 15
    Last Post: 12-09-2009, 09:29 AM
  3. openVG - dependency
    By tinuhp in forum OpenVG and VGU
    Replies: 0
    Last Post: 10-24-2007, 09:22 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •