Go Back   SmartClient Forums > Technical Q&A
Wiki Register Search Today's Posts Mark Forums Read

Reply
 
Thread Tools Search this Thread
  #1  
Old 26th Feb 2010, 12:30
senordhuff
Guest
 
Posts: n/a
Default Slow script error occurring only when ListGrid columns are grouped

Hello,

We are seeing a persistent "slow script" warning with Firefox 3.6 against SmartClient 6.5.1. And, we've even isolated the code via isc.Timer.setTimeout() so this refreshRow() code is executing by itself. But, it is still causing a slow script error. If we ungroup the columns in the ListGrid, the slow script error does not happen. But, when they are grouped, it happens consistently.

Here is what the firebug "slow script" stack looks like below. Any ideas on a way to resolve this? If you are interested in seeing the problem in action, I can provide you a login to our environment. Just email me off list.


Code:
 ....loading....
$ed()
add()
getParents()
isFolder()
$52u()
getCellValue()
(?)()
$22k()
refreshCellValue()
refreshCellValue()
refreshCell()
refreshRow()
error()
fireCallback()
$in()
ISC_Core...5.1.js()
Reply With Quote
  #2  
Old 26th Feb 2010, 12:48
Isomorphic Isomorphic is offline
Administrator
 
Join Date: May 2006
Posts: 38,988
Default

If you enable the "redraws" log are you seeing that the refreshRow ultimately leads to a full redraw()? If so, what reason is reported?
Reply With Quote
  #3  
Old 26th Feb 2010, 13:15
senordhuff
Guest
 
Posts: n/a
Default

I changed the redraws log category to "DEBUG" and then executed the sequence that causes this to happen. I think the first two redraws are just the result of me clicking on a drop-down option and the third is the redraw causing the problem. Is there something else I need to do in order to provide more information?

Code:
16:06:49.054:INFO:redraws:isc_PickListMenu_3662_body:Scheduling redraw (setColumnWidths)
16:06:49.071:INFO:redraws:isc_PickListMenu_3662_body:Immediate redraw of dirty widget (pickList sizing)
16:06:49.256:RDQ0:DEBUG:redraws:clearRedrawQueue: 0 redraws (1 items), 0ms
Reply With Quote
  #4  
Old 26th Feb 2010, 14:41
Isomorphic Isomorphic is offline
Administrator
 
Join Date: May 2006
Posts: 38,988
Default

Actually those logs indicate no redraws other than the PickList (which is expected).

However the stack does suggest that getCellValue is causing the tree to be rebuilt. If you have getCellValue() overridden or any formatters installed, is there something you're doing, perhaps a setEditValue() or similar, that might explain the need to rebuild the group tree?
Reply With Quote
  #5  
Old 1st Mar 2010, 08:58
senordhuff
Guest
 
Posts: n/a
Default

Hi there, I was sending incorrect output before, here is the statement showing the grid redraw. This is getting called because of a call in my code to grid.markForRedraw():

11:44:02.239:TMR5:INFO:redraws:fundAssetsGrid:Scheduling redraw (8 children) (no reason provided) [Stack trace logged via Firebug: FBugTrace4]


I am seeing this problem in a grouped grid with 1 row showing and only 2 visible columns. I think the issue is probably related to the fact this grid has about 180 columns although all but 2 are hidden for this test.

Here is another stacktrace below that is a bit different than the first one I sent. Any suggestions on how to figure this out? We've got a very important end user who wants this resolved. And, it happens in both IE and Firefox.

Code:
 ....loading....
getParents()
getParents()
isFolder()
$52u()
getCellValue()
makeBodyMethods
$22k()
getTableHTML()
shouldUs...dRatio()
invokeSuper()
$ct()
$282()
$px()
modifyContent()
invokeSuper()
drawVisibleChunks()
$ra()
redrawIfDirty()
invokeSuper()
modifyContent()
invokeSuper()
redraw()
finalEval()
redrawPr...nPeers()
$ra()
redrawIfDirty()
invokeSuper()
redraw()
clearRedrawQueue()
fireCallback()
$in()
ISC_Core...5.1.js()
Reply With Quote
  #6  
