[tor-bugs] #2093 [Vidalia]: Handle debug-level Tor log severity efficiently

[Tor Bug Tracker & Wiki]

#2093: Handle debug-level Tor log severity efficiently
---------------------+------------------------------------------------------
 Reporter:  arma     |       Owner:     
     Type:  defect   |      Status:  new
 Priority:  major    |   Milestone:     
Component:  Vidalia  |     Version:     
 Keywords:           |      Parent:     
---------------------+------------------------------------------------------

Comment(by chiiph):

 Replying to [comment:2 atagar]:
 > Most likely the issue isn't so much drawing the volume of logs, but
 rather that each DEBUG log event triggers a UI update. Arm ran into this
 problem too, and I'm addressing it by coalescing events if they occur too
 frequently (by default limiting UI updates to once every 300 ms). For the
 code involved look for the 'features.log.maxRefreshRate' config option in:
 > https://svn.torproject.org/svn/arm/trunk/src/interface/logPanel.py

 Actually, it is a problem of drawing, if you update the GUI once every
 300ms, but you "feed" the QTextEdit or whatever chunks of text of 400
 lines, the drawing will be a problem. I experienced this with an
 application that generated equation systems, I generate one "block of
 equations" (5 lines average) and then add it to a QTextEdit that had all
 the blocks, the generation was almost costless, but what almost crashed
 everything was Qt trying to draw everything I asked it to.
 I think it isn't the same as ARM's problem, since it's a console
 application, but maybe somebody else has another idea/experience. I still
 think taking out debug messages will be the way to go here, and fixing the
 logging inconsistencies. I can't think of a Qt way to handle that much
 text without experiencing odd issues.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2093#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online