optimizations

[tj]

I dont know python so i cant really do much there, but quite a few important optimizations could be made, namely the extra function calls required to do all the lame "super"ing etc

[HBehrens]

Thank you for that hint. To safely remove these super calls the conversion script has to look at the class hierarchy and overridden methods to determine if a super call is really necessary. That's definitely doable. Can you do me a favor and provide a prominent examples of such a case?

[tj]

for sure, one second

[tj]

    function Rect(x, y, width, height) {
        this.x = x;
        this.y = y;
        this.width = width;
        this.height = height;
    }

    function Box(x, y, width, height) {
        Rect.apply(this, arguments);
    }

[tj]

extra overhead in the constructors the way they are now just worries me due to how often these objects are created in a system like this, otherwise it wouldnt be much of a big deal. accessors (get/set) are slow as well, best to avoid when possible

[HBehrens]

I'd rather like to discuss this issue on actual code of the project. For which "class" exactly did you measure a performance impact in which cases? "Rect" and "Box" are just fictitious, right?

[tj]

yeah, just examples. I'm just saying if have a tight loop (which all canvas rendering does) spawning tons of shapes / colors etc it will get expensive quick. it's fine if you dont want to, I already started a fork

[HBehrens]

In my cases, colors and shapes were created only once. During rendering I am just rendering the coordinates and apply them to the actual visualization code (I am not talking about DebugDraw, here). Anyway, I am looking forward to your measurement results. Based on these we will be able to proof what changes have which performance effects.