Page 2 of 3

Re: Slow performance

PostPosted: 18 Feb 2010, 20:57
by DennisBergkamp
Hmm, I'm still not convinced, what was the old way of blurring/resizing ?

Re: Slow performance

PostPosted: 18 Feb 2010, 21:16
by silly freak
i think there was no blurring previously, but it looks really good. you can start a game and resize the picture panel to the 0.5 scale limit and compare with/-out blur. it really is a gain for small sizes. the configuration also seems very good

i think we just jeave it as it currently is until it makes problems

Re: Slow performance

PostPosted: 18 Feb 2010, 23:29
by DennisBergkamp
I see... but there's no way to do it the same way it was done originally?
It looked much better at first, I think. The small card images just looked completely smooth, now they're really jaggy. Or maybe this is just happening on my system?

Re: Slow performance

PostPosted: 18 Feb 2010, 23:57
by silly freak
do you have a screen? it shouldn't look as crappy as previously any more, and I can't confirm they're "really jaggy"

Re: Slow performance

PostPosted: 19 Feb 2010, 07:37
by DennisBergkamp
Actually, in ImageCache.java if you change the radius int parameter value that's passed into getBlurredImage from 3 to 6, things look awesome again :)
I just hope this won't cause too bad of a slowdown.

Re: Slow performance

PostPosted: 19 Feb 2010, 08:16
by Huggybaby
I don't know what kind of scaling algorithm you guys are using, but (if applicable) it's possible to provide the end user a selection from a variety of well known high speed varieties, and the code is readily available. See http://en.wikipedia.org/wiki/Pixel_art_ ... algorithms.

Re: Slow performance

PostPosted: 19 Feb 2010, 09:46
by Snacko
Those NxSai and Hqnx filters work good only for pixel art, like the one used in the snes games plus they are designed to enlarge only. Also they're quite slow and need quite a beefy computer (as in any core2).

Personally for me at radius 6 it looks like a blurred mess but each to his own.

Re: Slow performance

PostPosted: 19 Feb 2010, 18:08
by DennisBergkamp
Ok, I guess it's all personal preference then :)
Or perhaps it's system specific? On my computer 6 - 7 looks almost exactly the same it was the original way, using medium - large card sizes. 3 is just too jaggy (i'll post a screenshot).

I'll try to turn it into an menu option then ("blur radius"?), with values of something like 2 - 8.

Re: Slow performance

PostPosted: 19 Feb 2010, 20:47
by DennisBergkamp
Also, using LQ pics will definitely turn the small sized pics into a blurry mess when using a radius of 6.
HQ pics look jaggy though.

Re: Slow performance

PostPosted: 19 Feb 2010, 21:23
by Snacko
Yes, I haven't thought about HQ pics.
It is true that as the size increases the blur radius needs to increase as well to preserve the same relative blurriness.
~3 looks good for LQ and you need ~6-7 for HQ as you said

edit:
I've been testing scaling with a external library which does Lanczos scaling and the results are even better. However I'm not sure you want to make dependency on another jar.

Re: Slow performance

PostPosted: 19 Feb 2010, 22:47
by Huggybaby
Please, make the dependency.

Re: Slow performance

PostPosted: 19 Feb 2010, 23:03
by DennisBergkamp
How big is the Jar?
If it looks even better, it is probably worth it :)

Re: Slow performance

PostPosted: 20 Feb 2010, 14:05
by Snacko
It's like 40kB. I've also used a maven build of google collections which is a single jar, that's why I've removed jsr jar.

Re: Slow performance

PostPosted: 20 Feb 2010, 19:15
by DennisBergkamp
Very cool, Lanczos3 looks beautiful (also for HQ images scaling) :mrgreen:
Definitely worth the 40kb in my opinion.

Re: Slow performance

PostPosted: 20 Feb 2010, 19:27
by DennisBergkamp
Hmm, except, for some reason tapped images don't show anymore?
And performance seems pretty slow :(