If it's mainly because of OSX/macOS how about a Hackintosh? But I don't know how well it works with laptops. I never used OSX. The first thing i did with my MacBook Pro was formatting the HDD and installing Win7 
A matte screen cover on a tablet sounds very interesting. Which screen cover are you using?
The new MacBook Pro can't be repaired or upgraded anymore. The battery is glued in now and the CPU, RAM and even the SSD is soldered to the logic board!
https://www.ifixit.com/Teardown/MacBook+Pro+15-Inch+Touch+Bar+Teardown/73395
NO WAY! And all this combined with the mirror display and this unreasonable price... i think i have to replace the battery of my 2010 MacBook Pro (matte screen+ssd) and keep it a bit longer, until hopefully someone will build some Windows laptop with good design and macbook grade touchpad 
No answer to my question and an essay about building software instead that i will never read? ...should i give it a thumbs down now?
No, i don't think so... Ok, I'm out.
(just one last thing... RailClone and ForestPack are working great with their multi threading... but maybe Itoo is just dumb and the development was completely unneccessary... LOL these idiots!)
@garry k said:
Perhaps it is you who should explain !!
ok...
@unknownuser said:
@slbaumgartner said:
No 3D geometry model editing program has cracked this nut in at least two decades. There are fundamental computer science reasons why it regarded as essentially impossible.
@numerobis said:
%(#0080BF)[I'm fully aware that it wouldn't be possible for all operations (at least at the moment) But why not use it for tasks that can be multi-threaded, like background saving or file import/export, rendering, etc.?
Examples:
...
If there are better ways to improve the performance single threaded - no problem.]@slbaumgartner said:
Some of the things you list can and probably are passed to separate threads, whether explicitly by SketchUp or by the operating system. For example, file writes are usually buffered by the system and actually occur after the application's request returns control. So long as the model is frozen, multiple threads could be used for rendering. But some things have to wait. For example you can't save a model while it is in the midst of being updated! And, in SketchUp's case, nobody has figured out a way to use multiple threads to capture model geometry in a database simultaneously while presenting it to the user for editing.
@unknownuser said:
@slbaumgartner said:
There is nothing the SU team can do about the basic execution speed of Ruby. They do not develop the Ruby interpreter, they just embed it within SketchUp. Ruby is not designed as or advertised as a high-performance language.
@numerobis said:
If that's really the case and they are already at the limit of what ruby is capable to deliver, then i think they should rethink their "strategy" of relying completely on ruby code for standard operations like rounding edges or processing SUbD models.
@slbaumgartner said:
I suppose there could be further optimizations in the SketchUp Ruby API (which is the gateway between Ruby code and underlying compiled SketchUp code). For example, new methods that hand off more bulk operations to the compiled library instead of using Ruby step-by-step logic. Other apps get their speed by having these operations done by compiled code, not by a scripting language such as Ruby.
@numerobis said:
Like i said above, if it's not possible to speed up Ruby scripts, i think Trimble should do anything to either support the developers of these critical functions or implement them directly into the SU code.
@slbaumgartner said:
This is a misunderstanding (see also my other post). Only SketchUp extensions/plugins are written in Ruby. The core of the program is in C and/or C++. At this point in time, rounding edges and processing SubD models are not built into the core of SketchUp, they are extensions. The philosophy of SketchUp has always been to keep the core relatively simple...
So do you think it would have been better to tell him once more that i already know the difference between Ruby code and compiled code (e.g. C++)? And that i think that if it is not possible to speed up things in Ruby, they should find other ways, which of course would mean something other than Ruby, and most likely compiled code (what else?)?
And then i could have said once again, that i know it's not possible to use multi threading on every task, but that there are many examples of other programs where it has already been implemented successfully and more is planned so it seems to be possible for many tasks (...regardless of the "fundamental computer science reasons" that make it "essentially impossible").
And maybe i could have told him that i'm aware of the old story of the "philosophy" of SU to keep the core simple because i'm following the develeopent for more than 15 years now, and then say once again, that i think that such fundamental functions should be implemented into the code if there is no other way to make them run (MUCH) faster and then maybe that i don't think that some more functions will make it "bloated", especially such basic things like quads, subd or rounding edges.
And maybe then he could have answered that the SU team can't do anything to speed up the Ruby code and that SU is programmed in C++ and that it is not possible to use multi threading... Is that how you think the "conversation" should have been continued? But how many times?
Btw. i thought this was meant as a wishlist and not a thread for endless "discussions".
@unknownuser said:
LOL!!! Really? Who ever is downvoting this post... i would like to hear your explanation.
(maybe you have to re-read the posts above?!?)
@slbaumgartner said:
This is a misunderstanding (see also my other post). Only SketchUp extensions/plugins are written in Ruby. The core of the program is in C and/or C++. At this point in time, rounding edges and processing SubD models are not built into the core of SketchUp, they are extensions. The philosophy of SketchUp has always been to keep the core relatively simple so that the program doesn't become a bloated behemoth, and to allow specialized features to be added via extensions so that users can pick and choose which ones they really need.
@unknownuser said:
To repeat, the SketchUp team does not develop or implement Ruby, they just embed the interpreter into SketchUp.
@slbaumgartner said:
Some of the things you list can and probably are passed to separate threads, whether explicitly by SketchUp or by the operating system. For example, file writes are usually buffered by the system and actually occur after the application's request returns control. So long as the model is frozen, multiple threads could be used for rendering. But some things have to wait. For example you can't save a model while it is in the midst of being updated! And, in SketchUp's case, nobody has figured out a way to use multiple threads to capture model geometry in a database simultaneously while presenting it to the user for editing.
Are you kidding me? 
@fredo6 said:
For RoundCorner and SubD (and other plugins creating heavy geometry), the limitation is not due to Ruby but to the time needed by Sketchup to create the actual geometry in the model. It would be the same if you created it manually at the speed of Ruby.
Interesting.
@slbaumgartner said:
No 3D geometry model editing program has cracked this nut in at least two decades. There are fundamental computer science reasons why it regarded as essentially impossible. So, don't hold your breath!
I'm fully aware that it wouldn't be possible for all operations (at least at the moment) But why not use it for tasks that can be multi-threaded, like background saving or file import/export, rendering, etc.?
Examples:
Revit https://knowledge.autodesk.com/support/revit-products/troubleshooting/caas/sfdcarticles/sfdcarticles/Which-function-in-Revit-will-take-use-of-multiple-processors.html
ArchiCAD http://helpcenter.graphisoft.com/technotes/setup/software-technologies/multiprocessing-and-archicad/#Is_ArchiCAD_multi-threaded
Invertor https://knowledge.autodesk.com/support/inventor-products/troubleshooting/caas/sfdcarticles/sfdcarticles/Support-for-multi-core-processors.html
Some 3DSmax modifiers are already threaded (Bend, Skin, SkinWrap, Shell, PFlow, APEX Clothing, Delta Mush to Skin, etc.)
Not sure about Maya... i know that Maya API supports multi threading
cinema4d https://www.maxon.net/en/news/maxon-news/article/foundations-for-the-future/
Siemens NX (Parasolid) http://cadabout.ru/2016/10/28/a-few-words-about-siemens-nx-perfomance-cpu-graphic-adapter-memory-multi-core/
Grasshopper https://stevebaer.wordpress.com/2013/12/11/ghpython-node-in-code/
If there are better ways to improve the performance single threaded - no problem.
@slbaumgartner said:
In some ways this proposal is like the one a few years ago about the need for 64-bit support. They added it, and it turns out the pundits were right: the only real benefit was ability to use more memory for large models. It did not have a noticeable effect on the performance of SU.
I never said that 64bit would improve performance. But i can say that i experienced many crashes hitting the memory limit. Trust me... i know why i voted for 64bit 
@slbaumgartner said:
There is nothing the SU team can do about the basic execution speed of Ruby. They do not develop the Ruby interpreter, they just embed it within SketchUp. Ruby is not designed as or advertised as a high-performance language.
If that's really the case and they are already at the limit of what ruby is capable to deliver, then i think they should rethink their "strategy" of relying completely on ruby code for standard operations like rounding edges or processing SUbD models.
(Btw. as far as i know it's also possible to multi-thread Ruby code. I don't know about the SU implementation. https://www.tutorialspoint.com/ruby/ruby_multithreading.htm)
@slbaumgartner said:
I suppose there could be further optimizations in the SketchUp Ruby API (which is the gateway between Ruby code and underlying compiled SketchUp code). For example, new methods that hand off more bulk operations to the compiled library instead of using Ruby step-by-step logic. Other apps get their speed by having these operations done by compiled code, not by a scripting language such as Ruby.
Sophisticated programmers write the performance-critical parts of their extensions in compiled C/C++ code, which is much faster than Ruby. But they must still route their access to the SU model and library through the Ruby API bridge. They are compiled extensions to Ruby, not really compiled extension to SU itself. It isn't clear how much overhead that adds, but perhaps there could be a C/C++ API to bypass Ruby entirely (note: the existing SDK does not do so, it is for reading and writing SU files independent of the SU process).
Like i said above, if it's not possible to speed up Ruby scripts, i think Trimble should do anything to either support the developers of these critical functions or implement them directly into the SU code.
@dave r said:
What do you mean? And why won't you just try it and see for yourself?
Ok, i installed it now and i have to say that it doesn't feel faster than v2015. And it seems that the degradation kicks in earlier now compared to v2015, which is quite annoying and less usable (recovery time). With the degradation it is of course faster than the non degraded model in v2015 (e.g. ~16-25fps vs 10-11fps in v2015). But when i take a model that already degrades in v2015, so that i compare degraded vs degraded then they are both the same. No measurable difference.
It would be good if it would be possible to disable the auto degradation as it is in 3DSmax.
All tests without shadows and AA, i7 5960X@4.5GHz | GTX 970, 372.70, 2560x1440px | Win7
@dave r said:
There are improvements in SU2017. I can see them on my screen when I look at the model, can't you?
I didn't test it myself, i just reacted to the "new features" video.
So what are the improvements? How big are they? I can't believe that they made remarkable improvements and don't show them in their video, while they are promoting the stupiest small new features and fixes as if they wouldn't have to show anything else. So i think they should revise their marketing if they miss to show such important improvements. I didn't even bother to install 2017 after seeing this video, but maybe it is just misleading.
@rich o brien said:
There's no avoiding that 2017 out performs previous releases in terms of viewport performance.
Sorry, i can't see it. The earlier degradation is quite annoying.
@rich o brien said:
They're downplaying the change but the signs are there. 64bit only. No more software rendering. GPUs on OpenGL 3 or above. It's all geared towards a better viewport performance.
Sounds good. We'll see how it develops ...maybe next year.
@rich o brien said:
So it begs the question....what as users do we want in the viewport to help sell designs to clients?
Fancy shaders that bring specular reflections, matcap shaders for NPR, soft shadows, per-pixel shading, ambient occlusion etc....
I need faster geometry processing no fancy shaders.
@rich o brien said:
As a sidenote, upgrading the engine doesn't mean file imports are faster. SketchUp is a surface modeller and anytime you import a mesh it needs to rebuild it, heal edges, assign textures etc...
You can't benchmark it because everyone's setup is different.
You can benchmark it on the same system. Like with any other benchmark.
@rich o brien said:
Did anyone start a SketchUp 2018 Feature Request thread yet???
Seems rather pointless to me. Do you think they ever read them?
But i will copy my list from last year.
@juju said:
if it's texture related it will help a lot already seeing that the more textures you have in your model the bigger the file size and thus slower performance
I can't see an improvement. The degradation kicks in earlier than in v2015.
And i always use much smaller textures in the model than in the linked render material. And i doubt that it would be possible to use the original texture now. Even if the performance would be ok - the file size would be gigantic.
Ok, once again, almost the same as for 2013, 2014, 2015, 2016 and 2017...
(faster load/save and 64bit has been removed with 2015)
)and... since this is a wish list (i really don't think this will ever happen): non destructive and parametrical modeling using a modifier stack or node graphs. Maybe we'll see a ruby... this seems to be the only way this program will evolve in the future (as always).
...and a roadmap would be nice
@rich o brien said:
The 3D engine upgrade is what'll yield the biggest benefit in following releases.
Last time we had an upgrade was v7.1. But this release open ups a huge amount of scope in the viewport.
I hope you're right and it's a real improvement.
But what does "in following releases" mean? So there is no improvement now, but maybe in future release? Why not now?
Oh, please, not again... 
So a finally working offset tool, two new inference options and faster transparency are the top new features of 2017?!? How about the performance with 30 million non transparent faces? Or importing 3 million faces? Or executing ruby scripts?!?
I hope they saved the best new features for a second video...
But yeah, i always wished i could change the axis colors! Must have been really hard to implement! WOW! One color for every direction and i can adjust them separately! Well done.
Looks like another wasted year... unbelievable. 
Ok. Then once again: Thank you very much! 
Yes, you're right, it's working great now! Thank you very much! 
Do you have some donation account so that i can at least pay you the same $10 that i payed for the "useless" SceneExporterPro? 
Wow! That's great. Thanks for your effort!
Is it possible that the script is not working if only the shadow setting is stored in a scene? I only get 0KB files without file extension.
I have a "base scene" without sun angle and then many different scenes defining only date and time. So i select the "base" scene and then cycle through the "time" scenes and save them.
I have to say that i already bought the SceneExporterPro now and it seems to have the same problem.
Btw. would it be possible to make the selection dialog larger or scalable. Right now i can only see three or four of maybe 30 scenes which makes it a bit laborious to select them.
Sure, here is a simple demo scene.
I just separated the camera position(s) and the sun settings to be able to control them separately and maintain the same camera position.
I simply have one or more scenes that contain all camera and style settings and then i have multiple scenes that define only different sun positions (date and time). So i first select the camera defining "base"-scene and then after that i cycle through the scenes with the sun positions one by one and export the resulting images.