Qt4-preview-feedback Archive, February 2007
QGraphicsView exposed rectangle and intersection calculation issues
Pages: Prev | 1 | 2 | Next
Message 16 in thread
Hi,
Me again on this one.
It appears that all parents of the item that accepts hover events, get this
event propagated in QGraphicsScenePrivate::dispatchHoverEvent();, calling the
default QGraphicsItem::hoverEnterEvent() of all the parent items, which in
turn call update().
The result of this, obviously, is that all child's of the item's parent that
accept hover event's get repainted on a hoverenter on the item...
Is this behaviour correct ???
Does it mean all classes that inherit qgraphicsitem that don't accept
hoverEvents have to reimplement QGraphicsItem::hoverEnterEvent, to avoid the
default implementation that calls update() ?
Me is confused.
Greetings,
Remon
> > On mouse enter, it's boundingrect seems to have grown by 1 pixel at the
> > bottom, but horror, it grows also to the left edge of the view!!
>
> Correction: It seems the exposed area is viewport width!
>
> Might make debugging a lot easier :-)
>
>
> Remon
>
> To unsubscribe - send "unsubscribe" in the subject to
> qt4-preview-feedback-request@xxxxxxxxxxxxx
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 17 in thread
Hi,
Although less related to the subject, I found that the scrollbar, as well as
the arrow 'pushbuttons' had a relatively high paint cost compared to the time
spend in QGraphicsView::paintEvent().
The style classes are a bit confusing, but at least I found this:
qcommonstyle:
line 766: itemText always drawn, even if there is no text...
And there seems to be always text painted for a scrollbar, though obviously it
doesn't have text ! ?
Most of the painting time for the scrollbar was spend in the functions
uniqueName, and in QStyle::drawItemText, the profile by callgrind only
instrumented during scrollbar move.
Hope this is of any help,
Remon
P.S.
The style in use was QPlastiqueStyle
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 18 in thread
Remon wrote:
> The result of this, obviously, is that all child's of the item's parent
> that accept hover event's get repainted on a hoverenter on the item...
> Is this behaviour correct ???
Yup!
> Does it mean all classes that inherit qgraphicsitem that don't accept
> hoverEvents have to reimplement QGraphicsItem::hoverEnterEvent, to avoid
> the default implementation that calls update() ?
Items that don't accept hover events, don't get hoverEnterEvent(). But
children that are on top of parents will always trigger a repaint of the
parent, regardless of hover events.
Andreas
--
[ signature omitted ]
Message 19 in thread
> Items that don't accept hover events, don't get hoverEnterEvent(). But
> children that are on top of parents will always trigger a repaint of the
> parent, regardless of hover events.
Ah yeah, that's the part I don't understand really.
Say you have a parent, and child1, child 2, child3, etc.
Only the childs accept hover events.
When the mouse enters child1, the parent and child1, child2, and child3 get
repainted!
On a mouse leave event, only child1 get's repainted, why is it different for
mouse hover enter?
Consider you have a few hundred items on one parent, moving the mouse over the
canvas will repaint all of them all the time!
I just fail to see how this can be wanted behaviour :-)
Regards,
Remon
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 20 in thread
Remon wrote:
> When the mouse enters child1, the parent and child1, child2, and child3
> get repainted!
> On a mouse leave event, only child1 get's repainted, why is it different
> for mouse hover enter?
Can you show this in code, please?
> Consider you have a few hundred items on one parent, moving the mouse over
> the canvas will repaint all of them all the time!
> I just fail to see how this can be wanted behaviour :-)
It's how composition works, and it only occurs if items overlap. If you want
to redraw something when there's something behind, you first have to redraw
what's behind.
Andreas
--
[ signature omitted ]
Message 21 in thread
> > When the mouse enters child1, the parent and child1, child2, and child3
> > get repainted!
> > On a mouse leave event, only child1 get's repainted, why is it different
> > for mouse hover enter?
>
> Can you show this in code, please?
Not a working example, but basically what happens in my code:
class ChildItem : public QGraphicsItem
{
ChildItem(ParentItem* item) : QGraphicsItem(item)
{
setAcceptsHoverEvents(true);
}
QRectF boundingRect() const
{
return QRectF(0, 0, 100, 100);
}
};
class ParentItem : public QGraphicsItem
{
ParentItem() : QGraphicsItem()
{
// Parent item doesn't accept hoverevents.
}
QRectF boundingRect() const
{
return QRectF(0, 0, 1000, 1000);
}
};
int main( int argc, char **argv )
{
ParentItem* parent = new ParentItem();
ChildItem* child1 = new ChildItem(parent);
child1->setPos(0, 0);
ChildItem* child2 = new ChildItem(parent);
child2->setPos(200, 0);
ChildItem* child3 = new ChildItem(parent);
child3->setPos(0, 200);
ChildItem* child4 = new ChildItem(parent);
child4->setPos(200, 200);
// Cild items don't overlap.
// on hoverenter event, dispatched in
QGraphicsScenePrivate::dispatchHoverEvent
// the child item and it's parents are send an event with sendHoverEvent()
// which in turn calls sendEvent(QGraphicsItem, event), which then calls the
// items sceneEvent(event), which calls update();
// Due this, all childs of parent parent will be repainted!
return 1;
};
> > Consider you have a few hundred items on one parent, moving the mouse
> > over the canvas will repaint all of them all the time!
> > I just fail to see how this can be wanted behaviour :-)
>
> It's how composition works, and it only occurs if items overlap. If you
> want to redraw something when there's something behind, you first have to
> redraw what's behind.
Sure, nothing wrong with that, but as you see in the above example, the whole
parent will be repainted and thus all it's children, not just the exposed are
of the hovered child!
Regards,
Remon
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 22 in thread
Hi,
i'm not sure if qt4-preview-feedback@xxxxxxxxxxxxx is the correct place
for this, i'm wondering if i should instead send this to
qt-bugs@xxxxxxxxxxxxx? also, it seems snapshot-users@xxxxxxxxxxxxx might
be a more appropriate place for discussions about snapshots, but that
list seems to be pretty dead? (i guess i'll just crosspost it for now.)
in the recent snapshot (4.3.0-snapshot-20070216) QTreeWidget is acting
strange when inserting items into QTreeWidgets.
The following test project exhibits the behaviour:
To reproduce, right click anywhere to trigger the insertion of new
elements.
The Treewidget will show the newly inserted item having the children of
one of the older items and a lot more wild behaviour (i.e. when you
press cursor down, you can get "warped around", you can have 2 lines
highlighted etc.)
The test project uses the qt-solution qtpropertybrowser-2.2-commercial,
compile like the examples of that solution.
The error is in Qt4.3.0-snapshot-20070216, not in qtpropertybrowser, i
already checked that by trying with another (but a lot larger) test
project which shows the same bug. Qt 4.2.2 works fine.
Cheers,
Peter
--------main.cpp-----------------------------------------------------
#include "test.h"
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
Test w;
w.show();
app.connect(&app, SIGNAL(lastWindowClosed()), &app,
SLOT(quit()));
return app.exec();
}
--------test.h-------------------------------------------------------
#include <QtGui>
#include "qtpropertymanager.h"
#include "qttreepropertybrowser.h"
#include "qtvariantproperty.h"
class Test : public QWidget
{
Q_OBJECT
public:
Test(QWidget *fp_parent = 0, Qt::WFlags f_flags = 0);
~Test();
public slots:
void contextMenu(const QPoint &position);
private:
QtTreePropertyBrowser *mp_propertyBrowser;
QtProperty *mp_dataRoot;
QtProperty *mp_insertAfter;
QtVariantPropertyManager *mp_propertyManager;
};
--------test.cpp-----------------------------------------------------
#include <QtGui>
#include "test.h"
Test::Test(QWidget *fp_parent, Qt::WFlags f_flags)
: QWidget(fp_parent, f_flags)
{
resize(QSize(400, 300));
mp_propertyManager = new QtVariantPropertyManager();
mp_dataRoot =
mp_propertyManager->addProperty(QtVariantPropertyManager::groupTypeId(),
QLatin1String("Group Property"));
// create some test data...
QtVariantProperty *item;
item = mp_propertyManager->addProperty(QVariant::Bool,
QLatin1String("Bool Property"));
mp_dataRoot->addSubProperty(item);
mp_insertAfter = item;
item =
mp_propertyManager->addProperty(QtVariantPropertyManager::flagTypeId(),
QLatin1String("Flag Property"));
item->setAttribute(QLatin1String("flagNames"), QStringList() <<
"Flag0"<< "Flag1"<< "Flag2");
mp_dataRoot->addSubProperty(item);
mp_propertyBrowser = new QtTreePropertyBrowser(this);
mp_propertyBrowser->addProperty(mp_dataRoot);
mp_propertyBrowser->setContextMenuPolicy(Qt::CustomContextMenu);
connect(mp_propertyBrowser,
SIGNAL(customContextMenuRequested(const QPoint &)),
this, SLOT(contextMenu(const QPoint &)));
}
Test::~Test()
{
}
void Test::contextMenu(const QPoint &f_position)
{
QtVariantProperty *item;
item = mp_propertyManager->addProperty(QVariant::String,
QLatin1String("New Text Property"));
mp_dataRoot->insertSubProperty(item,mp_insertAfter);
}
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 23 in thread
Hi,
Peter Prade wrote:
> Hi,
>
> i'm not sure if qt4-preview-feedback@xxxxxxxxxxxxx is the correct place
> for this, i'm wondering if i should instead send this to
> qt-bugs@xxxxxxxxxxxxx? also, it seems snapshot-users@xxxxxxxxxxxxx might
> be a more appropriate place for discussions about snapshots, but that
> list seems to be pretty dead? (i guess i'll just crosspost it for now.)
>
Lets see if I can clarify :)
qt-bugs - To report bugs in our released software. This is mostly read
by our support team.
snapshot-users - To report problems with the snapshots mechanism itself
(rsync, unavailability). This is mostly read by our system administrators.
qt4-preview-feedback - discussion of new API, reporting bugs and compile
problems in our beta/snapshots/tech previews. This is mostly read by our
developers.
> in the recent snapshot (4.3.0-snapshot-20070216) QTreeWidget is acting
> strange when inserting items into QTreeWidgets.
> The error is in Qt4.3.0-snapshot-20070216, not in qtpropertybrowser, i
> already checked that by trying with another (but a lot larger) test
> project which shows the same bug. Qt 4.2.2 works fine.
>
Ok, I will let the responsible developers know.
Girish
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 24 in thread
> > i'm not sure if qt4-preview-feedback@xxxxxxxxxxxxx is the correct
place
> > for this, i'm wondering if i should instead send this to
> > qt-bugs@xxxxxxxxxxxxx? also, it seems snapshot-users@xxxxxxxxxxxxx
might
> > be a more appropriate place for discussions about snapshots, but
that
> > list seems to be pretty dead? (i guess i'll just crosspost it for
now.)
>
> Lets see if I can clarify :)
>
> qt-bugs - To report bugs in our released software. This is mostly read
> by our support team.
>
> snapshot-users - To report problems with the snapshots mechanism
itself
> (rsync, unavailability). This is mostly read by our system
administrators.
>
> qt4-preview-feedback - discussion of new API, reporting bugs and
compile
> problems in our beta/snapshots/tech previews. This is mostly read by
our
> developers.
Thanks Girish,
maybe someone should update the info at http://lists.trolltech.com/ then
because there it you can read this misleading info:
> Qt4-preview-feedback: This mailing list hosts discussions about the Qt
> Technology Preview releases.
(the latest Qt Technology Preview release is
qt-win-preview-commercial-src-4.2.0-tp1.zip which is long outdated)
> Snapshot-users: This is a special mailing list, snapshot-users, for
> discussion of issues specific to the Qt rsync server pre-release
> versions or the periodic Qt snapshots. We encourage you to use this
> mailing list instead of qt-interest for issues relating to
> beta/pre-release versions of Qt.
Cheers,
Peter
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 25 in thread
Remon wrote:
> // Cild items don't overlap.
> // on hoverenter event, dispatched in
> QGraphicsScenePrivate::dispatchHoverEvent
> // the child item and it's parents are send an event with sendHoverEvent()
> // which in turn calls sendEvent(QGraphicsItem, event), which then calls
> the // items sceneEvent(event), which calls update();
> // Due this, all childs of parent parent will be repainted!
This looks like a bug, certainly. Could you please type it in this as a
bugreport on this form:
http://www.trolltech.com/bugreport-form
It'll go into our tracking system so others can see it too. I'll see if we
can fix it; it should be simple.
Andreas
--
[ signature omitted ]
