From kde-panel-devel Mon Nov 26 10:01:34 2007 From: "Aaron J. Seigo" Date: Mon, 26 Nov 2007 10:01:34 +0000 To: kde-panel-devel Subject: Re: [Panel-devel] Multi-threaded SVG Rendering has arrived... Message-Id: <200711260301.34555.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=119607135926429 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0721478229==" --===============0721478229== Content-Type: multipart/signed; boundary="nextPart2800268.yMET3jcBNI"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2800268.yMET3jcBNI Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 25 November 2007, Sean Harmer wrote: > The various paint() functions will also cause requested Svg elements to be > scheduled for rendering. If there is no cached pixmap ready, then paint > will not paint anything. So you should connect to svgRendered() to trigger > another repaint. This is the quick and dirty way of using the > multithreading features. > > To make more efficient use of the multithreading, you should take a look = at > panel.cpp in the second patch. This triggers a fresh rendering of the SVG > elements from within constraintsUpdated. The panel class has been modified > by adding a couple of bools to keep track of which parts of the Svg have > been rendered. When all of the requisite parts are rendered into the Svg > cache, then the paintBackground() function is allowed to proceed. it would be very nice if this could be kept hidden from the applets entirel= y,=20 since this is too high of a bar for the kind of code we're going to be=20 expecting people to write. it also sounds error prone (leading to applets n= ot=20 painting because someone forgot to call update() again) if one could associate a QGraphicsItem* or a QWidget* with a given Svg=20 rendering job, this would allow Svg to call update() on the associated obje= ct=20 automatically at the same time that svgSetRendered or svgRendered signals a= re=20 emitted. in the paint methods, we can extract the device being painted to, which giv= es=20 us a way to get at the QWidget transparently, but this does not help with=20 QGraphicsItems (the painter is on the view and doesn't know about the item)= ,=20 so we'd have to come up with some solution there. we can't really use the parent QObject either, since that may not be the it= em=20 that is ultimately being painted to ... i'm too tired right now to think this through any further. will take it up= =20 after sleep. > A new paint function has been added to Plasma::Svg that allows painting a > subset of the entire cached pixmap. This should allow certain > containments/plasmoids to make more efficient use of Svg images by only > painting the dirty area. this is good; it would be best if it were committed on its own to keep it=20 nicely away from the rest of the changes. > Is this OK to commit now please? I know of the following things that need > to be done: if we can find a way to handle the above issues, i'm find with committing=20 these features .. however, i haven't had a chance to review the code very=20 carefully at this point (i'm just about to head to bed). =2D-=20 Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech --nextPart2800268.yMET3jcBNI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHSpl+1rcusafx20MRAthGAJ9n8nPeNoqrBRL18Qp5AMEYFx/aVwCgqQ3+ 5lLiP2HylGaH+lf1u8a3B0s= =7csi -----END PGP SIGNATURE----- --nextPart2800268.yMET3jcBNI-- --===============0721478229== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Panel-devel mailing list Panel-devel@kde.org https://mail.kde.org/mailman/listinfo/panel-devel --===============0721478229==--