2.6 Dynamic Image option not there
- dwatson
- Posts: 6
- Joined: Tue Oct 11, 2011 4:12 am
2.6 Dynamic Image option not there
It appears the option to select if an image widget is dynamic does not appear in the position group in page designer like it did in 2.3.
- drphil69
- Posts: 139
- Joined: Wed Mar 02, 2011 5:59 pm
Re: 2.6 Dynamic Image option not there
I just noticed that as well. And I have slow screen response. And I have to ship today. And Murphy is closed today.
- jpratt
- Enovation Controls Development
- Posts: 222
- Joined: Mon Jun 21, 2010 11:18 am
Re: 2.6 Dynamic Image option not there
The 2.6 drawing system no longer relies on static and dynamic to optimize performance. In the past the system used static/dynamic to drive which objects (images and text) would be cached. This led to a large number of unpredictable behaviors and made it difficult to place objects in a true "Z-Order."
2.6 does away from this proprietary caching model and replaces it with a standard dirty rectangle drawing system . With this you simply assign the Z-Order of the object and let the screen figure out if the area needs drawn in each pass. This removes the need to capture static/dynamic and effectively determines it "on the fly" for each frame. The net affect is that you now can simply set the Z-Order (top to bottom order) of objects to control what covers what.
These changes change can have an affect on performance however the effect is very deterministic. The amount of work done during a frame is now directly proportional to the amount of change on the screen. In fact, when the screen is mostly unchanged it can consume as little as 1-4% of system resources. Over all the screen should put less burden on the system.
If you are seeing a slow response in the screen its likely that its due to the screen running at a lower priority than other system processes. By this I mean that most likely the CPU is being consumed by another system process..likely CCM (programming) or NVMgr (database). In teh case of CCM the most common cause is large chains of work tied to a fast timer. For example you are running a 50ms timer and the timer fires a larger than necessary amount of work. If the performance is tied to the database its likely caused by excessive writes to the file system. The most likely reason for this that you have set variables to write more often than necessary. For example, if you update 100 variables and have logic that updates each variable after a change...this can cause a LOT of writes as each write will update the database over and over. A better model is to save once after a set of changes changes or save on a less frequent basis.
Hope some of this helps.
2.6 does away from this proprietary caching model and replaces it with a standard dirty rectangle drawing system . With this you simply assign the Z-Order of the object and let the screen figure out if the area needs drawn in each pass. This removes the need to capture static/dynamic and effectively determines it "on the fly" for each frame. The net affect is that you now can simply set the Z-Order (top to bottom order) of objects to control what covers what.
These changes change can have an affect on performance however the effect is very deterministic. The amount of work done during a frame is now directly proportional to the amount of change on the screen. In fact, when the screen is mostly unchanged it can consume as little as 1-4% of system resources. Over all the screen should put less burden on the system.
If you are seeing a slow response in the screen its likely that its due to the screen running at a lower priority than other system processes. By this I mean that most likely the CPU is being consumed by another system process..likely CCM (programming) or NVMgr (database). In teh case of CCM the most common cause is large chains of work tied to a fast timer. For example you are running a 50ms timer and the timer fires a larger than necessary amount of work. If the performance is tied to the database its likely caused by excessive writes to the file system. The most likely reason for this that you have set variables to write more often than necessary. For example, if you update 100 variables and have logic that updates each variable after a change...this can cause a LOT of writes as each write will update the database over and over. A better model is to save once after a set of changes changes or save on a less frequent basis.
Hope some of this helps.
Jake Pratt
Software Development Manager
Software Development Manager