YesNoOk
avatar

Delay... (Read 13171 times)

Started by Nightwish, August 03, 2005, 18:55:43

0 Members and 1 Guest are viewing this.
Share this topic:
#1
Delay... |
August 03, 2005, 18:55:43
Well.. while playing with some new stuff for my clist_nicer+ and a avatar service plugin (more will be disclosured when this stuff reaches a more useful state), I discovered a BIG problem with current tabSRMM.

The problem is caused by the multisend code, which embeds a contact list in EVERY message tab you open. This contact list is hidden, but still active (it worked the same way in old SRMM plugins) and this is really, really an enormous and useless waste of resources, especially when someone is using one of the more complex contact lists (e.g. clist_modern with avatars or clist_mw).

This needs to be fixed, because it slows down the creation of a message window and can waste some hundred k of memory PER MESSAGE WINDOW (that can sum up to a few megs, if multiple tabs/windows are open).

The solution will be a dynamically created contact list, which will only be present when it is actually needed.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#2
Re: Delay... |
August 03, 2005, 20:19:24
Sounds good, Nightwish.
May I siggest something? :) I don't know the architecture of Miranda, but I was thinking as long as you are fixing it may be you don't have to apply all the visual effects of the contact list when you display one in a TabSRMM container (I mean things like background images or colors). May be it will help you save some more resources. Again, I don't know how it works, just guessing. Consider it, if you want.
Another thing, may be you want to fix one visual glitch :) When you select an option to send a message to multiple contacts, you're not only showing a contact list but also displating an icon of a man in the bottom-left corner of the container. And this icon seems to be wider than the area it's on. I'm attaching a screenshot.

Regards ;)
__
Repeat after me: I will use Google before asking stupid questions.
#3
Re: Delay... |
August 04, 2005, 03:30:58
May I siggest something? :) I don't know the architecture of Miranda, but I was thinking as long as you are fixing it may be you don't have to apply all the visual effects of the contact list when you display one in a TabSRMM container (I mean things like background images or colors). May be it will help you save some more resources. Again, I don't know how it works, just guessing. Consider it, if you want.

That could only be done in the contact list itself. My future (not yet released) clist_nicer+ does something like that - when used in "embedded mode" inside other dialogs (one example would be the ignore configuration page), it doesn't show avatars or extra icon, it still uses its skinning, but clist_nicer's skinning is pretty resource friendly because of the fact it doesn't use images for skinning, but draws everything itself.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#4
Re: Delay... |
August 04, 2005, 04:32:30
So that's the reason why a container takes 10-15 seconds to open, on my machine!!! No wonder I can't run anything else while Miranda's running!
Uhm... I'm using clist_modern 0.3.0.181 (without avatars) with pretty much skinning, including picture background. And when I tried -just for the sake of it- the final .95 build of tabSRMM, container creation time went up to 20 seconds and more...
That's one of the main reasons why I gave up upgrading tabSRMM from .95pre7.

Now I might sound like a bitch, but could you apply the (future) fix to the pre7 ANSI build, if only to see the differences? I'm very happy with this build, except for these delay and memory hog issues.

And talking about the fix, I really think the multisend CList should be simple to the bone, for maximum performance. No avatars, no skins, nothing but names and protocol icons, taken from the DB.
#5
Re: Delay... |
August 04, 2005, 05:31:06
since this multisend behavior isn't new, instead of fixing .95pre7 you can simply try it with clist classic and see the difference... with the fix it can only improve
#6
Re: Delay... |
August 04, 2005, 08:23:52
So that's the reason why a container takes 10-15 seconds to open, on my machine!!! No wonder I can't run anything else while Miranda's running!

The main reason for slowdowns on opening a window is the rich edit control and the amount of "old" messages you load. Also, the complexity of the message templates can contribute a lot and IEView can, depending on the complexity of the theme, quickly double or triple that time. For example, with complex themes (satin or similar), opening a tab and loading 100 old events can take a few seconds,  even on a 3+ GHz system.

