View Issue Details

IDProjectCategoryView StatusLast Update
0000237DarkRadiantGUIpublic01.05.2007 16:40
ReporterSneaksieDave Assigned Togreebo  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version0.9.0 
Fixed in Version0.9.0 
Summary0000237: ESC to cancel operation now takes very long
DescriptionThis is weird... Up till the last build, I specifically recall this taking a second or so at most. However now, if I rotate some brushes and then hit ESC to cancel the rotation before releasing the mouse, it takes around 8 seconds. DR is non-responsive during that time.

TagsNo tags attached.

Activities

greebo

greebo

25.03.2007 15:49

administrator   ~0000500

This happens instantly on my end, I can't believe this takes any longer than a few milliseconds. What are your system specs?
SneaksieDave

SneaksieDave

26.03.2007 14:36

developer   ~0000505

Last edited: 26.03.2007 14:37

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.

greebo

greebo

26.03.2007 15:44

administrator   ~0000507

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.
orbweaver

orbweaver

26.03.2007 16:00

developer   ~0000508

If I can recreate this on Linux I might be able to attack it with the debugger.
greebo

greebo

26.03.2007 16:06

administrator   ~0000509

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.
greebo

greebo

26.03.2007 16:14

administrator   ~0000510

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.
orbweaver

orbweaver

27.03.2007 17:23

developer   ~0000518

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.
greebo

greebo

27.03.2007 19:02

administrator   ~0000519

Either that or the revertTransform() call that was applied to every visited "Transformable" instance.

Issue History

Date Modified Username Field Change
25.03.2007 15:11 SneaksieDave New Issue
25.03.2007 15:49 greebo Note Added: 0000500
25.03.2007 15:49 greebo Assigned To => SneaksieDave
25.03.2007 15:49 greebo Status new => feedback
26.03.2007 14:36 SneaksieDave Note Added: 0000505
26.03.2007 14:37 SneaksieDave Note Edited: 0000505
26.03.2007 15:44 greebo Note Added: 0000507
26.03.2007 15:44 greebo Status feedback => confirmed
26.03.2007 15:44 greebo Status confirmed => assigned
26.03.2007 15:44 greebo Assigned To SneaksieDave => greebo
26.03.2007 16:00 orbweaver Note Added: 0000508
26.03.2007 16:06 greebo Note Added: 0000509
26.03.2007 16:14 greebo Status assigned => resolved
26.03.2007 16:14 greebo Fixed in Version => latest SVN
26.03.2007 16:14 greebo Resolution open => fixed
26.03.2007 16:14 greebo Note Added: 0000510
27.03.2007 17:23 orbweaver Note Added: 0000518
27.03.2007 19:02 greebo Note Added: 0000519
01.05.2007 16:40 SneaksieDave Status resolved => closed