 |
This happens instantly on my end, I can't believe this takes any longer than a few milliseconds. What are your system specs? |
 |
1.4 MHz system - and this symptom is relatively new (last few builds). I use this function all the time, and only then did I notice something changed. But I've narrowed it down to a dependance on map size (maybe). Open snow.map, and create a three-brush func_static like shown. Rotate that, and ESC-cancel the operation. For a map this size, I get a 2 second delay. On a small or empty map, I do get immediate results that you described. http://img411.imageshack.us/my.php?image=snowjb5.jpg To repeat though, I've always been using the same map for this test - in the last three or so drops, it's acting different. |
|
|
Confirmed, I can notice it in bonehoard.map, where even my system is lagging. I'll have to do some profiling in order to hunt this down, although I'm not sure I can do anything about it. |
 |
If I can recreate this on Linux I might be able to attack it with the debugger. |
|
|
It should behave the same on linux. I suspect that the [b]revertTransform()[/b] calls might be misplaced and affecting the whole scenegraph. I'll have a quick look of how I did this. |
|
|
Yep. That was it. I traversed the whole scenegraph with a revertTransform() call. I didn't suspect that this was so expensive. Anyway, it should be fixed now. |
|
|
If traversing the scenegraph is very expensive, this is an important piece of information regarding the renderer because AFAIK the graph is traversed every frame. |
|
|
Either that or the revertTransform() call that was applied to every visited "Transformable" instance. |
- Anonymous
