Changes in 2015

tt_su

I just noticed in one of my plugins that loading a single small skp file (to use as a component definition) seems to take almost 1 second whereas the same code in SU 2014 loads the skp instantly.

Is this with any SKP? Can you share that SKP?

tt_su

@dan rathbun said:

But I disagree! It does NOT return Float on ANY of the previous versions back to v8 that I have installed.

Confirmed - our source code has always been returning Length objects for Point3d members and Edge lengths.

Dan Rathbun

@tt_su said:

@dan rathbun said:

But I disagree! It does NOT return Float on ANY of the previous versions back to v8 that I have installed.

Confirmed - our source code has always been returning Length objects for Point3d members and Edge lengths.

Interestingly,... the API does not actually say what the return class is. IT says "value".

Dan Rathbun

@tt_su said:

@kaas said:

I just noticed in one of my plugins that loading a single small skp file (to use as a component definition) seems to take almost 1 second whereas the same code in SU 2014 loads the skp instantly.

Is this with any SKP? Can you share that SKP?

Bigger thumbnail = more loading time? (guessing)

tt_su

@dan rathbun said:

Interestingly,... the API does not actually say what the return class is. IT says "value".

Yea... one of the many improvements to be made.

kaas

@tt_su said:

Is this with any SKP? Can you share that SKP?
Any skp will take longer to load with that code in SU 2015 compared to SU2014.. at least on my system. Would like to see if anyone else could confirm or even better, have a solution.

Brighter3D

SU2015 can be installed in two versions 32 and 64bit.
Is there a way to check which is installed from ruby api?

Sketchup.version
returns: 15.0.9350

driven

from the API

 if Sketchup.respond_to?(;is_64bit?) && Sketchup.is_64bit?
   # Load 64bit binaries.
 else
   # Load 32bit binaries.
 end

Brighter3D

Thanks!

Brighter3D

Packing float value into two integers, and passing to double parameter function,
seems no longer works in 64bit SU2015.

passF = Win32API.new(mydll,"PassDouble",["L","L"],"V")

packedF = [rubyFloat].pack("D").unpack("LL")
passF.call(packedF[0],packedF[1])

Any tips?

wbarnes05

I noticed the change regarding the Length class a few days ago in the API. What's weird is that the API states that the parent of Length is Object starting in SU 2015. That had me worried as it implies that mathematical operations will no longer work on an instance of Length. However everything continued to work ok in my plugin when running in SU 2015.

I ran a few tests in 2015 and found the following:

length = 4.to_l
4"
length.is_a? Integer
false
length.is_a? Float
true
length.is_a? Length
true
length.class.superclass
Numeric
length.class.ancestors
[Length, Numeric, Comparable, Object, Kernel, BasicObject]

It would appear then that the API is incorrect and should be changed to show that Numeric is the parent class.

kaas

@dan rathbun said:

@kaas said:

I just noticed in one of my plugins that loading a single small skp file (to use as a component definition) seems to take almost 1 second whereas the same code in SU 2014 loads the skp instantly.

Bigger thumbnail = more loading time? (guessing)

I can't imagine. The box.skp testfile I created was just a rectangle with an extrusion.

Still looking for a solution. I tested all kinds of files and the result is always the same: loading a skp file as a component definition takes 2 to 3 times as much in SU2015 compared to SU2014 with the code above.
I tested disabling all plugins. I also tested loading SU2015 skp files (I wanted to rule out it took additional conversion time from SU2014 to SU2015).

Any suggestions / workarounds ?

slbaumgartner

@dan rathbun said:

Bigger thumbnail = more loading time? (guessing)

Seems unlikely to me unless it was programmed really badly. The thumbnail contains nothing that SketchUp needs for loading the file, so the loader should simply skip that part of the file with nearly zero impact on load time. Where a larger thumbnail would have an effect is on save or quit, when SU has to write the thumbnail. I think something else must be afoot, but at this point I have no clue what...

Steve

tt_su

@brighter3d said:

Packing float value into two integers, and passing to double parameter function,
seems no longer works in 64bit SU2015.

passF = Win32API.new(mydll,"PassDouble",["L","L"],"V")

