Unnecessarily slow Preview

[cebderby]

I had been using the Nightly as the last prod release was (presumably still is as no re-release) flickering badly with a very large model. However, during this year I've found Preview mode very slow, and have been ignoring the Nightly and using a 2018.02 AppImage I happened to have downloaded to try. This version has 2 advantages - fast Preview and double-click to set view focus (rotation, zoom centre). A later AppImage from 2018.04 is much more like the current Nightly.

For comparison, for models above a certain complexity, Preview rendering time is 4s for 2018.02 against an unpleasant/unusable 36s for Nightly. If it matters I'm using Mint 18.3 MATE 64bit.

I've been able to reproduce the problem with a trivial .scad file, in which the complexity can be changed by altering a single value, and a loop then generates some arbitrary geometry. Hopefully this works for others, the numbers may be different depending on CPU speed etc I guess. See attached.

progress_bar_36s_preview_time.scad.txt

My conclusion is that with the 2018.02 version, rendering time was up to 1s for the model plus up to 3s for the progress bar. And that for the current nightly, the same models take up to 2s for the model plus up to ~35s for the progress bar. (The model rendering time probably scaling linearly with complexity, the progress bar time linearly with the amount of time or fraction it is displayed).

Clearly having the progress bar take 3x (old) up to 15x (latest) the actual activity needs addressing, however my recommendation is that the progress bar is never shown for Preview, it's just too fast without! Presumably the progress bar for Render needs to be checked, in case it's wasting time there too.

Don't know why the newer version takes 2s rather than 1s for a big model, but that's secondary to the main issue.

If possible, it would be good if the old view is cleared from the screen as late as possible, so the new preview just appears directly after it, without a 'flash' of cleared screen between. That way the effect of tweaking a value and re-Preview can be seen the best.

I'd also love to see the return of double-click to set view focus too, if that's still possible (or ctrl-click or anything similar if there's a problem with double-click).

[t-paul]

Please share the infos from Help->Library info. I can't reproduce that at all on Debian/Testing with 2018.12.08.nightly (git c257783). With numitems = 9999 I still get instant preview. Also there is no flashing here. Maybe this is due to different graphics drivers.

Double click is a known issue but there's no general solution in sight yet. (#2466).

GLEW version: 2.0.0
OpenGL Version: 3.0 Mesa 18.2.6
GL Renderer: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2) 
GL Vendor: Intel Open Source Technology Center
RGBA(8880), depth(0), stencil(0)
GL_ARB_framebuffer_object: yes
GL_EXT_framebuffer_object: yes
GL_EXT_packed_depth_stencil: yes

Qt graphics widget: QOpenGLWidget
QSurfaceFormat: RGBA(8880), depth(0), stencil(0)

[MichaelPFrey]

What graphic card and driver are you using?
9999 works fine on Ubuntu 18.10 with an NVidia 710 and Proprietary driver.

[cebderby]

Interesting, so no progress bar at all I guess. Maybe you'd need to double up the amount of stuff created inside the loop if my hardware is working badly... the progress bar does have to appear for anything slow to happen.

Here's the corresponding section of output from my Help->Library info:
GLEW version: 1.13.0
OpenGL Version: 3.0 Mesa 18.0.5
GL Renderer: AMD BARTS (DRM 2.50.0 / 4.15.0-42-generic, LLVM 6.0.0)
GL Vendor: X.Org
RGBA(8880), depth(0), stencil(0)
GL_ARB_framebuffer_object: yes
GL_EXT_framebuffer_object: yes
GL_EXT_packed_depth_stencil: yes

Qt graphics widget: QOpenGLWidget
QSurfaceFormat: RGBA(8880), depth(0), stencil(0)

The card is a Radeon HD6870, not recent but well supported by the non-proprietary driver (allegedly). As far as I know the libraries are all up to date as far as Mint 18.3 is concerned, plus I manually installed the one newer (looks like it was OpenCSG-1.4.2) back in April which was needed.

[kintel]

To make this more interesting, this example actually crashes OpenSCAD during normalization on my debug Mac build..

[MichaelPFrey]

Maybe you'd need to double up the amount of stuff created inside the loop if my hardware is working badly... the progress bar does have to appear for anything slow to happen.

sure - Let me try

numitems=9999;
for (i = [1:numitems]) 
{
  translate([i*1.5,0,0])
  {
   sphere(1);
   cube([1,1,1]);
   cube([2,.4,1]);
  translate([0,0,2]){
         sphere(1);
   cube([1,1,1]);
   cube([2,.4,1]);
  }
  translate([0,0,4]){
         sphere(1);
   cube([1,1,1]);
   cube([2,.4,1]);
  }
  translate([0,0,6]){
         sphere(1);
   cube([1,1,1]);
   cube([2,.4,1]);
  }
  }
}

and I get as result

Compiling design (CSG Products normalization)...
WARNING: Normalized tree has 119988 elements!
WARNING: OpenCSG rendering has been disabled.
Compile and preview finished.
Total rendering time: 0 hours, 0 minutes, 13 seconds

which is fine by me.

I mean: Yes the preview starts reacting strangely, but that has more with the fact that the object is very thin relative to its size.
To truely find the limits of my machine I would have to use nested loops.

[cebderby]

Ok, hope you got the progress bar this time at least, starting from 0/1000?
For me, this more complex version takes 41s (and same time with or without the warning/disabled message depending on how high I set the preference for 'Turn off rendering at ... elements'). I also have the two cache size settings big eg 512000000 so it shouldn't be memory limited and hang.

This is just 4s more than to draw the original (1/4 as complex) version, which I reckoned was was taking 1 to 2s not counting the 35s for the full progress bar.