IE is extremely slow when image transparency is involved..

Quote
Now I might sound like a bitch, but could you apply the (future) fix to the pre7 ANSI build, if only to see the differences? I'm very happy with this build, except for these delay and memory hog issues.

No longer possible. The pre7 source was never tagged as a release, so its gone.

Quote
And talking about the fix, I really think the multisend CList should be simple to the bone, for maximum performance. No avatars, no skins, nothing but names and protocol icons, taken from the DB.

Like I said, only possible with "help" from the contact list.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#7
Re: Delay... |
August 04, 2005, 23:54:40
No "old" events; "only unread events" is checked in my options.
Tweety's Cyan-Pink theme is installed in IEView. I don't think transparency is to be taken into account on a 98SE system.
Smiley packs are moderate, the standard number of smileys for each protocol (ICQ, MSN and Yahoo), mostly animate but normal size (16x16).

For help on CList (Modern) you should contact FYR; I'm sure he'll do whatever needed. He's a good and understanding person.

@ PROGAME:

After all features and tweaks for CList personally requested to FYR (and done very quickly) since it was called clist_meta_mw, I would really be an ass to change CList, if only for a test.

I guess I'll have to live with both tabSRMM and clist_modern, as they are. After all, I should be grateful for all the work that's been invested in them...
#8
Re: Delay... |
August 05, 2005, 00:52:55
The main reason for slowdowns on opening a window is the rich edit control and the amount of "old" messages you load. Also, the complexity of the message templates can contribute a lot and IEView can, depending on the complexity of the theme, quickly double or triple that time. For example, with complex themes (satin or similar), opening a tab and loading 100 old events can take a few seconds,  even on a 3+ GHz system.

I use Satin :P

Is this the "input history size" option?
I have it for set at 10 entries (default), so since I do not use these histories for anything, there is no need for 10 of them to load? maybe just 1?
What is the point of more than 1 old message to load (I havn't seen a use/need yet)?
Last Edit: August 05, 2005, 00:55:29 by andrewabc
#9
Re: Delay... |
August 05, 2005, 03:16:55
If you see no point in loading old events, why don't you just set it to "Load only unread events"? I always had it that way...
#10
Re: Delay... |
August 06, 2005, 15:52:16
Options->message sessions->message window->message log
Under "load history events" I have "load unread events only" checked. :)

But under
Options->message sessions->message window->tabs and windows
There is "input history size" option which is currently set at 10.
What does this do?
#11
Re: Delay... |
August 06, 2005, 18:04:06
Input history size is the the number of previous messages you sent that tabsrmm should remember; the number of messages you can access by pressing ctrl + up/down in the input area.
#12
Re: Delay... |
August 06, 2005, 19:41:20
Hi, the problem with "delay" is already fixed in clist nicer+ 0.5.0.1 or we need to wait for the next version?

Btw, very great job man, you're a great coder.

Thanks in advance ^^
#13
Re: Delay... |
August 06, 2005, 20:10:36
Hi, the problem with "delay" is already fixed in clist nicer+ 0.5.0.1 or we need to wait for the next version?

Btw, very great job man, you're a great coder.

The reason why I gave clist_nicer priority is the new avatar service. The clist is basically a "test case" for this service plugin. tabSRMM will most likely also use it in the future, allowing for cleaner code and shared avatar resources.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#14
Re: Delay... |
August 06, 2005, 22:23:06
The solution will be a dynamically created contact list, which will only be present when it is actually needed.

Hmm, excuse me if I missed something, but is this something that will be fixed on the CList or TabSRMM side?
#15
Re: Delay... |
August 06, 2005, 22:35:14
The solution will be a dynamically created contact list, which will only be present when it is actually needed.

Hmm, excuse me if I missed something, but is this something that will be fixed on the CList or TabSRMM side?

