Very slow performance after OS X 10.14 update #1250
Comments
|
There is most likely something going wrong with OpenGL drivers. |
|
iMac (Retina 5k, 27", Late 2015) |
|
In the Facebook group "Prusa Community Forum - Original Prusa MK2/2.5, MK3, MMU, and Custom Mods" I found some other people with the same issue. |
|
Quite often it is nearly impossible to asses and fix such issues without
getting our hands on the actual hardware / software. Let's see whether
somebody at Prusa Research will have such an issue.
…On Tue, Sep 25, 2018 at 9:45 AM skohls ***@***.***> wrote:
In the Facebook group "Prusa Community Forum - Original Prusa MK2/2.5,
MK3, MMU, and Custom Mods"
<https://www.facebook.com/groups/prusacommunity/> I found some other
people with the same issue.
https://www.facebook.com/groups/prusacommunity/permalink/854882688185798/
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1250 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFj5I9R-XCORuASA66jzJmTTttX0SD2mks5ued8CgaJpZM4W3zO8>
.
|
|
Let's hope so. If I can provide any logs I'll gladly do so - I just need some hints at what to provide. =^_^= |
|
Update: I tried the new beta 1.41.1 and it is just as slow. This is all using a large window - Slic3r gets noticeably faster when I reduce the window size... |
|
We are not sure whether we can help. It seems that the Cuppertino engineers hurried their product out of the door too early this time. Would you please report the issue to them? This is how the CPU load looks like on @FidelCapo 's new MacBook Pro after he upgraded to OSX Mojave: On @FidelCapo 's computer , even the file finder process causes such a high CPU load through the QuickLookUIService, and from my research it looks the Cuppertino enigneers have had this issue since the Mojave beta. |
|
I'll report it to Apple, no problem. The QuickLookUIService has been a pain for some time now, I even had to resort to an automatic kill-script in 10.13, killing the process when a certain load was reached. This service seems to be invoked all the time, e.g. user switching stalls, playing a movie in VLC stalls etc.. |
|
I've looked around a bit more - using the "top" command in the terminal. It shows Perl as the resource hog. |
|
I used to play with
https://www.perl.org/about/whitepapers/perl-profiling.html
and it worked quite well, but I did not use it for a long.
You would need to install the NYTProf into the Slic3r install tree, which
may be quite difficult if you are not familiar with perl.
Just moving the build plate in Slic3r around gets Perl up to 107% CPU
usage.
If the Slic3r window is shown, but there is no interaction from you, does
Slic3r use a lot of CPU?
…On Thu, Sep 27, 2018 at 5:33 PM skohls ***@***.***> wrote:
I've looked around a bit more - using the "top" command in the terminal.
It shows Perl as the resource hog.
"/Applications/Slic3r.app/Contents/MacOS/perl5.26.1
/Applications/Slic3r.app/Contents/MacOS/slic3r.pl"
Just moving the build plate in Slic3r around gets Perl up to 107% CPU
usage.
Can you point me into a direction to get more info out of this Perl
instance?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1250 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFj5I__C1V15yKl4OQs_QYUlXxexVEosks5ufO_SgaJpZM4W3zO8>
.
|
|
I'm not that familiar with Perl but I'll take a look, thanks. Regarding your question: |
|
does not happen for me, I use it since 10.14 beta 1 with no problems except the tab handlers not rendering, which was fixed in 10.14 beta 4 |
|
But I am on late 2017 MBP with Touch Bar, so maybe I just don't feel it |
Turns out to bee to difficult - it always complains about not finding something, I try to fix that and then it doesn't find another part... Is there a way you could build me a Slic3r app that would contain all the needed bells and whistles? So that I could run it and it would generate useful output for you to analyze? It only seems to be the GUI btw - slicing and generating gcode seems normal. On a side note - is it normal that the "Slice now" function runs after every little change automatically? Or did I miss a setting somewhere? I load an STL - it slices - I change one parameter - it slices etc... |
|
You have the background slice on, turn it off
pá 28. 9. 2018 v 9:28 odesílatel skohls <notifications@github.com> napsal:
… I used to play with
https://www.perl.org/about/whitepapers/perl-profiling.html and it worked
quite well, but I did not use it for a long. You would need to install the
NYTProf into the Slic3r install tree, which may be quite difficult if you
are not familiar with perl.
Turns out to bee to difficult - it always complains about not finding
something, I try to fix that and then it doesn't find another part...
Is there a way you could build me a Slic3r app that would contain all the
needed bells and whistles? So that I could run it and it would generate
useful output for you to analyze?
It only seems to be the GUI btw - slicing and generating gcode seems
normal.
On a side note - is it normal that the "Slice now" function runs after
every little change automatically? Or did I miss a setting somewhere? I
load an STL - it slices - I change one parameter - it slices etc...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1250 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AYr07TirgpTO8RQb60LLYXr6SL4SO6WTks5ufc-0gaJpZM4W3zO8>
.
|
|
Now that you mention it - I think I enabled something like „Process in Background“ but didn‘t make that connection in my head. Thanks.
… Am 28.09.2018 um 21:08 schrieb Patrik-svobodik ***@***.***>:
You have the background slice on, turn it off
pá 28. 9. 2018 v 9:28 odesílatel skohls ***@***.***> napsal:
> I used to play with
> https://www.perl.org/about/whitepapers/perl-profiling.html and it worked
> quite well, but I did not use it for a long. You would need to install the
> NYTProf into the Slic3r install tree, which may be quite difficult if you
> are not familiar with perl.
>
> Turns out to bee to difficult - it always complains about not finding
> something, I try to fix that and then it doesn't find another part...
>
> Is there a way you could build me a Slic3r app that would contain all the
> needed bells and whistles? So that I could run it and it would generate
> useful output for you to analyze?
>
> It only seems to be the GUI btw - slicing and generating gcode seems
> normal.
>
> On a side note - is it normal that the "Slice now" function runs after
> every little change automatically? Or did I miss a setting somewhere? I
> load an STL - it slices - I change one parameter - it slices etc...
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#1250 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AYr07TirgpTO8RQb60LLYXr6SL4SO6WTks5ufc-0gaJpZM4W3zO8>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Unfortunately it is not straightforward, it would cost me at least couple of hours. We are working on a C++ only build of slic3r now, it will be much easier to debug then. Did you guys get any feedback from Cuppertino? |
|
No feedback unfortunately. I submitted feedback to OS X but after sending the form there is only the generic "thanks you and we can't respond to everything personally" bla bla... |
|
Funny thing - when I use the "Cut" function in Slic3r I can put that window in full-screen mode and move the view around in real time, completely fluid and w/o any lag. |
|
I can confirm that orbiting, panning, as well as using the layers controls are essentially broken when using Slic3r in Mac OS X Mojave. My machine is a 2017 iMac 5K. Worked flawlessly before Cupertino went and changed something in Mojave. |
|
Lucky you... |
|
but other parts of the ui are really bad, but not as bad as you, I am running latest developer beta of Mojave |
|
It looks like something weird going on with WxWidgets and its compatibility with Mojave, I had this problem with earlier betas of Mojave with different apps, but I got this problem only with the GM build of Mojave and Slic3r PE, I don't get this problem now with other apps |
|
I think that this is likely an issue with the retina screens, and that the issue was always there but it was never so severe as it is in Mojave. I have a 2017 iMac 5K 27" with 24 GB of RAM and a Radeon Pro 580 with 8 GB of VRAM, and I also have an old non-retina 1920x1080 screen connected to it via HDMI. Apple definitely did something in Mojave, and indeed deprecated OpenGL in favor of Metal 2 (https://developer.apple.com/macos/whats-new/), but hopefully this doesn't mark the beginning of the end of Slic3r PE on Mac. For the record, my own system info is: Slic3r Prusa Edition Summary of my perl5 (revision 5 version 26 subversion 1) configuration: Platform: @inc: GL_APPLE_aux_depth_stencil |
|
The Slic3r PE is based on obsolete wxWidgets 3.0.3, which does not support
retina displays. We are currently getting rid of the remains of the Perl
interpreter, along the way we are updating to wxWidgets 3.1. Let's keep our
fingers crossed, that this will solve this issue.
…On Sun, Oct 14, 2018, 00:46 Daniele Nicolucci ***@***.***> wrote:
I think that this is likely an issue with the retina screens, and that the
issue was always there but it was never so severe as it is in Mojave.
I have a 2017 iMac 5K 27" with 24 GB of RAM and a Radeon Pro 580 with 8 GB
of VRAM, and I also have an old non-retina 1920x1080 screen connected to it
via HDMI.
Moving Slic3r to the non-retina screen, even maximized, makes the 3D view
unbelievably fast, faster than I ever saw it run on the retina screen.
Bringing it back onto the retina screen makes the interface way sluggish,
though making it smaller definitely helps (as shown in @Patrik-svobodik
<https://github.com/Patrik-svobodik>'s video, which was made on a laptop:
the 2017 MBP has 2880x1800 actual pixels, i.e. 1440x900 "points" in
retina-speak; the iMac 5K display has 5120x2880 actual pixels, i.e.
2560x1440 "points").
That's probably also why the cut preview is faster, and indeed it was
faster on High Sierra too: there are just fewer pixels to deal with.
Apple definitely did something in Mojave, and indeed deprecated OpenGL in
favor of Metal 2 (https://developer.apple.com/macos/whats-new/), but
hopefully this doesn't mark the beginning of the end of Slic3r PE on Mac.
For the record, my own system info is:
Slic3r Prusa Edition
Version: 1.41.0+
Build: Slic3rPE-1.41.0+full-201809010756
Operating System: darwin
System Architecture: darwin-thread-multi-2level
System Version: Darwin ytsejam 18.0.0 Darwin Kernel Version 18.0.0: Wed
Aug 22 20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64 x86_64
Summary of my perl5 (revision 5 version 26 subversion 1) configuration:
Platform:
osname=darwin
osvers=13.4.0
archname=darwin-thread-multi-2level
uname='darwin mavericks-build-vm.local 13.4.0 darwin kernel version
13.4.0: sun aug 17 19:50:11 pdt 2014; root:xnu-2422.115.4~1release_x86_64
x86_64 '
config_args='-de -Dprefix=/Users/prusa3d/perl5/perlbrew/perls/perl-5.26.1
-Duserelocatableinc -Dusethreads
-Aeval:scriptdir=/Users/prusa3d/perl5/perlbrew/perls/perl-5.26.1/bin'
hint=recommended
useposix=true
d_sigaction=define
useithreads=define
usemultiplicity=define
use64bitint=define
use64bitall=define
uselongdouble=undef
usemymalloc=n
default_inc_excludes_dot=define
bincompat5005=undef
Compiler:
cc='cc'
ccflags ='-fno-common -DPERL_DARWIN -mmacosx-version-min=10.9
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
-I/opt/local/include -DPERL_USE_SAFE_PUTENV'
optimize='-O3'
cppflags='-fno-common -DPERL_DARWIN -mmacosx-version-min=10.9
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
-I/opt/local/include'
ccversion=''
gccversion='4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)'
gccosandvers=''
intsize=4
longsize=8
ptrsize=8
doublesize=8
byteorder=12345678
doublekind=3
d_longlong=define
longlongsize=8
d_longdbl=define
longdblsize=16
longdblkind=3
ivtype='long'
ivsize=8
nvtype='double'
nvsize=8
Off_t='off_t'
lseeksize=8
alignbytes=8
prototype=define
Linker and Libraries:
ld='cc'
ldflags =' -mmacosx-version-min=10.9 -fstack-protector -L/usr/local/lib
-L/opt/local/lib'
libpth=/usr/local/lib
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/lib
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib
/usr/lib /opt/local/lib
libs=-lpthread -ldbm -ldl -lm -lutil -lc
perllibs=-lpthread -ldl -lm -lutil -lc
libc=
so=dylib
useshrplib=false
libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs
dlext=bundle
d_dlsymun=undef
ccdlflags=' '
cccdlflags=' '
lddlflags=' -mmacosx-version-min=10.9 -bundle -undefined dynamic_lookup
-L/usr/local/lib -L/opt/local/lib -fstack-protector'
@inc <https://github.com/inc>:
/Users/jollino/Desktop/3D/Slic3r.app/Contents/MacOS/local-lib/lib/perl5/5.26.1/darwin-thread-multi-2level
/Users/jollino/Desktop/3D/Slic3r.app/Contents/MacOS/local-lib/lib/perl5/5.26.1
/Users/jollino/Desktop/3D/Slic3r.app/Contents/MacOS/local-lib/lib/perl5/darwin-thread-multi-2level
/Users/jollino/Desktop/3D/Slic3r.app/Contents/MacOS/local-lib/lib/perl5
/Users/jollino/Desktop/3D/Slic3r.app/Contents/MacOS/lib
/Users/jollino/Desktop/3D/Slic3r.app/Contents/lib/site_perl/5.26.1/darwin-thread-multi-2level
/Users/jollino/Desktop/3D/Slic3r.app/Contents/lib/site_perl/5.26.1
/Users/jollino/Desktop/3D/Slic3r.app/Contents/lib/5.26.1/darwin-thread-multi-2level
/Users/jollino/Desktop/3D/Slic3r.app/Contents/lib/5.26.1
OpenGL installation
GL version: 2.1 ATI-2.0.36
Vendor: ATI Technologies Inc.
Renderer: AMD Radeon Pro 580 OpenGL Engine
GLSL version: 1.20
Installed extensions:
GL_APPLE_aux_depth_stencil
GL_APPLE_client_storage
GL_APPLE_element_array
GL_APPLE_fence
GL_APPLE_float_pixels
GL_APPLE_flush_buffer_range
GL_APPLE_flush_render
GL_APPLE_object_purgeable
GL_APPLE_packed_pixels
GL_APPLE_pixel_buffer
GL_APPLE_rgb_422
GL_APPLE_row_bytes
GL_APPLE_specular_vector
GL_APPLE_texture_range
GL_APPLE_transform_hint
GL_APPLE_vertex_array_object
GL_APPLE_vertex_array_range
GL_APPLE_vertex_point_size
GL_APPLE_vertex_program_evaluators
GL_APPLE_ycbcr_422
GL_ARB_color_buffer_float
GL_ARB_depth_buffer_float
GL_ARB_depth_clamp
GL_ARB_depth_texture
GL_ARB_draw_buffers
GL_ARB_draw_elements_base_vertex
GL_ARB_draw_instanced
GL_ARB_fragment_program
GL_ARB_fragment_program_shadow
GL_ARB_fragment_shader
GL_ARB_framebuffer_object
GL_ARB_framebuffer_sRGB
GL_ARB_half_float_pixel
GL_ARB_half_float_vertex
GL_ARB_imaging
GL_ARB_instanced_arrays
GL_ARB_multisample
GL_ARB_multitexture
GL_ARB_occlusion_query
GL_ARB_pixel_buffer_object
GL_ARB_point_parameters
GL_ARB_point_sprite
GL_ARB_provoking_vertex
GL_ARB_seamless_cube_map
GL_ARB_shader_objects
GL_ARB_shader_texture_lod
GL_ARB_shading_language_100
GL_ARB_shadow
GL_ARB_shadow_ambient
GL_ARB_sync
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_compression_rgtc
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar
GL_ARB_texture_env_dot3
GL_ARB_texture_float
GL_ARB_texture_mirrored_repeat
GL_ARB_texture_non_power_of_two
GL_ARB_texture_rectangle
GL_ARB_texture_rg
GL_ARB_transpose_matrix
GL_ARB_vertex_array_bgra
GL_ARB_vertex_blend
GL_ARB_vertex_buffer_object
GL_ARB_vertex_program
GL_ARB_vertex_shader
GL_ARB_window_pos
GL_ATI_blend_equation_separate
GL_ATI_blend_weighted_minmax
GL_ATI_separate_stencil
GL_ATI_texture_compression_3dc
GL_ATI_texture_env_combine3
GL_ATI_texture_float
GL_ATI_texture_mirror_once
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_bindable_uniform
GL_EXT_blend_color
GL_EXT_blend_equation_separate
GL_EXT_blend_func_separate
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_clip_volume_hint
GL_EXT_debug_label
GL_EXT_debug_marker
GL_EXT_depth_bounds_test
GL_EXT_draw_buffers2
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_framebuffer_blit
GL_EXT_framebuffer_multisample
GL_EXT_framebuffer_object
GL_EXT_framebuffer_sRGB
GL_EXT_geometry_shader4
GL_EXT_gpu_program_parameters
GL_EXT_gpu_shader4
GL_EXT_multi_draw_arrays
GL_EXT_packed_depth_stencil
GL_EXT_packed_float
GL_EXT_provoking_vertex
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_shadow_funcs
GL_EXT_stencil_two_side
GL_EXT_stencil_wrap
GL_EXT_texture_array
GL_EXT_texture_compression_dxt1
GL_EXT_texture_compression_s3tc
GL_EXT_texture_env_add
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_integer
GL_EXT_texture_lod_bias
GL_EXT_texture_mirror_clamp
GL_EXT_texture_rectangle
GL_EXT_texture_sRGB
GL_EXT_texture_sRGB_decode
GL_EXT_texture_shared_exponent
GL_EXT_timer_query
GL_EXT_transform_feedback
GL_EXT_vertex_array_bgra
GL_IBM_rasterpos_clip
GL_NV_blend_square
GL_NV_conditional_render
GL_NV_depth_clamp
GL_NV_fog_distance
GL_NV_light_max_exponent
GL_NV_texgen_reflection
GL_NV_texture_barrier
GL_SGIS_generate_mipmap
GL_SGIS_texture_edge_clamp
GL_SGIS_texture_lod
GL_SGI_color_matrix
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1250 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFj5I7wer76KYoawTm9xLcaaZk6pSttIks5ukm1PgaJpZM4W3zO8>
.
|
|
@jollino you are actually right, if I make the window small it is really fast and smooth, but if I maximize it it is slow |
|
Can you please try on your macs attached build? This build is in development and most things are not working here. Please try to only insert the object if performance has improved. Please also provide me the full specification of yours macs. Thank you. Slic3rPE-1.42.0-alpha+113-dev-native-full-gb9b404d-201810151050.dmg.zip |
|
@FidelCapo Same issues here: slow on retina screen, especially with bigger windows; blazing fast on non-retina. iMac (Retina 5K, 27-inch, 2017), aka iMac18,3 About the GPU and screens in particular: Radeon Pro 580: |
|
Can't open a file in this Slic3r build, it crashes immediately. Just rotating the empty build plate shows the same performance problem tho. Modellname: iMac AMD Radeon R9 M390: Chipsatz-Modell: AMD Radeon R9 M390 |
|
Hi. I've been looking into this and it looks like it's a wxWidgets event loop / repainting problem (cf. 440fbb1). Here's a beta build that we hope should fix the problem: Would you guys please try out the above build and report if it's an improvement? Thanks! |
|
Works great here (iMac 5K 27" 2017), thanks! |
|
The beta build is fast again (in high resolution) and doesn't hit on the CPU anymore. Is this build otherwise fully useable or should we better not use it "normally"? |
It should be useable normally, it's the same as the last official release plus a few bugfixes :) |
|
Seems to be working properly for me as well. |
|
Note that resizing the window is still slow; a very minor issue, obviously, but I thought I'd mention it. :) |
I didn't try it at first but yes, resizing the window is still slow - which is not an issue for me as well. |
|
3D Views are fast. Resizing is slow. Text input in boxes is slow. |
|
The 3D view is soooo fast now, but the UI is still slow |
Yes. My change in that commit basically makes the 3D scene go around wxWidgets. |
|
Is there a separate github issue for the slow UI and text input? That portion is still not fixed in 1.41.2+ on most machines running Mojave. There seems to be almost exactly a 1000ms delay when an event is triggered when mouse clicking on a tab, textbox, checkbox or while typing etc. 2015 iMac 5k Retina running 10.14.1 |
|
@FidelCapo do you see this 1 second lag as well?
…On Mon, Nov 26, 2018 at 2:57 AM ctilley83 ***@***.***> wrote:
Is there a separate github issue for the slow UI and text input? That
portion is still not fixed in 1.41.2+ on most machines running Mojave.
There seems to be almost exactly a 1000ms delay when an event is triggered
when mouse clicking on a tab, textbox, checkbox or while typing etc.
2015 iMac 5k Retina running 10.14.1
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1250 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFj5I3616DrMZMrYQnPfV_5p4dQTLWkzks5uy0qQgaJpZM4W3zO8>
.
|
|
It seems to me that the delay is little shorter than 1 second on my macbook pro. |
|
On my it is shorter too
po 26. 11. 2018 v 12:10 odesílatel HurkaF <notifications@github.com> napsal:
… It seems to me that the delay is little shorter than 1 second on my
macbook pro.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1250 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AYr07ezeFIO3h3Ci2AsxH55lJcFebqBoks5uy8wLgaJpZM4W3zO8>
.
|
|
That is because it is CPU bound. Typing and resizing window jumps >100% CPU usage, so people with different CPUs will see different results. |
|
It's related to screen resolution not the cpu. I'm not seeing the CPU spike. When I maximize the window to fill more screen space the delay is much longer than when I manually resize the window to 800X800 pixels. The delay almost disappears at that size. This explains why the delay is shorter on Fidel's MacBook Pro vs my iMac. This is also true when typing in text boxes, so it seems slic3r is redrawing the whole interface after every change. |
|
I did not say it is related to CPU. I just said it is eating lots of CPU when doing resize/text input so people can see differences based on CPU performance. And yes, your observation adds on top of that. |
Gotcha. I knew CPU load was what you meant, I just wasn't seeing it. Sorry for the Misunderstanding. |
|
I downloaded regular slic3r and version 1.30 does not have the issue of laggy keyboard input in text boxes or the lag when checking boxes etc. Slow OpenGL performance, and slow clicking between tabs is still there, but it's strange that keyboard input works fine in that version. |
|
The upcoming Slic3r 1.42 alpha will only send updates about the change of the text field after the text field loses focus, so the text editing is much more fluent now. Closing. |
|
For technical reference: https://developer.apple.com/library/archive/technotes/tn2133/_index.html |
|
@jollino you wrote on facebook that you have now an issue with PrusaSlicer 2.0.0-rc. |
I haven't used any of the 1.42 alphas as I stayed on 1.41. I actually use 1.41 in low res mode because examining the layers (i.e. looking "into" the sliced model) is what is slow; rotating the view has been fixed. The same issue happens with 2.0.0-rc, actually.
Retina screen, high-resolution app, high-resolution 3d rendering (in preferences): 60 fps when rotating the screen, 2-4 fps when using the vertical slider to look into the model; this is with PrusaSlicer pretty much full screen, save for the menu bar and the Dock. Even the slider itself lags behind the pointer. Same settings, but on the non-retina 1080p screen pretty much full screen save for the menu bar (no Dock on this one): 60 fps both when panning around AND when using the slider. However, if I enable "Open in Low Resolution" in the file info window in the Finder, I can keep the window to almost full screen (again just except the menu bar and Dock) and I get the same 20-ish fps when using the slider, which would be fine. 20 fps is perfectly acceptable as the slider is generally used very gently while looking into the model, but 2-4 fps is slow enough that it feels extremely clunky, see https://youtu.be/lnwgyLPFsLY All of this happens exactly the same way with 1.41. Let me know if you want me to run any other tests. :) Model Name: iMac Radeon Pro 580: Displays: DELL U2212HM: |
|
I see, so the issue now is the slow update of the screen when manipulating
the layer slider in the FDM mode.
Thanks for the report.
…On Thu, May 16, 2019 at 2:51 PM Daniele Nicolucci ***@***.***> wrote:
@jollino <https://github.com/jollino> you wrote on facebook that you have
now an issue with PrusaSlicer 2.0.0-rc.
Is it now worse than with the Slic3r 1.42.0-alpha?
I haven't used any of the 1.42 alphas as I stayed on 1.41. I actually use
1.41 in low res mode because examining the layers (i.e. looking "into" the
sliced model) is what is slow; rotating the view has been fixed. The same
issue happens with 2.0.0-rc, actually.
Would you please measure the frame rate with
https://www.macgamerhq.com/count-it-mac-frame-rate/ ? What is your frame
rate on your low res screen, and what is the frame rate on your high res
screen?
Retina screen, high-resolution app, high-resolution 3d rendering (in
preferences): *60 fps* when rotating the screen, *2-4 fps* when using the
vertical slider to look into the model; this is with PrusaSlicer pretty
much full screen, save for the menu bar and the Dock. Even the slider
itself lags behind the pointer.
If I reduce the window to around 1/4 of the full screen, the slider
refreshes the view at around *20 fps* (and doesn't feel bad at all.)
Same settings, but on the non-retina 1080p screen pretty much full screen
save for the menu bar (no Dock on this one): *60 fps* both when panning
around AND when using the slider.
If I disable "Use Retina resolution for the 3D scene" within the
Prefences, it's exactly the same on both screens; looks like that setting
just changes the size of the model in pixel, but doesn't change how it's
actually rendered.
However, if I enable "Open in Low Resolution" in the file info window in
the Finder, I can keep the window to almost full screen (again just except
the menu bar and Dock) and I get the same *20-ish fps* when using the
slider, which would be fine.
20 fps is perfectly acceptable as the slider is generally used very gently
while looking into the model, but 2-4 fps is slow enough that it feels
extremely clunky, see https://youtu.be/lnwgyLPFsLY
*All* of this happens *exactly* the same way with 1.41.
Let me know if you want me to run any other tests. :)
------------------------------
Model Name: iMac
Model Identifier: iMac18,3
Processor Name: Intel Core i7
Processor Speed: 4.2 GHz
Number of Processors: 1
Total Number of Cores: 4
L2 Cache (per Core): 256 KB
L3 Cache: 8 MB
Memory: 24 GB
Radeon Pro 580:
Chipset Model: Radeon Pro 580
Type: GPU
Bus: PCIe
PCIe Lane Width: x16
VRAM (Total): 8 GB
Vendor: AMD (0x1002)
Device ID: 0x67df
Revision ID: 0x00c0
ROM Revision: 113-D000AA-931
VBIOS Version: 113-D0001A1X-025
EFI Driver Version: 01.00.931
Metal: Supported, feature set macOS GPUFamily2 v1
Displays:
iMac:
Display Type: Built-In Retina LCD
Resolution: 5120x2880 Retina
Framebuffer Depth: 30-Bit Colour (ARGB2101010)
Main Display: Yes
Mirror: Off
Online: Yes
Rotation: Supported
Automatically Adjust Brightness: No
DELL U2212HM:
Resolution: 1920x1080 (1080p FHD - Full High Definition)
UI Looks like: 1920 x 1080 @ 60 Hz
Framebuffer Depth: 30-Bit Colour (ARGB2101010)
Display Serial Number: Y9KCH25L0D0L
Mirror: Off
Online: Yes
Rotation: Supported
Automatically Adjust Brightness: No
Connection Type: DVI or HDMI
Adapter Firmware Version: 7.55
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#1250?email_source=notifications&email_token=ABMPSI4C6AA773H73ZTCPG3PVVKFXA5CNFSM4FW7GO6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVRWTLA#issuecomment-493054380>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABMPSI2OO2QMETWT3CJKCKDPVVKFXANCNFSM4FW7GO6A>
.
|
|
So here is our update.
We believe that you should get the same slow refresh rates if you rotate
camera in the layer view, as if you move the slider in the layer view. The
culprit is the huge amount of triangles generated for the FDM layer view,
and the slow rendering into a huge number of pixels. The frame rate should
be dependent on the window size and on the model complexity. Would you
please confirm that?
There is not much we can do about it for the current release. In the
future, we may try some magic (rendering only the paths that are visible,
using advanced techniques like the OpenGL tesselation shaders, we may try
shading only the pixels visible).
…On Thu, May 16, 2019 at 3:03 PM bubnikv ***@***.***> wrote:
I see, so the issue now is the slow update of the screen when manipulating
the layer slider in the FDM mode.
Thanks for the report.
On Thu, May 16, 2019 at 2:51 PM Daniele Nicolucci <
***@***.***> wrote:
> @jollino <https://github.com/jollino> you wrote on facebook that you
> have now an issue with PrusaSlicer 2.0.0-rc.
> Is it now worse than with the Slic3r 1.42.0-alpha?
>
> I haven't used any of the 1.42 alphas as I stayed on 1.41. I actually use
> 1.41 in low res mode because examining the layers (i.e. looking "into" the
> sliced model) is what is slow; rotating the view has been fixed. The same
> issue happens with 2.0.0-rc, actually.
>
> Would you please measure the frame rate with
> https://www.macgamerhq.com/count-it-mac-frame-rate/ ? What is your frame
> rate on your low res screen, and what is the frame rate on your high res
> screen?
>
> Retina screen, high-resolution app, high-resolution 3d rendering (in
> preferences): *60 fps* when rotating the screen, *2-4 fps* when using
> the vertical slider to look into the model; this is with PrusaSlicer pretty
> much full screen, save for the menu bar and the Dock. Even the slider
> itself lags behind the pointer.
> If I reduce the window to around 1/4 of the full screen, the slider
> refreshes the view at around *20 fps* (and doesn't feel bad at all.)
>
> Same settings, but on the non-retina 1080p screen pretty much full screen
> save for the menu bar (no Dock on this one): *60 fps* both when panning
> around AND when using the slider.
> If I disable "Use Retina resolution for the 3D scene" within the
> Prefences, it's exactly the same on both screens; looks like that setting
> just changes the size of the model in pixel, but doesn't change how it's
> actually rendered.
>
> However, if I enable "Open in Low Resolution" in the file info window in
> the Finder, I can keep the window to almost full screen (again just except
> the menu bar and Dock) and I get the same *20-ish fps* when using the
> slider, which would be fine.
>
> 20 fps is perfectly acceptable as the slider is generally used very
> gently while looking into the model, but 2-4 fps is slow enough that it
> feels extremely clunky, see https://youtu.be/lnwgyLPFsLY
>
> *All* of this happens *exactly* the same way with 1.41.
>
> Let me know if you want me to run any other tests. :)
> ------------------------------
>
> Model Name: iMac
> Model Identifier: iMac18,3
> Processor Name: Intel Core i7
> Processor Speed: 4.2 GHz
> Number of Processors: 1
> Total Number of Cores: 4
> L2 Cache (per Core): 256 KB
> L3 Cache: 8 MB
> Memory: 24 GB
>
> Radeon Pro 580:
> Chipset Model: Radeon Pro 580
> Type: GPU
> Bus: PCIe
> PCIe Lane Width: x16
> VRAM (Total): 8 GB
> Vendor: AMD (0x1002)
> Device ID: 0x67df
> Revision ID: 0x00c0
> ROM Revision: 113-D000AA-931
> VBIOS Version: 113-D0001A1X-025
> EFI Driver Version: 01.00.931
> Metal: Supported, feature set macOS GPUFamily2 v1
>
> Displays:
> iMac:
> Display Type: Built-In Retina LCD
> Resolution: 5120x2880 Retina
> Framebuffer Depth: 30-Bit Colour (ARGB2101010)
> Main Display: Yes
> Mirror: Off
> Online: Yes
> Rotation: Supported
> Automatically Adjust Brightness: No
>
> DELL U2212HM:
> Resolution: 1920x1080 (1080p FHD - Full High Definition)
> UI Looks like: 1920 x 1080 @ 60 Hz
> Framebuffer Depth: 30-Bit Colour (ARGB2101010)
> Display Serial Number: Y9KCH25L0D0L
> Mirror: Off
> Online: Yes
> Rotation: Supported
> Automatically Adjust Brightness: No
> Connection Type: DVI or HDMI
> Adapter Firmware Version: 7.55
>
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub
> <#1250?email_source=notifications&email_token=ABMPSI4C6AA773H73ZTCPG3PVVKFXA5CNFSM4FW7GO6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVRWTLA#issuecomment-493054380>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABMPSI2OO2QMETWT3CJKCKDPVVKFXANCNFSM4FW7GO6A>
> .
>
|
Reducing the amount of pixels does help, be it by forcing the app to run in low-resolution, moving it to a low-resolution screen or just reducing the window size on a high-res screen (which is why I believe it's less of an issue on MacBook Pros). However the model's complexity does not seem to have much of an effect on the issue: I just loaded an stl of a cube with no features, and it's still very sluggish in a big window on a high-res screen. I even tried setting the infill to 0% so it only has to draw the perimeters and it's the same. Moreover, I just noticed that CPU usage jumps to 140-150% when moving the slider up and down; it's as if it's not using the GPU at all for that. Rotating the camera in layer view just uses 10% of less CPU, and works at 60 fps regardless. This does not happen when rotating the camera in the layer view, which runs very smoothly at 60 fps regardless of window size, model and settings, and uses less than 10% of the CPU (I'm not sure if this is related to the fix of #1250 (comment)). A quick practical workaround is just to open the app in low-res, anyway: it doesn't make much of a difference. :) |
|
Thanks for the update. We certainly do not see such behavior, or maybe we have a different threshold of pain. We will try to improve the layer slider. I don't think that #1250 (comment) or #1250 (comment) has anything to do with your issue. |
Version
1.41.0+
Operating system type + version
macOS Mojave 10.14 (18A391
Behavior
Slic3r is really slow since the OS update. Every action takes "time to think" before a reaction happens. Everything seems to function, just really sluggish.
Is this a new feature request?
no
STL/Config (.ZIP) where problem occurs
any STL
config.ini.zip
Slic3r Prusa Edition
Version: 1.41.0+
Build: Slic3rPE-1.41.0+full-201808301409
Operating System: darwin
System Architecture: darwin-thread-multi-2level
System Version: Darwin imacintranet.local 18.0.0 Darwin Kernel Version 18.0.0: Wed Aug 22 20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64 x86_64
Summary of my perl5 (revision 5 version 26 subversion 1) configuration:
Platform:
osname=darwin
osvers=13.4.0
archname=darwin-thread-multi-2level
uname='darwin mavericks-build-vm.local 13.4.0 darwin kernel version 13.4.0: sun aug 17 19:50:11 pdt 2014; root:xnu-2422.115.4~1release_x86_64 x86_64 '
config_args='-de -Dprefix=/Users/prusa3d/perl5/perlbrew/perls/perl-5.26.1 -Duserelocatableinc -Dusethreads -Aeval:scriptdir=/Users/prusa3d/perl5/perlbrew/perls/perl-5.26.1/bin'
hint=recommended
useposix=true
d_sigaction=define
useithreads=define
usemultiplicity=define
use64bitint=define
use64bitall=define
uselongdouble=undef
usemymalloc=n
default_inc_excludes_dot=define
bincompat5005=undef
Compiler:
cc='cc'
ccflags ='-fno-common -DPERL_DARWIN -mmacosx-version-min=10.9 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/opt/local/include -DPERL_USE_SAFE_PUTENV'
optimize='-O3'
cppflags='-fno-common -DPERL_DARWIN -mmacosx-version-min=10.9 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/opt/local/include'
ccversion=''
gccversion='4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)'
gccosandvers=''
intsize=4
longsize=8
ptrsize=8
doublesize=8
byteorder=12345678
doublekind=3
d_longlong=define
longlongsize=8
d_longdbl=define
longdblsize=16
longdblkind=3
ivtype='long'
ivsize=8
nvtype='double'
nvsize=8
Off_t='off_t'
lseeksize=8
alignbytes=8
prototype=define
Linker and Libraries:
ld='cc'
ldflags =' -mmacosx-version-min=10.9 -fstack-protector -L/usr/local/lib -L/opt/local/lib'
libpth=/usr/local/lib /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/lib /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib /usr/lib /opt/local/lib
libs=-lpthread -ldbm -ldl -lm -lutil -lc
perllibs=-lpthread -ldl -lm -lutil -lc
libc=
so=dylib
useshrplib=false
libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs
dlext=bundle
d_dlsymun=undef
ccdlflags=' '
cccdlflags=' '
lddlflags=' -mmacosx-version-min=10.9 -bundle -undefined dynamic_lookup -L/usr/local/lib -L/opt/local/lib -fstack-protector'
@inc:
/private/var/folders/x4/87cpzrvd69n47b0cj3pq_rjw0000gn/T/AppTranslocation/8F0B6E44-FF53-43F4-BDAA-46510C5569C6/d/Slic3r.app/Contents/MacOS/local-lib/lib/perl5/5.26.1/darwin-thread-multi-2level
/private/var/folders/x4/87cpzrvd69n47b0cj3pq_rjw0000gn/T/AppTranslocation/8F0B6E44-FF53-43F4-BDAA-46510C5569C6/d/Slic3r.app/Contents/MacOS/local-lib/lib/perl5/5.26.1
/private/var/folders/x4/87cpzrvd69n47b0cj3pq_rjw0000gn/T/AppTranslocation/8F0B6E44-FF53-43F4-BDAA-46510C5569C6/d/Slic3r.app/Contents/MacOS/local-lib/lib/perl5/darwin-thread-multi-2level
/private/var/folders/x4/87cpzrvd69n47b0cj3pq_rjw0000gn/T/AppTranslocation/8F0B6E44-FF53-43F4-BDAA-46510C5569C6/d/Slic3r.app/Contents/MacOS/local-lib/lib/perl5
/private/var/folders/x4/87cpzrvd69n47b0cj3pq_rjw0000gn/T/AppTranslocation/8F0B6E44-FF53-43F4-BDAA-46510C5569C6/d/Slic3r.app/Contents/MacOS/lib
/private/var/folders/x4/87cpzrvd69n47b0cj3pq_rjw0000gn/T/AppTranslocation/8F0B6E44-FF53-43F4-BDAA-46510C5569C6/d/Slic3r.app/Contents/lib/site_perl/5.26.1/darwin-thread-multi-2level
/private/var/folders/x4/87cpzrvd69n47b0cj3pq_rjw0000gn/T/AppTranslocation/8F0B6E44-FF53-43F4-BDAA-46510C5569C6/d/Slic3r.app/Contents/lib/site_perl/5.26.1
/private/var/folders/x4/87cpzrvd69n47b0cj3pq_rjw0000gn/T/AppTranslocation/8F0B6E44-FF53-43F4-BDAA-46510C5569C6/d/Slic3r.app/Contents/lib/5.26.1/darwin-thread-multi-2level
/private/var/folders/x4/87cpzrvd69n47b0cj3pq_rjw0000gn/T/AppTranslocation/8F0B6E44-FF53-43F4-BDAA-46510C5569C6/d/Slic3r.app/Contents/lib/5.26.1
OpenGL installation
GL version: 2.1 ATI-2.0.36
Vendor: ATI Technologies Inc.
Renderer: AMD Radeon R9 M390 OpenGL Engine
GLSL version: 1.20
Installed extensions:
GL_APPLE_aux_depth_stencil
GL_APPLE_client_storage
GL_APPLE_element_array
GL_APPLE_fence
GL_APPLE_float_pixels
GL_APPLE_flush_buffer_range
GL_APPLE_flush_render
GL_APPLE_object_purgeable
GL_APPLE_packed_pixels
GL_APPLE_pixel_buffer
GL_APPLE_rgb_422
GL_APPLE_row_bytes
GL_APPLE_specular_vector
GL_APPLE_texture_range
GL_APPLE_transform_hint
GL_APPLE_vertex_array_object
GL_APPLE_vertex_array_range
GL_APPLE_vertex_point_size
GL_APPLE_vertex_program_evaluators
GL_APPLE_ycbcr_422
GL_ARB_color_buffer_float
GL_ARB_depth_buffer_float
GL_ARB_depth_clamp
GL_ARB_depth_texture
GL_ARB_draw_buffers
GL_ARB_draw_elements_base_vertex
GL_ARB_draw_instanced
GL_ARB_fragment_program
GL_ARB_fragment_program_shadow
GL_ARB_fragment_shader
GL_ARB_framebuffer_object
GL_ARB_framebuffer_sRGB
GL_ARB_half_float_pixel
GL_ARB_half_float_vertex
GL_ARB_imaging
GL_ARB_instanced_arrays
GL_ARB_multisample
GL_ARB_multitexture
GL_ARB_occlusion_query
GL_ARB_pixel_buffer_object
GL_ARB_point_parameters
GL_ARB_point_sprite
GL_ARB_provoking_vertex
GL_ARB_seamless_cube_map
GL_ARB_shader_objects
GL_ARB_shader_texture_lod
GL_ARB_shading_language_100
GL_ARB_shadow
GL_ARB_shadow_ambient
GL_ARB_sync
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_compression_rgtc
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar
GL_ARB_texture_env_dot3
GL_ARB_texture_float
GL_ARB_texture_mirrored_repeat
GL_ARB_texture_non_power_of_two
GL_ARB_texture_rectangle
GL_ARB_texture_rg
GL_ARB_transpose_matrix
GL_ARB_vertex_array_bgra
GL_ARB_vertex_blend
GL_ARB_vertex_buffer_object
GL_ARB_vertex_program
GL_ARB_vertex_shader
GL_ARB_window_pos
GL_ATI_blend_equation_separate
GL_ATI_blend_weighted_minmax
GL_ATI_separate_stencil
GL_ATI_texture_compression_3dc
GL_ATI_texture_env_combine3
GL_ATI_texture_float
GL_ATI_texture_mirror_once
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_bindable_uniform
GL_EXT_blend_color
GL_EXT_blend_equation_separate
GL_EXT_blend_func_separate
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_clip_volume_hint
GL_EXT_debug_label
GL_EXT_debug_marker
GL_EXT_depth_bounds_test
GL_EXT_draw_buffers2
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_framebuffer_blit
GL_EXT_framebuffer_multisample
GL_EXT_framebuffer_object
GL_EXT_framebuffer_sRGB
GL_EXT_geometry_shader4
GL_EXT_gpu_program_parameters
GL_EXT_gpu_shader4
GL_EXT_multi_draw_arrays
GL_EXT_packed_depth_stencil
GL_EXT_packed_float
GL_EXT_provoking_vertex
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_shadow_funcs
GL_EXT_stencil_two_side
GL_EXT_stencil_wrap
GL_EXT_texture_array
GL_EXT_texture_compression_dxt1
GL_EXT_texture_compression_s3tc
GL_EXT_texture_env_add
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_integer
GL_EXT_texture_lod_bias
GL_EXT_texture_mirror_clamp
GL_EXT_texture_rectangle
GL_EXT_texture_sRGB
GL_EXT_texture_sRGB_decode
GL_EXT_texture_shared_exponent
GL_EXT_timer_query
GL_EXT_transform_feedback
GL_EXT_vertex_array_bgra
GL_IBM_rasterpos_clip
GL_NV_blend_square
GL_NV_conditional_render
GL_NV_depth_clamp
GL_NV_fog_distance
GL_NV_light_max_exponent
GL_NV_texgen_reflection
GL_NV_texture_barrier
GL_SGIS_generate_mipmap
GL_SGIS_texture_edge_clamp
GL_SGIS_texture_lod
GL_SGI_color_matrix
The text was updated successfully, but these errors were encountered: