Site Tools


Differences

This shows you the differences between two versions of the page.

Link to this comparison view

rhino:testviewupdate [2015/09/14]
127.0.0.1 external edit
rhino:testviewupdate [2016/07/18] (current)
sandy
Line 1: Line 1:
  
 +======TestViewUpdate======
  
-=====TestViewUpdate===== +When Rhino draws feedback items (i.e. dragging objects around), it must update all views simultaneously. Depending on how many views you have open, what resolution your monitor is in, the number of monitors, ...basically anything that adds overhead ​... updating all views will impact feedback.
-When Rhino draws feedback items (i.e. dragging objects around), it must update all views simultaneously. Depending on how many views you have opened, what resolution your monitor is in, the number of monitors, ...basically anything that can/will add overhead ​to updating ​"all" ​viewswill impact feedback.+
  
-Rhino attempts to update all views as fast as it can, as best it can, without experiencing delays. ​ The mechanism isn't perfect, but for most configurations it does pretty well. In situations where this doesn'​t seem to be working well, I suggest you try using the test command ​"TestViewUpdate". This command gives you the ability to change the frequency at which views get updated. ​ A value of 0 (zero) means use Rhino'​s automated mechanism, which is the default. By changing the frequency, you will be giving the "active" ​view higher priority over all other views. ​ A value of 200 **should** ​give you something close to what V3's updating mechanism is. The higher the value, the higher the priority ​is given to the active view, which means, the less priority is given to all other views. The end result ​**should** ​be that your active view updates immediately,​ whereas all other views will most like experience some sort of delay. The delay is dependent on the speed of your computer and the amount of processing Rhino has to do per view. Unfortunately,​ the command settings aren't remembered across sessions, but if this works for you, and you're able to find a frequency that works, you can always add the command to your startup commands.+Rhino attempts to update all views as fast as it can, as best it can, without experiencing delays. ​ The mechanism isn't perfect, but for most configurations it does pretty well. In situations where this doesn'​t seem to be working well, I suggest you try the test command ​**TestViewUpdate**. This command gives you the ability to change the frequency at which views get updated. ​ A value of 0 (zero) means use Rhino'​s automated mechanism, which is the default. By changing the frequency, you will be giving the active view higher priority over other views. ​ A value of 200 __should__ ​give you something close to what V3's updating mechanism is. The higher the value, the higher the priority given to the active view, which means that less priority is given to all other views. The result ​__should__ ​be that your active view updates immediately,​ whereas all other views will likely ​experience some sort of delay. The delay is dependent on the speed of your computer and the amount of processing Rhino has to do per view. Unfortunately,​ the command settings aren't remembered across sessions, but if this works for you, and you're able to find a frequency that works, you can always add the command to your startup commands.
  
-The reason things ​worked ​better using region buffers is because region buffers are/were designed to update regions of the view based on what things ​changed from the previous update. They are all implemented in the video hardware, which makes them fast. However, ​this speed comes at a pricememory! ​ Using region buffers doubles the amount of video memory used...and if you're running at high resloutions and/or with multiple views and/or multiple monitors, then region buffers ​can and will most likely cause performance issues due to the video drivers trying to maintain all those contiguous blocks of video memory, which is most likey what you were experiencing.+The reason things ​work better using region buffers is because region buffers are designed to update regions of the view based on what changed from the previous update. They are all implemented in the video hardware, which makes them fast. But this speed comes at a pricememory! ​ Using region buffers doubles the amount of video memory used...and if you're running at high resolutions ​or with multiple views and multiple monitors, then region buffers will likely cause performance issues due to the video drivers trying to maintain all those contiguous blocks of video memory. This is likely ​what you were experiencing.
  
 -Jeff -Jeff
  
  
rhino/testviewupdate.txt · Last modified: 2016/07/18 by sandy