Results 1 to 8 of 8

Thread: Making Compiler, Disk Testing More Reproducible

  1. #1
    Join Date
    Jan 2007
    Posts
    14,805

    Default Making Compiler, Disk Testing More Reproducible

    Phoronix: Making Compiler, Disk Testing More Reproducible

    There's some enhancements to share that make compiler and disk testing more reproducible under Linux, plus many other features...

    http://www.phoronix.com/vr.php?view=MTA3MDI

  2. #2
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,103

    Default

    The text in the PNGs is clipped:


  3. #3

    Default

    Quote Originally Posted by curaga View Post
    The text in the PNGs is clipped:

    I haven't yet implemented any artificial word-wrapping support in the PNG back-end renderer... Opera is the only major browser where SVG is black-listed, even Microsoft IE does better. Opera still can't handle text dominant-baseline...

  4. #4
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,103

    Default

    Just curious, why do you have to do manual png support? Couldn't you just pipe the svg to rsvg, or any other svg renderer and let them handle the conversion to png?

  5. #5
    Join Date
    Apr 2010
    Posts
    99

    Default

    Quote Originally Posted by phoronix View Post
    If you're browser doesn't yet fully support SVG,
    I'm not a browser!

    (Sorry, I couldn't resist)

  6. #6

    Default

    Quote Originally Posted by curaga View Post
    Just curious, why do you have to do manual png support? Couldn't you just pipe the svg to rsvg, or any other svg renderer and let them handle the conversion to png?
    Previous to the forthcoming 3.8-Bygland release, pts_Graph used bilde_renderer, which was a cross-format image renderer I came up with. The single API exposed that was used by pts_Graph could then seamlessly target SVG, PNG, JPEG, SVGZ, Adobe SWF/Flash, etc with different back-end renderers. With 3.8 the focus has changed to using an SVG DOM directly. The only time PNG (or anything else) is being used is when either targeting a problematic browser or when inserting graphs into an Adobe PDF file. In terms of not using any external SVG-to-PNG converter now, I prefer eliminating the need of external dependencies, etc. SVG is the main focus. The PNG renderer I wrote for Bygland that accepts the SVG DOM as input can produce a near static parity in about 400 lines of code, which is efficient for fall-back purposes when doing the rendering on OpenBenchmarking.org.

  7. #7

    Default

    Quote Originally Posted by curaga View Post
    Just curious, why do you have to do manual png support? Couldn't you just pipe the svg to rsvg, or any other svg renderer and let them handle the conversion to png?
    CURAGA:

    Within PTS Git I changed around how SVG text alignment is done so it avoids most use of the dominant-baseline attribute where Opera falls on its face... On OB, you can try appending '&force_format=SVG' to any of the URLs to get SVG graphs.... do those pretty much show up nicely for you? Opera may be white-listed soon with this new renderer that avoids dominant-baseline attribute.

    e.g. http://openbenchmarking.org/result/1...rce_format=SVG

  8. #8
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,103

    Default

    Thanks for taking care of the browser minority Michael.

    The alignment is now fine, but some text is even more unreadable than in the PNGs. The summary table looks fully OK.



    --------------

    In the bars, the top-left description is clipped. There's some unreadable text here too:

Posting Permissions

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