Improving performance using QHash and QList

Question

I'm using these classes:

QHash: rapresenting all the objects of the scene (cannot modify this class)

QList: rapresenting all the objects selected. It contains IDs (saved as int)

//DrawSelectedObjects(){

QHash<QString, SceneObject*>& hash=sc->getObj();
QList<int> tempList = HitsList;

int counter =0;

for (QHash<QString,SceneObject*>::ConstIterator i = hash.begin();i!=hash.end();++i) {

     if (tempList.startsWith(counter)) {
            .
            Draw_as_selected()
            .
            tempList.removeOne(counter);
     }
}
}

So,for example if I select the object #77,its ID is saved in Hitslist (QList).

After that HitsList is sorted and DrawSelectedObjects() is called.

It has to iterate the QHash until counter=77 and Draw_as_selected(). After that,The first element of the QList is removed, pulling to the front the second one.

This function is called EVERY time one object is selected. With small imported scenes its all ok,but when I'm using files >10MB I can see some output lag (its obvious, because I am iterating through a huge QHash).

Could you suggest me a more efficient way to do this? Any help would be appreciated.

EDIT:

Thank you for your reply.The problem is that I can't get rid of that QList<int> (iI can push only integers on top of OpenGL selection stack).

So another way from the above solution is to do QString.toInt() for every element of the QHash and save them into the QList<int>.

The fact is...how find out the correct QString on the hash using the int (calculated now by conversion from QString, no more from counter) on the QList?

score 2 · Accepted Answer · answered Jun 13 '13 at 02:33

2

If the way you access objects in the hash is using a QString (I guess the "name" of an object, instead of its ID), then you should also use a list of QString to store the selected objects.

QHash<QString, SceneObject*> & hash = getAllObjects();
QList<QString> & tempList = getSelectedObjects();

foreach(QString name, tempList)
    hash[name]->drawAsSelected(); // or drawAsSelected(hash[name]) depending on your design

answered Jun 13 '13 at 02:33

Boris Dalstein

7,015
4
30
59

Thank you for your reply.The problem is that I can't get rid of that QList (i can push only integers on top of OpenGL selection stack ). So another way from the above solution is to do QString.toInt() for every element of the Qhash and save them into the QList. The fact is...how find out the correct QString on the hash using the int (calculated now by conversion from QString,no more from counter) on the QList? – Tcz Jun 14 '13 at 22:57
@nicolagenesin Ok, I see your issue. Then, the only computationally efficient solution is, in addition to your `QHash`, to keep in memory a `QHash stringFromInt;` (or `QMap`). Each time you create an object, you perform `stringFromInt[myObject->name()] = myObject->id();`. This is if you can't change your initial hash table: optimally, the best is to have directly a `QHash`. Last advice: the OpenGL built-in selection mechanism is very slow and deprecated. I used it in the past, but now use my own shaders for this (or do it in CPU if feasible). – Boris Dalstein Jun 14 '13 at 23:19
Thank you,thats what I thought but i think its "pretty horrible".The fact is that i hate to change the architecture because of old gl limits.Is it difficult to upgrade from the GL_SELECT mechanism to the shaders one?is there any good tutorial you know to link to me? – Tcz Jun 14 '13 at 23:29
@nicolagenesin Yes it -is- horrible ;-) But if you don't want or can't change the original QHash, then you have no choice :-/ Note that you will have the same issue whatever the picking mechanism, since it is likely to be int-based (you can only use QString with CPU picking, but even then I would prefer int, much simpler to enforce unique IDs than unique names). – Boris Dalstein Jun 15 '13 at 01:06
1

"Is it difficult to upgrade from the GL_SELECT mechanism to the shaders one?" Yes. And worst, I've not found a good tutorial on this. If yours is working right now, and you can't spend time on moving to a GPU shader-based picking, better not touch it. Note that Blender still uses GL_SELECT too, which is a bit of a shame. – Boris Dalstein Jun 15 '13 at 01:07
@nicolagenesin You are very welcome, this is what a community is for, I give back the time SO saved me before :) – Boris Dalstein Jun 15 '13 at 20:10

Improving performance using QHash and QList

1 Answers1