Hi! Odd Skancke wrote:
read. What I said is that WinDom makes loads of unnecessary calls on each WM_REDRAW, and that zView serviced its redraws very slow because "the problem is that wind_set() in XaAES is slow". <-- read carefully!!!
OK :)
* There has always been open discussion with WinDom developers until we reached some point we could agree on (Unlike here :().Does the WinDom authors read this list?
As far as I know yes. At least Arnaud and Me ;)
One thing is for sure; wind_calc() can not be used like in WinDom if we want to be able to change themes without restarting the AES. So here we can start discussing solutions....
Why the way wind_calc() is used in WinDom would make it behave wrong when the window CURR vs. WORK rectangle deltas change? I can fix it.
Best Regards StandaBTW: There is no documentation on the complexity of particular AES call (unlike e.g. in the SGI STL documentation) so I assume the AES does whatever necessary to keep API calls as fast as possible at any point. As allways the comparison point would be n.aes as it is proven to be the fastest (or had been for some here already).