If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

You probably don't follow Inkscape's development closely. Head over to inkscape.org, I have some news there for you

Holy crap!! At long last!! Inkscape is so painfully slow right now... and it's sad to see it only use one core of my quad-core system. Can't wait for that 0.49 version. I thought that performance work wouldn't appear until version 0.50. Good news indeed.

BTW, I do follow Inkscape's development and news, although not that frequently. A couple of weeks ago I read about some optimization work being worked on, but I was under the impression that it would take some time to materialize.

Comment

If one uses PBOs instead of buffer arrays then it should be faster and/or more energy effective because you don't have to transfer data back and forth.
Also, upgrading the GPU also improves performance, when I upgraded from 9600gt to gtx 560Ti the PBO read/write performance in my little test went up like 4 times!

So it's really mostly up to the quality of the source code and the solutions it uses.
Even if both the CPU and GPU solutions run equally fast (that is you have a newer CPU and older GPU) you should still use the GPU solution because it saves energy by doing less I/O.

But then there's still some folks with old hw that doesn't support PBOs yet (though it's a shame nowadays to not support PBOs) and some crappy drivers maybe.

"So it's really mostly up to the quality of the source code and the solutions it uses."

i think this is the only problem ;-)

right now it works.. but it makes mouse input lag... maybe they fix this in the future!..

then its maybe better maybe not faster on some old cards compared to new cpus but more energy efficiency sure

but right now it sucks!

Phantom circuit Sequence Reducer Dyslexia

Comment

The idea is to copy the data once, to a let a whole lot of filters do their thing and only then copy back. The copying back and forth to the GPU will always be the bottleneck. This benchmark gives the worst case scenario.

"The copying back and forth to the GPU will always be the bottleneck."

you are wrong in that point. the amd fusion3 with r900 (hd8000) graphic core do use the same 64bit address space and the same RAM as the CPU no copying back is needed!

BTW, I do follow Inkscape's development and news, although not that frequently. A couple of weeks ago I read about some optimization work being worked on, but I was under the impression that it would take some time to materialize.

As a matter of fact, the guy who works on performance in Inkscape had OpenCL based SVG filters in plans, but had to postpone it. He is still interested, though. We'll see how it works out

Comment

The people who actually patched GIMP to make FilmGIMP which later became Cinepaint were the very same people who later started GEGL to do everything properly (i.e. not like in FilmGIMP/Cinepaint). But sure, you know better about silver plates and whatnot. Facts are soooo boring, aren't they?

Easily verifiable. You nailed it. Actually this is what you should have done prior to posting ? studying facts. You could, for example, go and check who and when worked on both FilmGIMP and GEGL. And you could find a mail from one of the R&H folks to [email protected] from early December 2002 where he wrote about the R&H's perspective on both projects. Instead you seem to be holding a personal grudge against GEGL without having any clue about facts and you can't let go of it. Well, good luck spreading bullshit

Comment

EAnd you could find a mail from one of the R&H folks to [email protected] from early December 2002 where he wrote about the R&H's perspective on both projects. Instead you seem to be holding a personal grudge against GEGL without having any clue about facts and you can't let go of it. Well, good luck spreading bullshit

You could post links, but lets face it you enjoy flaming rather than having a civil conversation about vaporware.

Comment

You could post links, but lets face it you enjoy flaming rather than having a civil conversation about vaporware.

You mean a civil conversation is when you bullshit people instead of relying on facts and everyone nodes in agreement? I don't think so Yeah, I could post links, but how would bringing you facts "on a silver platter" possibly teach you to do research? I can help you to get started though.

Let me know if you have problems understanding whose exactly the joint “People doing a 16 bpc version of gimp” account was that features in both GIMP and GEGL logs.

The fact is, FilmGIMP/Cinepaint was, is and will be a crippled solution. R&H team started to redo it properly with GEGL, and even the new team led by Robin started to redo everything properly with Glasgow (and failed). That's because engineers don't fall for crippled solutions, even if you personally expect them to waste time doing the opposite.

You start investing time into support of architecturally wrong code, you have less time for the right thing, so you end up with people not using your software, because it sucks. The amount of downloads Cinepaint got over last 4 years the builds of stable GIMP for Windows get in mere 2.something days (check download stats at Sourceforge). Users are intelligent enough to know what's good for them. Yes, Cinepaint doesn't get as much attention as GIMP, but could it be because it has a retarded UI and a feature set from ten years ago at best?

Let's face it: on a purely technical level both Cinepaint and GIMP/GEGL projects have issues. But one of them is alive and the other one is dead no matter how many times project "lead" promises a new release "soon, very soon, maybe next week".

Note that I wouldn't have to write any of that if you had skills to do a very basic research. it's really amazing how easily people who can't let go of their fav project failure distract other people from discussing a project that's alive and well.