search

Spade-Editor / Spade

Cross-platform raster graphics editor inspired by Paint.NET
GNU General Public License v3.0
41 stars 10 forks source link

Somehow alleviate lag? #114

Closed SuperDisk closed 9 years ago

SuperDisk commented 9 years ago

I don't know if it's just for me, but the editor itself is monstrously "laggy;" that is, when you hover over something (eg. a menu item) it takes .25 seconds or so to light up, which while small is still pretty annoying.

Drawing with the pencil is a slow affair. All of this wouldn't be much of a problem if the old Paint.JAVA wasn't so speedy; Playing with https://github.com/markbernard/Paint.JAVA, it's swift and normal. The mainline Spade branch is slow. This is especially apparent when drawing on a moderately large image (1024x1024). Paint.JAVA handles it like a champ; Spade chokes.

I suspect WebLAF, since even mousing over GUI stuff it takes a bit for it to actually "respond" graphically. Either that, or I fear it's some added complexity in the core, which might be actually necessary to more complex features.

HeroesGrave commented 9 years ago

The old Paint.JAVA didn't have layers for a start.

Also on that branch the undo/redo system was incomplete (well, completely broken) due to the fact we had just switched to a new rendering system using Java2D, which additionally was inaccurate and inconsistent (you should've seen some of the circles it drew).

The new drawing system added since then probably won't be as fast as using Java2D, but it shouldn't be far behind. There may be some weird platform-specific things going on that cause more lag on some systems.

I'm currently investigating whether the way PaintCanvas scales up the image could be causing extra lag.

HeroesGrave commented 9 years ago

Have you tried exporting and running outside of Eclipse?

For some strange reason that gives me a massive boost to performance.

HeroesGrave commented 9 years ago

I finally found the source of the lag.

In all of my timings, I never once included the painting of the transparent background, and funnily enough, that was the source of the lag. It was taking about 15ms to paint, which is pretty much a full frame at 60fps.

Time to look into alternative approaches.

Edit: Hmm. I think I may be able to get a reasonable improvement by caching the transparent background.

BurntPizza commented 9 years ago

Is that this? https://github.com/Spade-Editor/Spade/blob/master/src/heroesgrave/spade/gui/PaintCanvas.java#L359-L367 I always cache that kind of thing as a hidden layer or tile a small image to fill the bg. Also probably reset the paint to whatever it was before (or null) if that affects the drawGrid section.

HeroesGrave commented 9 years ago

Yep. It's that little piece there.

BurntPizza commented 9 years ago

I typically avoid setPaint [for repeated calls], most paints seem pretty inefficient.

BurntPizza commented 9 years ago

I also recommend separating paint() into submethods, as that will allow a profiler to tell you exactly where the time is being spent, as well as making the code more clear.

HeroesGrave commented 9 years ago

Fixed. Uploading new build shortly.

BurntPizza commented 9 years ago

Consider keeping in mind to refactor large methods into calling multiple smaller ones in general, paint() stood out especially because it is over 3 pages on github+my monitor. IDEA would actually have probably issued a complexity warning.

HeroesGrave commented 9 years ago

I split it up a little bit, into composeImage (draw the layers onto one image), renderImage (draw the image to the canvas), and drawGrid (self-explanatory).

composeImage could probably be split up a little bit further but that's a job for another day.

SuperDisk commented 9 years ago

Sweet; What is the performance increase exactly? I'm not seeing the new commit.

HeroesGrave commented 9 years ago

Just committed then. Be aware I have just semi-broken plugin versioning. You now need to use X.Y.Z or X.Y.Z-SOME_TEXT. I've left a warning if it detects a bad version, but clean up any old plugins anyway.

Performance varied a bit before, but now on a single layered 512^2 image, frames vary between 10 and 15 ms when actively drawing. Each additional layer should add less than a millisecond and I haven't tested how image size affects things.

SuperDisk commented 9 years ago

Hey, hate to kill the buzz but it's still monstrously laggy for me. I suspect it's some form of buffering; Each update of a Change re-renders the entire image when it really should only update a rectangle of interest. I'll get on that when I have some free time.

HeroesGrave commented 9 years ago

Hmm, that is weird. At the very least it is still a major performance improvement (at least on my machine). We just might need some more.

Try profiling and see where the bottleneck is, now that I've separated the rendering into several functions.