[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Traverso-devel] new themes
From: |
Remon |
Subject: |
Re: [Traverso-devel] new themes |
Date: |
Wed, 15 Aug 2007 15:42:18 +0200 |
User-agent: |
KMail/1.9.7 |
> > Ah yeah true. I think I've changed my mind about that a little, using
> > QSVG would be way to difficult, but a somewhat more flexible way to
> > describe colors and stop points to setup a Brush from the theme file
> > would be a great solution.
> > The stop points and colors then could be stored in some kind of struct,
> > and requested on demand from anywhere. Or maybe even better, creating the
> > Brush in Themer itself, so there is no code duplication!
>
> Hm, sounds like I might need your help. How to store variable numbers of
> pairs of stop-point / color isn't clear to me.
Sure, though I'll have to look into the matter myself too, I'll send some
ideas/code when I've them!
> I tried both very small ones (1 * height), and bigger ones (512 * height).
> Remember the screenshot with the pixmap texture filling the clips I sent
> you? These were relatively large, but I didn't notice a performance
> difference in both cases. When zooming in, painting became so slow that it
> was totally unusable, just as with the gradients buffered or painted
> directly.
Curious, somewhere something is going wrong, hopefully one day we'll find the
where and how!
> Is it a Qt/Xorg problem? It seems to me that they should clip the
> repainting to the viewport, even at high zoom levels. Then zooming should
> not make much difference.
That's the weird thing, the zoomlevel makes a difference in cpu usage, but it
really shouldn't make a difference!
> I'm a bit surprised, because when they introduced
> the
> GraphicsView framework, they showed some very impressive and performant
> examples. But I have the impression that things like painting the playhead
> would be much more performant when using the "old" pixmap painting.
Yeah, the playhead is able to 'damage' large parts of the view, and as a
result is causing large repaints. (e.g. during animated scroll)
As for the QGV framework, it's as performant as they can get it. The paint
slowdowns are to be searched outside of the QGV framework.
> Do you
> know if GraphicsView is still under construction? Will there be
> improvements in Qt 4.4?
A new feature for QGV is QWidgets as a QGraphicsItem, including the ability to
use all the QLayout classes. I think it has the potential of very nice
features, but I don't know how they'll implement it. When a
QGraphicsViewWidgetItem (or it's called something like that) uses it's own
backing store, then moving such an item over the canvas shouldn't impose a
repaint of the underlying canvas items, in which case it would be a perfect
candidate for the playhead. (Moving the playhead no longer would damage the
underlying canvas items)
When I feel lucky I'll give this painting stuff another shot ...
Remon