dr|z3d
ok, svg graphs now about 50% of the original size. turns out the main graph data path is being rendered twice to the file.
dr|z3d
ok, latest + dev build uploaded, now with crisper graph text, optimized svgs.
T3s|4
o/ dr|z3d - the graphs look great at 4K on 13+ = thanks!
dr|z3d
thanks for the feedback, T3s|4_, kudos to zzz for getting it working.
zzz
do I have double-rendering or was that your bug?
dr|z3d
you have it.
dr|z3d
the graph data path is rendered to file twice to the file, possibly because in rrd4j it's rendered twice to generate a "peaks" line above the graph.
dr|z3d
so you get 2 paths, one filled, one unfilled, both exactly the same. the clipPaths in the svg mean you don't need 2 copies to get the same result, you just need to add a stroke color to the main one.
dr|z3d
open a graph file in your favorite text editor and look for <path elements, you should see 2 identical consecutive paths (wrapped in a <g>).
dr|z3d
or rather, each <path> element is contained in a <g> element.
dr|z3d
but they're consecutive.
zzz
hmm
zzz
where did you fix it? in rrd4j or jfreesvg?
zzz
where did you fix it? in rrd4j or jfreesvg?
dr|z3d
git.skank.i2p/i2pplus/I2P.Plus/src/commit/7bd9a782a813ff0a1eb8e295a5fba8df81226df1/apps/jrobin/java/src/org/jfree/svg/src/SVGGraphics2D.java#L2760
zzz
also, you forgot to checkin SVGImageWorker, it doesn't build
dr|z3d
ah, that's why CI was complaining, thanks.
zzz
lol, couldn't be bothered to look?
dr|z3d
only just noticed :)
dr|z3d
"just" being within the last 5m.
zzz
you also went to a whole lot of trouble to make a separate jfreesvg.jar for some reason, but you put the sources in apps/jrobin/java/src (like I did), so you now have the classes in jrobin.jar also (like I did, which is the easy way, no separate build.xml req'd)
dr|z3d
I figured re fixes it's probably best to leave rrd4j alone for now and focus on jfree.. as I mentioned, there may be a valid reason to print the same path twice when you're rendering to bitmap.
dr|z3d
oh, right, never realised jrobin would happily integrate jfree without a separate jar.
dr|z3d
I had it separately initially in apps/jfree or wherever, but it needed to be in jrobin because of your ImageWorker.
zzz
ofc anything you throw in apps/jrobin/java/src goes into jrobin.jar
dr|z3d
ok, thought that might be the case, but wasn't sure, thanks for the tip :)
zzz
that's how I do a lot of experiments, just add source into some existing jar
dr|z3d
good to know, that makes things a lot quicker to mess around with.
dr|z3d
if you're using fonts for the graph display that support intermediate font weights, font-weight:600 gives you the best result for the text.
dr|z3d
much, much cleaner rendering.
zzz
were you comp0laining about the <defs> section that wasn't needed?
dr|z3d
yeah, I was, but it is needed on further inspection. the clip paths are required to ensure the graph doesn't overflow
dr|z3d
you'll also notice I've thrown a gradient definition in there for the dark theme.
zzz
I don't know what version of jfreesvg you copied in but it looks a heckofalot different than what I used, which was the head from github
zzz
and in my version it only includes defs if needed
zzz
I did a diff between yours and mine and it was completely different
dr|z3d
I used 4.1
dr|z3d
which apparently was the last version to support java 8.
dr|z3d
either way, the defs are needed, at least in 4.1, they supply the clip path.
zzz
yeah it claims java 11 req'd but it works fine for me on 8, so not sure why
dr|z3d
hmm, odd. well, works fine for our purposes with 4.1, anyways, no issue's I've seen. and maybe 4.1 is a better choice, less code churn.
dr|z3d
*issues
dr|z3d
4.1. or 4.2, sorry. I'd have to check.
dr|z3d
iirc, I pulled down the source zip of 4.1 from github.com/jfree/jfreesvg/releases
dr|z3d
maybe the java 11 requirement is related to using it as a module? "This is the first release of JFreeSVG as a Java module. It requires Java 11 or later."
zzz
sounds right
dr|z3d
did you confirm it's doing the double path thing with your version of jfree?
zzz
looking now
dr|z3d
I also had a stab at removing unneeded points in the paths, but haven't got that working yet.
zzz
yeah
zzz
are the colors of the two paths the same?
zzz
rrd4j is doing it
zzz
in RrdGraph.drawData()
zzz
worker.fillPolygon(x, lastY, y, source.color);
zzz
worker.drawPolyline(x, lastY, source.getParentColor(), new BasicStroke(0));
zzz
maybe it shouldn't bother if source.color.equals(source.getParentColor()) or something? not sure what the parent color is
dr|z3d
not sure the colors are the same, one path is just the stroke color, the other is filled.
dr|z3d
at least, by the time it hits the svg.
dr|z3d
If that's the case in rrd4j, it's probably intention to give the graph peaks slight emphasis which you may be able to see, was most noticeable in the light theme here before I modified the output.
dr|z3d
*intentional
dr|z3d
but yeah, you're probably right on the money. why draw the graph twice if the only purpose is to add a stroke? you can add that to the main graph.
dr|z3d
I was going to create a clone for the graph in svg to save space, but that wasn't necessary, because the copy of the graph adds nothing as long as you add a stroke color to the first graph.
dr|z3d
as for parent color, my guess is transparent.
zzz
it does seem like the outline of the graph is a little darker blue
dr|z3d
yeah, that emphasizes the peaks.
zzz
it's all the way around 4 sides, not just the top
dr|z3d
in the svg?
zzz
looking with my eyeballs
dr|z3d
use the zoom, Luke!
dr|z3d
I'll cake a screenshot of what a light themed graph looks like here. the clipPaths in use in 4.1 ensure that only the top of the graph has a different color. that's using a single path with a stroke color.
zzz
it is on purpose that rr44j is outlining the area with a different color
dr|z3d
right, that's what I'm saying. it's to emphasize the peaks.
dr|z3d
at least, that's what it seems like to me.
zzz
if it was for the peaks he wouldn't do it on all 4 sides
dr|z3d
never noticed on all 4 sides, only the peaks.
dr|z3d
maybe there's some clipping that happens so you might see it on the right, but not bottom/left.
dr|z3d
it's more obvious here what the intended (?) effect is: cake.i2p/file/gXwy7NR9ux_7w8CVW3CllGqurcZeTX9FXu5t4d9tp_yPBs2RAupF/peaks-dark.png
zzz
the awt Graphics2D API does not appear to support drawing polygons with a different border than fill color
zzz
so rrd4j has no choice but to do it twice if it wants a different color
dr|z3d
that makes sense.
zzz
gzip will make it all better :)
dr|z3d
it makes sense in one regard, but I'd question the notion it can't print out paths with a different stroke color.
dr|z3d
gzip does a great job, but removing the second path allows it to do an even better job :)
zzz
but then you only have one color, right?
dr|z3d
no
dr|z3d
because svg
dr|z3d
you take the filled path and add the stroke from the unfilled path.
dr|z3d
that's what my patch does.
dr|z3d
the stroke and fill colors can be whatever you like.
dr|z3d
in the peaks-dark.png example, that's a single path with a stroke color and a gradient fill.
zzz
I think it's actually the same color, but the fill is transparent and the outline isn't
dr|z3d
in rrd4j, sure, and maybe if you're using defaults in jfree. but you can modify that as you wish, as I've done in the dark example.
zzz
looks like parent color is null unless stacked, we don't use stacked
dr|z3d
yup, there we go. aka transparent :)
zzz
no, null != transparent
dr|z3d
well that's what we're getting, no? rga(0,0,0) with a fill-opacity of 0?
dr|z3d
*rgb
zzz
looking...
dr|z3d
something like that, might be 255,255,255 on light
zzz
I'm all spun around and I gotta run anyway, bbl
dr|z3d
aight, laters o/
zzz
ok
zzz
scratch what I said above about RrdGraph.drawData(), it's innocent, except for stack, which we don't use
zzz
for areas, and the two axis arrowheads, the offender is ImageWorker.fillPolygon() (the first one)
zzz
g2d.fillPolygon(xDev, yDev, xDev.length);
zzz
g2d.drawPolygon(xDev, yDev, xDev.length);
zzz
now, the color wasn't changed between those two calls
zzz
but if the area color has a decent amount of transparency, then drawPolygon() will make the border darker, because it has two layers
zzz
so it's pointless if the area color has alpha 255
zzz
if you don't want the dup path and are going to do your own polygon border shenanigans, the correct fix would be to override ImageWorker.fillPolygon() in SVGImageWorker
dr|z3d
up to you how you want to address it, easier just to post-edit the svg.
dr|z3d
(because you'll want to post-edit the svg in any event)