Fwd: [ANN] QEdje 0.1

[Zack Rusin]

On Monday 04 August 2008 05:08:00 pm Caio Marcelo wrote:
> Hello guys, we've just announced the project in qt-interest, but I
> think this could be specially interesting for Plasma (at least to
> provide ideas). I'll speak more informally here :-)
>
> Edje is used by E17 and is part of what we call EFL (Enlightenment
> Foundation Libraries). The name refers both to the declarative
> language but also the library that implements the mechanism.
>
> A *very simple* explanation is: you describe UI elements using Edje (a
> button, or a complex thing), it emits signals (strings) and can react
> to signals (like fading away when receive "disable" signal). Then the
> libedje allows you to create elements in canvas (Evas_Objects) that
> behaves like described in the Edje files.
>
> I'm new to Plasma, but I think some ideas in Edje could be useful for
> you guys, maybe even allowing using Edje to create plasmoids :-)

That's great news! Thanks!

One thing I was wondering about is how's the performance looking? Evas is 
really a raster canvas, while all of graphics in Qt (and as a result 
QGraphicsView) are really more vector graphics oriented. While we did add 
tons of optimizations for purely raster paths, I'd be interested in knowing 
the performance difference between Evas's Edje and QEdje.

Also one of the blogs mentioned that there were performance problems with QGV, 
did you ever get some profile data on that to see where the time was spent?

Oh, and I took a quick look at qzioncanvas and have a few small tips:
- you really don't want to be doing QApplication::syncX() in 
QZionCanvas::paintEvent , it means that the whole app will spin idle while it 
waits for the server to process all the events
- rather than "repaint" you really want to be calling "update". While they now 
should be more or less the same thing, historically the difference is that 
update will compress useless repaints into single, while repaint is crappy 
and bug  prone due to the fact that many systems don't like to forced to 
repaint =)
- you really don't want to be rotating a QRegion. Using QRegion's will likely 
cause a slowdown and huge memory consumption because rotating a QRegion 
produces almost exponentially more rectangles. Each one of those rectangles 
has to be then processed. So using QPainterPath will  likely save you a lot 
of memory, produce visually better results and likely be a lot faster, e.g.:
QPainterPath path;
if (_rotation != 0) {
	foreach (QRect rect, d_ptr->pendingUpdateRegion.rects())
		path.addRect(rect);
	path *= rotationMatrix;
}
update(path.controlPointRect());

Hope that helps.

z