It's profile time!

The bug is important, but marking as P4 to follow the mantra "First make it
work, then make it fast!"

To clarify, Hugo prioritized this to be post-1.0 content. I'm a bit ambivalent
about that because the issue seems to be potentially quite serious -- at least
this ought to be one of the very first items to fix after 1.0.

Is this bug a duplicate of bug 556?

I think this bug need use the same priority of bug #556. But I do not know if
this is the same problem, we need make some experiments to check this. And I do
not know if is possible to fix this without break the api. Because of that I
think hugo move that to after 1.0 release but we can do some research on this
before 1.0 because this problem is very important.

OK - I'm making this P3 as well so that the issue can be at least investigated
before 1.0.

If fixing this would require an ABI break, we need to postpone fixing this
after 1.0. :-(

I put this P4 because the code works, but don't scale well and I think that at
the moment fix crashes are more important than optimizing things.

This still a serious issue, have no doubt about this, but the problem is that
we have other serious issues as well and need to define what is more serious
than what.

About API/ABI breakage, we can't say that will be possible fix this without
break the API/ABI, just guess... and my guess is that is possible to fix it
without break anything... but as said... it's a guess =]

(En réponse au commentaire 2)
> Is this bug a duplicate of bug 556?

Yes, sorry for that, but it seems to be the same bug, except that this one
includes the addChildren, and it also points out that the time is not "very
long", but "growing exponentially", which is quite worse...

Actually, for the addChildren, it can be bypassed by not using the Qt's
mechanism, but just adding the children to a Python list property of the
object, but there is no solution for the graphics items, as they need to be
referenced in the list, or they are just not drawn. Maybe making a tree of
items could bypass it, so that we could have items having only a limited number
of children items, and the insertion time would remain quite small.

However, I see the problem from the outside, but I can't figure why it would
require an API break ?

Erwan, the API/ABI break refers to the internal Shiboken/PySide APIs, not the
Python API. They matter too because the Linux packagers need to create new
packages for every new library version, and especially on Debian that's quite
cumbersome. Also, when the library versions are bumped, any related bindings
(such as Qt Mobility, MeeGo Context Framework, etc.) need to be rebuilt against
the new libraries, so the API/ABI breaks result in a cascading effect.

As for the reason why that ABI break might be required, that's way past my
expertese. :-)

Hugo, in general I totally agree with your thinking (crashers are more
important than optimization). However, in this case, the issue (internal
O(N**2) or worse algorithms) would appear to bad enough to render some
functionality useless, and therefore I'd like to keep this P3, at least until
the issue has been further studied.

If it appears that the fix requires an ABI break or an insubordinate amount of
work is required, we can reprioritize it at that point. Is that OK?

(In reply to comment #7)
> Hugo, in general I totally agree with your thinking (crashers are more
> important than optimization). However, in this case, the issue (internal
> O(N**2) or worse algorithms) would appear to bad enough to render some
> functionality useless, and therefore I'd like to keep this P3, at least until
> the issue has been further studied.
> 
> If it appears that the fix requires an ABI break or an insubordinate amount of
> work is required, we can reprioritize it at that point. Is that OK?

It's ok for me, a futher investigation would be needed anyway.

after investigate the bug #556, I can confirm: this bug is part of the same
problem. I will mark this a duplicate bug.

*** This bug has been marked as a duplicate of bug 556 ***

release beta4

Hi, I'm using the PySide release 1.0.0, but I still can't use the QImage
constructor properly... I'm having the following error:

TypeError: 'PySide.QtGui.QImage' called with wrong argument types:
  PySide.QtGui.QImage(str, int, int, PySide.QtGui.QImage.Format)
Supported signatures:
  PySide.QtGui.QImage()
  PySide.QtGui.QImage(PySide.QtGui.QImage)
  PySide.QtGui.QImage(PySide.QtCore.QSize, PySide.QtGui.QImage.Format)
  PySide.QtGui.QImage(QString, str = None)
  PySide.QtGui.QImage(int, int, PySide.QtGui.QImage.Format)
  PySide.QtGui.QImage(uchar, int, int, PySide.QtGui.QImage.Format)
  PySide.QtGui.QImage(uchar, int, int, int, PySide.QtGui.QImage.Format)

I thought the "uchar" argument was automatically converted from a Python
string, but it seems not to be the case. Do I have to cast it to something, or
anything else ?

Thanks !

Sorry for the last comment, I posted it on the wrong bug :(
Is there any way I can remove it, or someone else ?
Thanks, and sorry again...