Old 1st Mar 2010, 10:43
Isomorphic Isomorphic is offline
Administrator
 
Join Date: May 2006
Posts: 38,988
Default

Hi Dave,

Can you enable the "redrawTrace" log category - this will log a stack trace when a redraw occurs with no "reason" specified. This should make it clear how you're ending up with a redraw.

Also, capturing stack traces in IE is much better (Firebug has trouble even getting the names right, much less providing all the additional SC-specific information we include in IE traces).
Reply With Quote
  #7  
Old 1st Mar 2010, 11:23
senordhuff
Guest
 
Posts: n/a
Default

Hi, I know exactly why the grid redraw is happening. My code is calling grid.markForRedraw(). The problem is that the grid has 1 row and 2 columns and still gets stuck in multiple slow script errors when nothing else is happening on the screen other than this call to grid.markForRedraw(). I think there is some problem related to this grid having 180 columns in it although only 2 are visible at the moment. We have no such issues when grouping is turned off. But, with grouping on, the slow script errors are persistent.

The reason I was sticking with Firebug is because I haven't found a way to debug a "slow script" error in IE whereas Firebug gives you that "Debug Script" button. And, I find that the IE Developer toolbar brings IE to a crawl when I try to use it.

However, I did enable both Redraw and Redraw Trace in IE and here is the stack below from the developer console. Thoughts on what to do next?

Code:
14:15:30.406:TMR4:INFO:redraws:fundAssetsGrid:Scheduling redraw (8 children) (no reason provided)
    Canvas.$q9(_1=>undef, _2=>undef)
    Canvas.markForRedraw(_1=>undef)
    refreshDataFAGrid(grid=>[ATListGrid ID:fundAssetsGrid], fundAssetList=>Array[1])
    removeLSTableRecord(record=>Obj, type=>"FundAsset")
    loadLSTable(dsName=>"FundAsset", record=>Obj, rowNum=>null, frequency=>"60", singleUpdate=>null, parentRecordObj=>null, forceNewTable=>true, lsUpdate=>false, callBackFn=>undef, skipUIRefresh=>undef)
    loadLSTablesActiveBody(fundID=>0, fundAssetID=>0)
    callback(undefined=>undef)
        "loadLSTablesActiveBody(0,0)"
    Class.fireCallback(_1=>"loadLSTablesActiveBody(0,0)", _2=>undef, _3=>Array[0], _4=>Obj{length:7}, _5=>true) on [Class Timer]
    Timer.$in(_1=>"$ir269")
    anonymous()
        "isc.Timer.$in('$ir269')"
Reply With Quote
  #8  
Old 1st Mar 2010, 11:46
Isomorphic Isomorphic is offline
Administrator
 
Join Date: May 2006
Posts: 38,988
Default

Confused now - you started this thread saying that a refreshRow() call was causing a script running slowly dialog so we tried to figure out if that refreshRow was somehow causing a full redraw.

Now you're saying you're actually calling redraw yourself and that's the source of the script running slowly dialog..

So which/what is the cause?
Reply With Quote
  #9  
Old 1st Mar 2010, 11:54
senordhuff
Guest
 
Posts: n/a
Default

Both!

If you look back at the thread, I sent one example of a slow script with refreshRow(). Then, I sent another example for a grid redraw(). So, something is happening when the ListGrid is grouped to cause a slow script error both when refreshRow is called and when grid.markForRedraw() is called.

Sorry about the confusion.
Reply With Quote
  #10  
Old 2nd Mar 2010, 07:54
Isomorphic Isomorphic is offline
Administrator
 
Join Date: May 2006
Posts: 38,988
Default

OK, that clears that part up.

The stack trace you've shown (from Firefox) is inconclusive, but suggests that somehow, you have a formatter function or similar that is causing the grid to repeatedly recalculate grouping every time certain cells are refreshed. Does this ring a bell? Possibly calls to setEditValue() are involved?

Capturing and posting profiler output from Firebug may also help.

Overall though, the usual approach of trying to isolate this behavior to grid with grouping and 180 columns is the sure way to get it solved (if it's a SmartClient issue).
Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search


© 2010,2011 Isomorphic Software. All Rights Reserved