packedF = [rubyFloat].pack("D").unpack("LL")
passF.call(packedF[0],packedF[1])

Any tips?

It's a bit vague - what exactly doesn't work of these calls? Do you see Ruby's packing methods returning different results?
Is the DLL you are calling actually 64bit?
Does the function you are calling actually use ints - or are you using some other type that might be different on 64bit OS?

On a side note - the Win32API has been deprecated for a long time. It has many limitations and is easy to cause crashes with. The recommended now is using Fiddle.

tt_su

@wbarnes05 said:

I noticed the change regarding the Length class a few days ago in the API. What's weird is that the API states that the parent of Length is Object starting in SU 2015. That had me worried as it implies that mathematical operations will no longer work on an instance of Length. However everything continued to work ok in my plugin when running in SU 2015.

I ran a few tests in 2015 and found the following:

length = 4.to_l
> 4"
> length.is_a? Integer
> false
> length.is_a? Float
> true
> length.is_a? Length
> true
> length.class.superclass
> Numeric
> length.class.ancestors
> [Length, Numeric, Comparable, Object, Kernel, BasicObject]

It would appear then that the API is incorrect and should be changed to show that Numeric is the parent class.

The API docs needs updating in general to make the hierarchy more clear. There are many inconsistencies. We have a big todo item to improve the whole developer site. Stay tuned.

@wbarnes05 said:

That had me worried as it implies that mathematical operations will no longer work on an instance of Length. However everything continued to work ok in my plugin when running in SU 2015.
We had to pull some tricky shimming to prevent breaking stuff. I wasn't able to do a 100% compatibility, but I think we have a near 99% use case coverage. Main one is C Extensions doing low level type checks for Floats which used to work, but not any more.

tt_su

@kaas said:

@dan rathbun said:

@kaas said:

I just noticed in one of my plugins that loading a single small skp file (to use as a component definition) seems to take almost 1 second whereas the same code in SU 2014 loads the skp instantly.

Bigger thumbnail = more loading time? (guessing)

I can't imagine. The box.skp testfile I created was just a rectangle with an extrusion.

Well, the simplicity of the model is one thing - but if out thumbnail generating code has become slower writing pixels then the model content doesn't matter...
This is still on our todo list to investigate.

kaas

@tt_su said:

Well, the simplicity of the model is one thing - but if out thumbnail generating code has become slower writing pixels then the model content doesn't matter...
This is still on our todo list to investigate.

just to be sure...My concern is not about writing skp files but about loading them. I don't see why it should be thumbnail issue.

driven

@kaas said:

I just noticed in one of my plugins that loading a single small skp file (to use as a component definition) seems to take almost 1 second whereas the same code in SU 2014 loads the skp instantly.

I ran a variation of your script in v13 and v15 on my mac...

t = Time.now
f = Sketchup.find_support_file('candle.skp', 'Components')
d = Sketchup.active_model.definitions.load f
puts (Time.now - t) 
#  all in different sessions of SU
# v13 => 0.146086 , 0.037117, 0.022029
# v15 => 0.033036, 0.046043,  0.013811

test skp, not complex...
john

Dan Rathbun

I was just guessing. The component browser DOES use the thumbnail if it is not set to display "List".

There used to be some time issues with thumbnails getting regenerated in the Component Browser.
Er.. or was that the Scene thumbnails ? It all blurs together.

Brighter3D

@unknownuser said:

t's a bit vague - what exactly doesn't work of these calls? Do you see Ruby's packing methods returning different results?
Is the DLL you are calling actually 64bit?
Does the function you are calling actually use ints - or are you using some other type that might be different on 64bit OS?

Yes dll is 64bit, I was passing double value as a pair of two ints. On c++ side it was double parameter, and call was passF.call(packedF[0],packedF[1]) on ruby side.

@unknownuser said:

On a side note - the Win32API has been deprecated for a long time. It has many limitations and is easy to cause crashes with. The recommended now is using Fiddle.

That solves my problem, it does work now - thank you!
It is a pity that there is no fiddle on SU < 2014 (with old ruby),
and I need to use ancient Win32API.so method for backward compatibility.