Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
|
From: SourceForge.net <noreply@so...> - 2006-07-29 17:20:40
|
Patches item #1520844, was opened at 2006-07-12 02:39 Message generated for change (Comment added) made by buliabyak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=604308&aid=1520844&group_id=93438 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jasper (jaspervdg) Assigned to: bulia byak (buliabyak) Summary: Improved rendering quality Initial Comment: This patches libnr/nr-pixops.h and libnr/nr-compose.cpp to make the compositing calculations more precise. This is done by making use of the fact that the intermediate calculations already use 32bit integers (unsigned int) by delaying normalization to the last possible moment. To accommodate this I restructured the operations in nr-pixops.h, mostly to reflect the precision of the arguments. In addition, some other files have been changed that also made use of the operations in nr-pixops.h, mostly to reflect the change in naming and make more use of the operations (in some cases the operations were still written out). Original e-mail: I've modified Inkscape to render at a slightly higher quality by avoiding repeated normalizations in libnr/nr-compose.cpp. I've uploaded examples of the results to: http://home.hccnet.nl/th.v.d.gronde/about-test-old.png http://home.hccnet.nl/th.v.d.gronde/about-test-new.png http://home.hccnet.nl/th.v.d.gronde/gradient-test-old.png http://home.hccnet.nl/th.v.d.gronde/gradient-test-new.png The first two are the current "about" drawing, exported to bitmap using Inkscape 0.44 (old) and reasonably current SVN+changes to compositing (new). The second two just show the gradient in background of the "about" drawing, which shows the "problem" with current version of Inkscape more clearly (if you have a hard time spotting the difference, look for a dark band in the upper left corner in the old image, it shouldn't be there, and it isn't in the new image). ---------------------------------------------------------------------- >Comment By: bulia byak (buliabyak) Date: 2006-07-29 21:20 Message: Logged In: YES user_id=741217 Jasper, I finally had a chance to test your compiled version on windows, and the speed difference is impressive - more than twice as fast compared to 0.44. About 10% of that is my optimizations in elliptic gradients that I did since 0.44, but the rest is yours :) So I committed the patch, even though it still makes it a bit slower on Linux. I also gave you developer access, so you can fix bugs if the emerge and do any further work. If you ever have a chance to test it on Linux, it would be nice if you could look into the reason of its being slower there. ---------------------------------------------------------------------- Comment By: Jasper (jaspervdg) Date: 2006-07-24 14:24 Message: Logged In: YES user_id=730345 I doubt the difference you're seeing is due to MMX being used, as the compositing functions that are used with these test files don't have MMX equivalents. But as I said, on my system "1600gradients.svgz" is rendered about equally fast with and without the patch, so it is entirely possible that under different circumstances it would be slightly slower (or faster). The other test file should render considerably faster with the patch though. I had some trouble attaching the compiled inkscape, so I uploaded it to: http://home.hccnet.nl/th.v.d.gronde/inkscape-precision.exe As for enabling MMX on Windows, I get the feeling it's using some Linux-only stuff (exec-shield?) and I don't feel very comfortable with GNU Assembly. What I could try is to use intrinsics to implement compositing functions using MMX instructions, but it would probably take me a while. ---------------------------------------------------------------------- Comment By: bulia byak (buliabyak) Date: 2006-07-23 22:07 Message: Logged In: YES user_id=741217 Thanks! Unfortunately fast3 is still a bit slower for me, by 1 or 2 seconds for the test files. You gave me an idea, maybe this is because you're on Windows and not using MMX code? I'm on Linux and MMX is compiled here. Can you please upload somewhere your Windows compiled versions (only the exe) with and without your patch, so I could test them on Windows? I promise to commit the patch if it turns out faster there :) Also, could you look into maybe enabling MMX on Windows too? Perhaps this will give a still bigger speedup? ---------------------------------------------------------------------- Comment By: Jasper (jaspervdg) Date: 2006-07-23 14:05 Message: Logged In: YES user_id=730345 Sorry about that, I now double checked that it indeed compiles and still has the desired effect. As for the MMX stuff, I'm afraid I haven't tested that as I couldn't get it to compile (didn't try really hard though, as it doesn't seem to be enabled on Windows anyway). ---------------------------------------------------------------------- Comment By: bulia byak (buliabyak) Date: 2006-07-23 00:23 Message: Logged In: YES user_id=741217 the fast2 version gives me a compile error: libnr/nr-pixops.h: In function `void nr_R8G8B8A8_P_R8G8B8A8_P_R8G8B8A8_P(unsigned char*, int, int, int, const unsigned char*, int, unsigned int)': libnr/nr-pixops.h:108: error: too few arguments to function `unsigned int NR_PREMUL_112(unsigned int, unsigned int)' libnr/nr-compose.cpp:427: error: at this point in file libnr/nr-compose.cpp: In function `void nr_R8G8B8A8_P_EMPTY_A8_RGBA32(unsigned char*, int, int, int, const unsigned char*, int, long unsigned int)': libnr/nr-compose.cpp:775: error: `spx' undeclared (first use this function) libnr/nr-compose.cpp:775: error: (Each undeclared identifier is reported only once for each function it appears in.) libnr/nr-compose.cpp:775: error: `srs' undeclared (first use this function) make[2]: *** [libnr/nr-compose.o] Error 1 make[2]: Leaving directory `/home/d/ink/inkscape/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/d/ink/inkscape' make: *** [all] Error 2 ---------------------------------------------------------------------- Comment By: Jasper (jaspervdg) Date: 2006-07-21 19:32 Message: Logged In: YES user_id=730345 The patch I'm attaching now (rendering-precision-fast2.patch) has the same precision as the original patch, is faster and fixes a few things. It still makes Inkscape render "gradient performance test.svgz" quite a bit faster than without the patch and "1600gradients.svgz" is rendered about equally fast as without the patch (on my system). It now also includes a reference implementation of nr-compose.cpp, as well as a small program to compare their outputs (more or less based on nr-translate-test.cpp). These files are excluded from the build by default btw. ---------------------------------------------------------------------- Comment By: Jasper (jaspervdg) Date: 2006-07-21 01:51 Message: Logged In: YES user_id=730345 I have created a reference implementation of the compositing functions and set up some tests based on that, and it seems there were some problems with the current code (as well as my patch). I've fixed the problems, but I'm still working on optimizing the code, so no revised patch yet. ---------------------------------------------------------------------- Comment By: Jasper (jaspervdg) Date: 2006-07-20 11:48 Message: Logged In: YES user_id=730345 Strange, because I tested with a very similar test file. Anyway, I managed to bring down the execution time of the compositing function that is used during rendering of your test file yesterday, and I'd like to test some more to see if there are any other bottlenecks remaining that I could eliminate. So I'll probably upload a revised patch again tonight. BTW, I don't mind you being picky at all, speed is important when it comes to rendering. (I attached my test file btw.) ---------------------------------------------------------------------- Comment By: bulia byak (buliabyak) Date: 2006-07-20 04:06 Message: Logged In: YES user_id=741217 I upped opacity of the clones' original to 1 in my file. The result is: 24.2 without your patch, 25.3 with it. So the difference is less than with opacity 0.5, but relatively to the total time it seems to be about the same, and your patch is still slower for me :( Sorry for being so picky, I just really care about speed. I think I will commit your patch regardless, because the slowdown is not so big and the quality improvement is worth it. I just wanted to ask you to maybe can try some more optimizing effort. Also, can you please attach a sample file on which your patch definitely gives a measurable speedup for you? ---------------------------------------------------------------------- Comment By: Jasper (jaspervdg) Date: 2006-07-19 00:50 Message: Logged In: YES user_id=730345 The main difference seems to be that in your test file the circles have their master opacity set to .5 (apparently this triggers use of a different compositing function). The triggered function is unfortunately one I found difficult to optimize, but I'll see if I can make it faster. BTW, on my system I can't really tell the difference in speed between the patched and unpatched versions for this file, but I would be nice to see if it can be made faster anyway. ---------------------------------------------------------------------- Comment By: bulia byak (buliabyak) Date: 2006-07-18 23:50 Message: Logged In: YES user_id=741217 Oops, here it is ---------------------------------------------------------------------- Comment By: Jasper (jaspervdg) Date: 2006-07-18 13:04 Message: Logged In: YES user_id=730345 I don't see any (new) attachments. ---------------------------------------------------------------------- Comment By: bulia byak (buliabyak) Date: 2006-07-18 08:54 Message: Logged In: YES user_id=741217 Thanks for the speed update! It's indeed much faster than before, but in my tests, it's still slower than before the patch. I attach the file which loads, renders and quits in 29 sec before the patch, 42 sec with the old version of the patch, and 31 sec with the new version. For you, is your patch slower or faster than unpatched Inkscape on this file? ---------------------------------------------------------------------- Comment By: Jasper (jaspervdg) Date: 2006-07-15 19:41 Message: Logged In: YES user_id=730345 Initial patch made rendering slower (probably due to the fact that it needed to divide by 65025 instead of 255). I have updated the patch to actually make rendering faster (without hurting quality). Gprof output shows compositing to be about twice as fast as the original from SVN on a test file suggested by Bulia (1600 overlapping circles with radial gradients), gradient rendering is also slightly faster. Measuring from the commandline with time also shows a speedup (but much less pronounced, due to overhead and the fact that gradient rendering is and was the main bottleneck in this situation). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=604308&aid=1520844&group_id=93438 |