If you had the full progress bar from 0 upwards and took 13s, your machine is about 3x faster. Then I'd predict that you can preview anything in 1s if the progress bar doesn't appear at all, huge stuff in ~13s regardless of the exact size, with a rapid change from one to the other depending on how long the progress bar is up for. If you can get that, you're seeing what I have, just 3x less annoyingly slow.

[t-paul]

In debug mode the example from @MichaelPFrey takes 28 seconds here, commenting out the whole report_func() brings that down to 16 seconds. So I guess it's just the huge amount of callbacks being processed.

@kintel would #2343 help with the crash or this issue?

[kintel]

#2343 does indeed fix the crash - good call! Should look into getting that merged...

[thehans]

I remember doing some openscad profiling for an unrelated issue before, and noting that the progress bar updates alone took a significant portion of CPU for a small render (something like 1s out of a 3s preview). I had mentioned it in this issue, with corresponding flame chart: #2303

Maybe something about @cebderby's combination of desktop environment, hardware or drivers are particularly slow at redrawing progress bar widget which exacerbates this issue.

Regardless I think there should be some mechanism to throttle the progress bar update calls per second to say 60 or 30fps, by putting the update calls inside a QTimer set to that interval, and only redrawing if progress changed since last interval. Because doing 1000 updates every time is a bit excessive. I thought about it some but never got around to writing up a solution.

[t-paul]

Just changing the redraw will not help, commenting out the updateEvents call will cause the progress bar to never render, but it does not save any time. I guess the only way is to throttle at the source, not at the end of the call chain.

[MichaelAtOz]

I have also noted 'preview' performance issues for some models, back to at least 2015.03
Tho it is not so much preview ie F5 processing, the compilation etc, but the re/drawing of the preview panel.

If you want to see slow redraw add a higher $fn.
With Michael's code (with 9999), I added $fn=50 (don't, start lower 10 not so bad, 20 gets sloooowww).

This happened to be with 2018.11.04

There seems to be two parts to the 'refresh', the GUI redrawing [this is speculative from observing the elements] such as the window frame, console, editor, scroll bars, menus, icons etc, this takes ~4-15s, during which 'Not Responding' gets added to the window title.
[I'm speculating that the preview drawing is happening concurrently - slowing the rest of the GUI repaint?]

'Not Responding' then clears. The cursor is not yet flashing.
The normal console output has finished at this stage.

At this point it appears the drawing of the preview panel commences.
You can tell it has not repainted yet due to the residual image from another window still showing (while the rest of the GUI/editor shows normally). It takes seconds before that residual image is cleared.

OpenSCAD.exe is 100% of a core.
It is not hung, as I click the close button, it cycles periods of 'Not Responding' finally asking if I want to save.
Clicking Save, has it off thinking for a very long time, cycles of 'Not Responding'.
I eventually killed it.

Then played with lower $fn, 16-18 is a good example.
I have yet to compare this to other versions.
It does clearly show the various phases the OP describes.
Close observation also shows, to my eye, what appears to be unnecessary repainting and quick 'flashes' of the whole window.
Move the preview around, resize panels¹ or the window, or cover the window with another and uncovering shows the various repainting parts.
Keep an eye on whether the cursor is flashing.
GUI is very unresponsive to clicks or keyboard.

¹changing the editor v's preview width is almost impossible, as it tries to redraw for every mouse move.

This is expanding the window, it took approaching a minute to redraw, and happened in a few chunky stages:

Sorry for the rambling...

As a separate note I concur with OP re:

If possible, it would be good if the old view is cleared from the screen as late as possible, so the new preview just appears directly after it, without a 'flash' of cleared screen between.

This may be related to the time it takes to draw, but if the old image can be buffered, that would be useful in observing the difference in the new F5, rather than a long period of blanked panel.

[cebderby]

Thanks for the efforts/thinking on this. Yes, not repainting the main model view 1000? num elements? times could be the problem and answer. Suspending the repaints during the F5 processing would feel ok to me, then the old view of the model is definitely still there until the new view replaces it, as happens by chance at the moment if the F5 processing finishes before any CPU is (made) available to show the progress bar at all.

[thehans]

I implemented a throttle on the progress bar that I was thinking about. Using @MichaelPFrey's example code the preview time went from 15s to 4s for me.

[thehans]

I get 2s now with #2738

Edit: hmm, actually I get 2s I guess just from the change to 5 updates / sec apparently.

[cebderby]

Just tried the latest nightly (2019.01.30.nightly git f914a57) and getting the 1s/2s preview with the test cases and same with a very complex actual model. Only by turning all parts of that on - something I don't normally do - could I get the briefest flash of the progress bar, and that immediately gone, so this is nice.

For the time being, I have been running a self-compiled copy with the progress bar call (for the preview) disabled. I found that, in MainWindow::compileCSG(), there's a call with the report_prep function passed as the 2nd parameter, which I tried changing to nullptr. This was either going to cause a seg fault or not invoke the status bar, and it seems to be absolutely fine.

For any models that are ever going to be feasible for F6 rendering (ie 3 or 4 orders of magnitude smaller), the preview status bar is never seen anyway, and anyone with very large model is likely going to be happy with never seeing it, with the flash of cleared screen that goes with it.

It's good if there are possibilities of making the preview itself more efficient, but completely disabling the progress bar for preview as above seems best for me.

[nophead]

I can get preview bars lasting for 10 minutes or more during my first F5 because I have lots of renders, so I don't want it disabled completely.

How can 5 progress bar draws a second slow anything down?

[cebderby]

10 mins of F5? ouch! Then the current nightly is probably optimal.