Shoutbox

well i tried changing the registry but the only difference now is that if i type a "(" the panel pops up before i can continue writing, but it still take a lot of time to load itself! The problem is, the first time it pops up, or the first time it pops up a new category, it is *very* slow! I think you misunderstood what i said: it's not the popup delay i want to decrease, i noticed that when it has to "cache" emos to show it is very slow. My idea was in fact a "big emo collection" version of the panel, that you may pop up with a defined keyboard shortcut, that doesn't take lots of time to cache previews because it does only show one preview; also, text search in an array of strings of 7 chars is very fast even if you have thousands of entries in that array. If Winamp can be so fast when "jumping to file" in my 2200+ playlist, why shouldn't Plus! with less than 200 emos? Anyway, if you bind the new panel to a key sequence, it doesn't "show up every time you type", or at less not more than the actual emos panel! It could just be a simple reworking on sounds panel, in fact that panel has nearly the functions I'm thinking about (except for the emo preview, of course, but it has sound preview).
I don't think it's a bad idea, nor a "cpu intensive" thing to do... if you want i think i could code something by myself but unfortunately i only know vb.net and java... i could apply to learn c# but at this moment i don't think i've got much time

quote:

---

Originally posted by rock3r
it's not the popup delay i want to decrease, i noticed that when it has to "cache" emos to show it is very slow. My idea was in fact a "big emo collection" version of the panel

---

I know, and I said that this will not speed things up at all.

Processing keystrokes and searching in binary trees with JScript is very slow, especially if you want "parts of shortcuts" to be reconized too. Making this as a script will be slow ...

quote:

---

Originally posted by rock3r
My idea was in fact a "big emo collection" version of the panel, that you may pop up with a defined keyboard shortcut, that doesn't take lots of time to cache previews because it does only show one preview;

---

No... it will be, at best, equally "fast" if not slower.

quote:

---

Originally posted by rock3r
also, text search in an array of strings of 7 chars is very fast even if you have thousands of entries in that array. If Winamp can be so fast when "jumping to file" in my 2200+ playlist, why shouldn't Plus! with less than 200 emos?

---

I think you have the wrong idea in how such intelisense searches work. It is far from "searching some substring in a string". I can assure you that string manipulation is very slow, if not the slowest thing you can do in code, in general...

And if you're going to implement it like "search a substring in a string" then you'll have dead-slow extremely unefficient code and extremely many unneeded loops in the code, etc...

For things like this you need to use binary tree searches.

quote:

---

Originally posted by rock3r
I don't think it's a bad idea

---

neither did I ever said it was.

quote:

---

Originally posted by rock3r
nor a "cpu intensive" thing to do...

---

again, read what I said exactly: I said it is more cpu intensive than how it is now.

ok i give up... anyway, i didn't say that it was you to say it is a bad idea...
the only thing, i wasn't absolutely talking about a script: i know that jscript is slow! absorbation himself said it could be good if directly implemented in Plus!, and that's what i'm talking about... and i think (at least in languages i use that is) that string manipulation is not slower than image manipulation (emos can also be 32bpp images, even if they are small, load and display lots of them is slower than adding the corresponding string entries in a listbox).
Also, i dunno how searching in winamp jump to file dialog is implemented (i repeat this example, because it shows clearly that it is possible to have a very quick solution) but it's very smooth. So, if i say that i think it can be a cpu-lightweight operation, i mean that: if somebody managed to do it, you can do it. It could be a hard result to achieve, that's another problem; but *it can be done*, and also in an efficient way. That's it.
Try to read carefully what i said, i'm not a fool.. i repeat you that i'm a programmer (maybe not a good one) and i have an idea of what can and what cannot be done... at least before saying me it can't try to do it! as i said in my last post you already have a sound search box that is very near to what i mean, and it doesn't seem to be deadly slow... i have lots of sounds, and it's efficient! The problem is only the "quick" emo panel....

Last resource: why don't you load cached emos previews in a separate thread in the bg, so when you need them they are ready? (maybe it's already doing it, i dunno... i'm just suggesting)

quote:

---

Originally posted by rock3r
ok i give up...

---

I'm not.. I mean, if I have some time I'll cook something up (as a script) which does what you want... unless someone beats me to it...

quote:

---

Originally posted by rock3r
and i think (at least in languages i use that is) that string manipulation is not slower than image manipulation

---

but image manipulation doesn't need to be done. PS: string manipulation is very slow and that goes for almost all languages. It has todo with how strings are handled in memory, especially if you need to search for substrings a hell of a lot memory reading and writing is done. The image manipulation involved in all this is not much more than writing something to memory only once...

quote:

---

Originally posted by rock3r
emos can also be 32bpp images, even if they are small, load and display lots of them is slower than adding the corresponding string entries in a listbox

---

displaying images need to be done anyways, there is otherwise no point in showing only shortcuts. If you can't remember shortcuts, you sure would not remember for what those shortcuts were in the first place.

Also, adding strings to a listbox (which is also dead slow on its own) is something totally different than displaying images. You can't compare apples with peaches (or whatever the expression is), and that goes too for comparing a search on filenames (or sound names for that matter) and displaying the found strings, with a searching on images (which you essentially will be doing) and displaying images...

And string manipulation is not adding stuff to a listbox but the actual searching, comparing, slicing up strings and iterating thru the list (over and over again), and the huge amount of memory reading and writing which is done by the CPU to achieve all this.

Write a bare bone program which displays something on screen and write something which searches 1 substring in a string using the basic building blocks of a program (with only memory read/write, for-loop and if-then-else statements). Then you'll see what I mean with 'a hell of a lot memory reading and writing'... as that is what the CPU must do...



---------------------------

quote:

---

Originally posted by rock3r
So, if i say that i think it can be a cpu-lightweight operation, i mean that: if somebody managed to do it, you can do it. It could be a hard result to achieve, that's another problem; but *it can be done*, and also in an efficient way. That's it
(....)
at least before saying me it can't try to do it!

---

my first response to this thread was:

quote:

---

Originally posted by CookieRevised
It is very well possible.

---

ok... well thank you, i think i was wrong... i'm still wondering how does winamp to be lightning-quick!! Last thing....

quote:

---

Also, adding strings to a listbox (which is also dead slow on its own) is something totally different than displaying images. You can't compare apples with peaches (or whatever the expression is), and that goes too for comparing a search on filenames (or sound names for that matter) and displaying the found strings, with a searching on images (which you essentially will be doing) and displaying images...

---

in fact i don't want to compare nor show images, just their shortcuts and the preview of the highlighted one. only one image is shown at a time, and search is done only through the "not-so-huge" 7-chars emo shortcuts list

1) I didn't said "comparing images", I said "compare displaying a string and displaying an image"

2) displaying images need to be done anyways, there is otherwise no point in showing only shortcuts. If you can't remember shortcuts, you sure would not remember for what those shortcuts were in the first place and you will end up scrolling thru the list and wasting a hell of a lot more time than how the quick-icon panel is integrated as it is.

Thus, 3) if you have 200 shortcuts wich contain the character "c" and you search for "c" it will be showing 200 shortcuts and images (that is also how intelisense works: narrowing a list down as you type)...

Showing only 1 emoticon at a time by selecting it doesn't make much sense and I'm sure you will not be able to select your icon any faster... If it does, you already remembered the shortcut anyways (hence you have typed it and you knew what icon to select afterwards) and the whole purpose of the idea is lost (to not needing to remember shortcuts anymore).

4) The whole process of typing and selecting an icon will be waaaaay longer than it is now by simply opening a panel and selecting the icon you need.