search

MaskedRetriever / SuperSkein

Open Source 3D Mesh Slicer in Processing: Generates gcode from stl files.
http://www.thingiverse.com/thing:3649
GNU General Public License v3.0
70 stars 11 forks source link

Text Boxes are SLOW #10

Closed MaskedRetriever closed 14 years ago

MaskedRetriever commented 14 years ago

Okay, either my home PC and netbook are both super-fast or Win7 made some serious improvements to haw Java runs-- either way anything older (which is really most PCs) can't handle my terrible text box code at anything like responsive speeds. Will work on this...

clothbot commented 14 years ago

I've filed Issue 359 with Processing (http://code.google.com/p/processing/issues/detail?id=359) in an effort to get createGraphics-based DXF export working. Once that's done we'll be able to switch back to the JAVA2D renderer to keep the UI light-weight.

MaskedRetriever commented 14 years ago

It's not just the P3D that's slowing down the text boxes-- I'm also convinced I'm doing some fairly stupid things with the text itself.

I might also note that if we want nice 3D graphics such as a Behold/Pleasant3D-like display we have to keep using P3D anyway...

clothbot commented 14 years ago

Got the DXF export bit working more cleanly and set the default renderer back to JAVA2D. If that speeds things up we could add some Configuration switches to match and manage the running hardware+OS capabilities and limitations.

MaskedRetriever commented 14 years ago

Ah! Configuration switches for varying levels of glitz! Great idea! When I'm mucking about in the UI code this weekend I'll give that a thought...

clothbot commented 14 years ago

Looks like nothing comes for free. Latest word from the Processing folks is RawDXF is preferred over the initial approach I took. I've had to bump the renderer up to P2D for it to work, but it also means I could write all layers to a single DXF file, one slice per layer.

I'll probably add a config option to switch between single-file/slice-per-layer and slice-per-file. Larger models could explode the single-file size, and some slice-processing algorithms may have trouble managing memory if they have to load the full file just to get at the layer/slice of interest.

MaskedRetriever commented 14 years ago

A note on memory-- In these modern times, most non-pathological meshes will fit comfortably into main memory, so holding an entire print worth of line segments in memory might not be a bad idea at all. So far I've been operating under the assumption we'll be able to get away with it, and in fact this may be the primary reason SuperSkein will keep beating Skeinforge even when it's got infill and shells.

clothbot commented 14 years ago

True. While I think of it, keep in mind the opportunities for multi-threading and GridEngine-style parallelism. That's where SuperSkein could beat Skeinforge by orders of magnitude.

MaskedRetriever commented 14 years ago

I think once we're using parallelism we should seriously be thinking about squooshing the code into a compiled library somehow-- that'd also speed things up.

Right now I'm getting /very/ fast slicing with SuperSkein of meshes I never would have even tried to SkeinForge, but I'm beginning to suspect I've been Doing It Wrong since others get much better results...

Have you done any benchmarking of a high-poly mesh in SuperSkein against, say, SkeinForge with no infill or shells?

MaskedRetriever commented 14 years ago

On the opposite end of things, GPUs can be used to launch hundreds of mini-processes in parallel, provided they don't touch each other's data-- slicing a file could be done quite /ridiculously/ fast if we had a separate, parallel machine running the code for each slice...

MaskedRetriever commented 14 years ago

Here are some things the GUI lag is NOT caused by:

The GUI lag is NOT caused by lengthy calls in mousePressed or keyTyped, since one or the other would stop lagging if I commented out all their code, which doesn't happen.

The GUI lag is NOT caused by the while() stubs buzzing on the other threads, since adding big delays to them does nothing for performance.

The GUI lag is not, to the best of my figuring so far, caused by lengthy draw calls-- wiping most of the UI doesn't help.

Still investigating whether we're somehow drawing stuff or fiddling with the mesh all the time but so far no dice.

clothbot commented 14 years ago

Perhaps some explicit use of of noLoop() calls would help?

MaskedRetriever commented 14 years ago

At the suggestion of a friend I got a look at what was happening to my processor usage when SuperSkein was running-- the results were pretty shocking as the primary core went to 100%!

Adding delays on the while() stubs actually helped this quite a lot, although it didn't fix the GUI delay. Given that, I think noLoop() would definitely help, since what may be happening is that (for some reason) the GUI is /waiting/ on those while stubs.

revarbat commented 14 years ago

I was able to speed it up a bit with noLoop() in setup, and a few redraw()s after mouse and key events, but it's still kind of slow. I think it's slow because it's having to check and redraw the entire window for each frame, instead of just updating the textbox. I'm not sure why it's still eating 100% CPU.

MaskedRetriever commented 14 years ago

That part is the while() stubs buzzing. On a micro with an RTOS, a while() stub is a great thing-- it uses next to no system resources because your RTOS only calls it once per scheduler frame. But on a big-ass desktop OS I think it's kind of the opposite, as the OS tries to get in /as many updates as at all possible/ to those threads.

Putting even modest (100ms) delays in after those while() stubs got me down to 33% or so...

MaskedRetriever commented 14 years ago

Okay, with Revar's addition of the noLoop stuff AND the while() stubs safely delayed, we're... BETTER. There's still some GUI lag which seems to /accumulate/ somehow but at least when you start up the system it's plenty fast. Calling this good enough for now-- we can re-visit later on.