On Fri, 2010-11-26 at 02:44 +0100, András Murányi wrote:
No, i wouldn't! I just had a vague memory that this behaviour (doing all the delayed calculations at once after a freeze) resembles -nosleep's behaviour (doing all the delayed calculations at once after a system sleep), but i may completely mistaken.
I see. As it turns out I did discover consistency check errors which have to do with the new way iemgui objects tag their inlets and outlets to make them highlight-compliant. It seems that GOP-ed objects should not call glist_findrtext which is triggering this error as a bug (even though iemgui's new code gracefully falls back to a secondary option). I've now implemented a pre-check so that we never even call findrtext if we are an iemgui object drawn as part of GOP.
All this said, I've not encountered any burst-like slowdowns except when moving tons of objects simultaneously which was even more problematic in the old iteration due to the amount of socket traffic.
What is really weird is the following:
- try using any of your complex GOP abstractions and add one to a blank
patch and try to move it around 2) in my case movement is rather choppy (understandably so as GOP even in l2ork iteration still relies upon coords calls rather than move-by-tagging) 3) *however*, when one selects and duplicates the same abstraction so that there are now two of them, suddenly performance is (at least on my machine--msi wind u100 with atom 1.6GHz procesor) amazingly smooth which goes against all logic
Anyone else experiencing the same and/or have a logical explanation for this?
Latest snapshot can be found in the usual place:
http://l2ork.music.vt.edu/main/?page_id=56
Cheers!