It will be changed in tabSRMM. Currently, it creates an embedded contact list (for the multisend feature) for each message session. I consider that a waste of resources, because multisend isn't something you use in every message tab you open. It's not really an issue with clist classic, but with a skinned clist_nicer or clist_modern it can waste quite some memory (and time, when opening the message window). So, the multisend contact list will only be created when you activate the multisend mode, and destroyed when you are done with multisend. This doesn't require any change in the contact list plugin.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#16
Re: Delay... |
August 07, 2005, 08:34:55
Yes, I understood most of what you said in the first post, just not where exactly the change would take place, but I'd have guessed that it was TabSRMM's fault. So this has been there all the time? I can't wait for the next, speedy release. :)
#17
Re: Delay... |
August 07, 2005, 12:34:30
Input history size is the the number of previous messages you sent that tabsrmm should remember; the number of messages you can access by pressing ctrl + up/down in the input area.

Tried the control up/down, but it does nothing.
#18
Re: Delay... |
August 07, 2005, 12:47:34
Tried the control up/down, but it does nothing.
Did you send at least one message before ? Ctrl + up/down moves through the list of sent messages (input history); send a couple of messages and then try ctrl + up/down.
#19
Re: Delay... |
August 08, 2005, 15:26:13
Oh, so I have to send messages during the current conversation, I can't open a new message window with someone I have talked to before and use ctl + -

Hmm, I tried using it during a conversation but nothing happens.
#20
Re: Delay... |
August 08, 2005, 16:05:21
Oh, so I have to send messages during the current conversation, I can't open a new message window with someone I have talked to before and use ctl + -
Exactly...

Hmm, I tried using it during a conversation but nothing happens.
Are you sure you didn't set the 'Input history' to 0...? did you messed with 'Global hotkey modifiers'...? are you sure you used CTRL+UP/DOWN keys...?
#21
Re: Delay... |
August 08, 2005, 23:45:25
Ok, its now working once I use the up down keys :P
#22
Re: Delay... |
September 24, 2005, 23:44:43
Has the speed issue with the embedded multisend clist been taken care of?
#23
Re: Delay... |
October 04, 2005, 20:33:11
Has the speed issue with the embedded multisend clist been taken care of?
I think the author is very busy and developing further the Avatars Service and the CList Nicer+. But since I use CList Modern this resource waste and increasing delay when opening TabSRMM is becoming more and more noticeable, so I'd like to know the status of this question too.

Also, I think that the usual multisend is not a must. It can be easily done with the "Send to container" feature in TabSRMM, keeping in mind that no one wants to spam tenths of people with the same message at the same time. But that's just an opinion, of course.

Thanks in advance for your info, your help and your good work, Nightwish.
#24
Re: Delay... |
October 05, 2005, 00:23:30
Has the speed issue with the embedded multisend clist been taken care of?
I think the author is very busy and developing further the Avatars Service and the CList Nicer+. But since I use CList Modern this resource waste and increasing delay when opening TabSRMM is becoming more and more noticeable, so I'd like to know the status of this question too.

It is already done for the next version. Embedded clist is created "on demand" only (that is, when you activate the multisend option).

Together with that, I implemented the "embedded" mode in clist_nicer+ - this is a simplified clist control which doesn't draw all the advanced stuff like avatars, complex background skinning and such. It looks more like clist_classic, but for dialog pages like the typing notify or ignore options (or the multisend contact list in a message window), it is enough.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#25
Re: Delay... |
October 07, 2005, 09:03:33
Oh, great stuff. Do I dare ask when it's likely to be released?
#26
Re: Delay... |
October 07, 2005, 13:18:53
I'm still betting on a Christmas 1.0 release. :)
#27
Re: Delay... |
October 07, 2005, 14:57:56
I'm still betting on a Christmas 1.0 release. :)

Main reason for the delay are the quite big changes in the core recently (unicode stuff). This is still work in progress and some changes will follow - however, I want to keep compatibility with older miranda versions (mainly 0.4.0.x) and that's a bit tricky, especially for the unicode build which should work with all cores (new unicode, new non-unicode and older non-unicode).
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork