[Panel-devel] Panel-devel Digest, Vol 23, Issue 6
tek_notes at bellsouth.net
tek_notes at bellsouth.net
Thu Mar 8 00:32:00 CET 2007
What would be the best way for me to get involved with programming for KDE 4? I'm a software engineer at HUMANA, yea I know I work for the man but you gotta eat right? I am already familiar with QT4 which I love. Any help is appreciated.
>
> From: panel-devel-request at kde.org
> Date: 2007/03/07 Wed AM 06:00:55 EST
> To: panel-devel at kde.org
> Subject: Panel-devel Digest, Vol 23, Issue 6
>
> Send Panel-devel mailing list submissions to
> panel-devel at kde.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.kde.org/mailman/listinfo/panel-devel
> or, via email, send a message with subject or body 'help' to
> panel-devel-request at kde.org
>
> You can reach the person managing the list at
> panel-devel-owner at kde.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Panel-devel digest..."
>
>
> Today's Topics:
>
> 1. rfc: Plasma::Theme and Plasma::Svg (Aaron J. Seigo)
> 2. Re: rfc: Plasma::Theme and Plasma::Svg (Matt Broadstone)
> 3. Re: rfc: Plasma::Theme and Plasma::Svg (Zack Rusin)
> 4. Re: rfc: Plasma::Theme and Plasma::Svg (Zack Rusin)
> 5. Re: rfc: Plasma::Theme and Plasma::Svg (Aaron J. Seigo)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 6 Mar 2007 11:46:21 -0700
> From: "Aaron J. Seigo" <aseigo at kde.org>
> Subject: [Panel-devel] rfc: Plasma::Theme and Plasma::Svg
> To: panel-devel at kde.org
> Message-ID: <200703061146.35121.aseigo at kde.org>
> Content-Type: text/plain; charset="us-ascii"
>
> hey all..
>
> looking at the use patterns in ksysguard, krunner and now plasma for QSvg this
> seems to be the common approach:
>
> - load the svg from disk
> - on paint, render the svg into a pixmap and hold on to that, blit the pixmap
> - on resize, mark the cached pixmap as dirty, causing a re-render on next
> paint
>
> this is because rendering svg obviously takes more time than simply blitting
> an image
>
> the other concern is that QSvg can take a good amount of memory to build the
> render tree, etc.. so sharing renderers is a good idea; and deleting them
> when not needed anymore is even better.
>
> there are two other assumptions that went into my thinking on this that
> reflect the current state of panels and desktop widgets in kde and other
> desktops:
>
> - items will be long-lived but rarely change size
> - many items will share identical graphical elements, e.g. widget and button
> backgrounds
>
> i sat down last night and put together a design that will provide for these
> use cases to avoid duplicating this pattern over and over in the code.
>
> Plasma::Svg will provide the following public methods:
>
> - Svg(const QString& imagePath, const QSize& size)
> constructor that takes a path to be used with Plasma::Theme
> - paint( QPainter*, const QRect& )
> pretty obvious =)
> - resize( int width, int height )
> also pretty obvious
> - resize( const QSize& size )
> even more obvious ;)
>
> so one would simply do:
>
> Plasma::Svg* bg = Plasma::Svg( "dialog/background", QSize( 400, 250 ) );
>
> and in the paint method:
>
> QPainter p( this );
> bg->paint( &p, rect() )
>
> to facilitate this, Plasma::Theme will be changed to provide a singleton
> pattern, e.g. Theme* self().
>
> what i haven't decided yet, is whether we should check the rect in paint()
> against the current size and assume that if the rect != rect() that a resize
> is implied. the usual case will be to call resize() in the painting item's
> resizeEvent() however, so i don't know if this will buy us anything in
> practice. at this point i'm taking a wait-and-see-approach on that.
>
> the pixmaps will be stored in a QPixmapCache for use throughout the app.
> therefore, if more than one instance of the same Plasma::Theme image path
> with the same rendering size is available, there should be no need to hit
> disk, parse or render the svg. woo! item keys will be constructed this way:
>
> ${IMAGE_PATH}_${WIDTH}_${HEIGHT}
>
> internally, Plasma::Svg will have a ref-counted shared struct of data
> containing:
>
> - refcount on the QPixmapCache entry
> - QSvgRenderer. this should prevent multiple instantiations of the renderer.
>
> profiling should later show if/when/how the shared renderer should be
> instantiated and removed. e.g. it may make sense to create the renderer and
> after a certain amount of time w/out calls to resize to delete it to conserve
> memory.
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
>
> Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 189 bytes
> Desc: not available
> Url : http://mail.kde.org/pipermail/panel-devel/attachments/20070306/228a7f13/attachment-0001.pgp
>
> ------------------------------
>
> Message: 2
> Date: Tue, 6 Mar 2007 14:27:18 -0500
> From: "Matt Broadstone" <mbroadst at gmail.com>
> Subject: Re: [Panel-devel] rfc: Plasma::Theme and Plasma::Svg
> To: panel-devel at kde.org
> Message-ID:
> <621909c70703061127p66f4aa06k77c820056051bdcc at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 3/6/07, Aaron J. Seigo <aseigo at kde.org> wrote:
> > hey all..
> >
> > looking at the use patterns in ksysguard, krunner and now plasma for QSvg this
> > seems to be the common approach:
> >
> > - load the svg from disk
> > - on paint, render the svg into a pixmap and hold on to that, blit the pixmap
> > - on resize, mark the cached pixmap as dirty, causing a re-render on next
> > paint
> >
> > this is because rendering svg obviously takes more time than simply blitting
> > an image
> >
> > the other concern is that QSvg can take a good amount of memory to build the
> > render tree, etc.. so sharing renderers is a good idea; and deleting them
> > when not needed anymore is even better.
> >
> > there are two other assumptions that went into my thinking on this that
> > reflect the current state of panels and desktop widgets in kde and other
> > desktops:
> >
> > - items will be long-lived but rarely change size
> > - many items will share identical graphical elements, e.g. widget and button
> > backgrounds
> >
> > i sat down last night and put together a design that will provide for these
> > use cases to avoid duplicating this pattern over and over in the code.
> >
> > Plasma::Svg will provide the following public methods:
> >
> > - Svg(const QString& imagePath, const QSize& size)
> > constructor that takes a path to be used with Plasma::Theme
> > - paint( QPainter*, const QRect& )
> > pretty obvious =)
> > - resize( int width, int height )
> > also pretty obvious
> > - resize( const QSize& size )
> > even more obvious ;)
> >
> > so one would simply do:
> >
> > Plasma::Svg* bg = Plasma::Svg( "dialog/background", QSize( 400, 250 ) );
> >
> > and in the paint method:
> >
> > QPainter p( this );
> > bg->paint( &p, rect() )
> >
> > to facilitate this, Plasma::Theme will be changed to provide a singleton
> > pattern, e.g. Theme* self().
> >
> > what i haven't decided yet, is whether we should check the rect in paint()
> > against the current size and assume that if the rect != rect() that a resize
> > is implied. the usual case will be to call resize() in the painting item's
> > resizeEvent() however, so i don't know if this will buy us anything in
> > practice. at this point i'm taking a wait-and-see-approach on that.
> >
> > the pixmaps will be stored in a QPixmapCache for use throughout the app.
> > therefore, if more than one instance of the same Plasma::Theme image path
> > with the same rendering size is available, there should be no need to hit
> > disk, parse or render the svg. woo! item keys will be constructed this way:
> >
> > ${IMAGE_PATH}_${WIDTH}_${HEIGHT}
> >
> > internally, Plasma::Svg will have a ref-counted shared struct of data
> > containing:
> >
> > - refcount on the QPixmapCache entry
> > - QSvgRenderer. this should prevent multiple instantiations of the renderer.
> >
> > profiling should later show if/when/how the shared renderer should be
> > instantiated and removed. e.g. it may make sense to create the renderer and
> > after a certain amount of time w/out calls to resize to delete it to conserve
> > memory.
> >
> Are we to continue using QAtomic for refcounting or are we going to
> move over to using KShared?
>
> Also, it might be cool if Plasma::Svg could just be a QPaintDevice so
> we could use it just like a QImage/QPixmap with all of this
> checking/caching/refcounting going on behind the scene.. Right now
> though this solution helps manage all the reuse involved with our svg
> images, it still provides the somewhat unintuitive api of svgrenderer
> (the whole calling paint/render on some other class to paint the
> image, instead of the more intuitive approach: just paint the image
> class itself). Just my two cents.
>
> Otherwise, sounds great.
>
>
> -- Matt
>
>
> > --
> > Aaron J. Seigo
> > humru othro a kohnu se
> > GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
> >
> > Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
> >
> > _______________________________________________
> > Panel-devel mailing list
> > Panel-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/panel-devel
> >
> >
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 6 Mar 2007 15:40:10 -0500
> From: Zack Rusin <zack at kde.org>
> Subject: Re: [Panel-devel] rfc: Plasma::Theme and Plasma::Svg
> To: panel-devel at kde.org
> Message-ID: <200703061540.10744.zack at kde.org>
> Content-Type: text/plain; charset="utf-8"
>
> On Tuesday 06 March 2007 13:46, Aaron J. Seigo wrote:
> <snip>
> > i sat down last night and put together a design that will provide for these
> > use cases to avoid duplicating this pattern over and over in the code.
>
> Sounds like a great idea.
>
> > Plasma::Svg will provide the following public methods:
> >
> > - Svg(const QString& imagePath, const QSize& size)
> > constructor that takes a path to be used with Plasma::Theme
>
> Right on.
>
> > - paint( QPainter*, const QRect& )
> > pretty obvious =)
>
> If Svg has a native size then I think the natural paint method for it would
> simply take a point. Otherwise if you'd like to extand to the whole rect
> (which will imply rerendering on the fly anyway) I'd suggest following the
> Qt's scenario where you both accept the source rectangle and destination
> rectangle. But yeah, the QPoint method would be enough.
>
> > - resize( int width, int height )
> > also pretty obvious
> > - resize( const QSize& size )
> > even more obvious ;)
>
> Neat.
>
> > the pixmaps will be stored in a QPixmapCache for use throughout the app.
> > therefore, if more than one instance of the same Plasma::Theme image path
> > with the same rendering size is available, there should be no need to hit
> > disk, parse or render the svg. woo! item keys will be constructed this way:
> >
> > ${IMAGE_PATH}_${WIDTH}_${HEIGHT}
>
> Damn, I have to spoil the party =) This won't work. This won't work because
> you accept an arbitrary painter and try this experiment in widget of your
> choice:
>
> QSvgRender r("file.svg");
> QPixmap px(100, 100);
> QPainter p(&px);
> r.render(&p);
> p.end();
> p.begin(this);
> p.setRenderHint(QPainter::Antialiasing);
> p.scale(2, 2);
> p.drawPixmap(0, 0, px);
> p.end();
>
> Spot Waldo? :) When rendering the pixmap on the widget the painter is scaled
> so we're upscaling the pixmap itself which will produce very ugly results.
> Even worse when you think about any other transformations besides scaling.
> By stuffing pixmap into cache while using the filename/size as the key this is
> the behavior you'll get. The good news is that I did the code to correctly
> cache svg's in an application global fashion in QGraphicsSvgItem so it's not
> a hard problem to get it right (it does involve a bit of math though but I'm
> here :) ). I guess Plasma::Svg will be very similar to QGraphicsSvgItem
> without the QGraphicsItem inheritance and with some nice code to mix it in
> with the rest of Plasma contents. I probably should have created
> QSvgCacheRenderer or maybe even adding caching to QSvgRenderer instead of
> adding it only to QGraphicsSvgItem. Oh, well, maybe in Qt 4.4 ;)
>
> > profiling should later show if/when/how the shared renderer should be
> > instantiated and removed. e.g. it may make sense to create the renderer and
> > after a certain amount of time w/out calls to resize to delete it to
> > conserve memory.
>
> Sounds like a great plan. I'm not sure how well the refcounting of pixmaps
> would work, but it's not a burning thing.
>
> z
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 6 Mar 2007 15:50:58 -0500
> From: Zack Rusin <zack at kde.org>
> Subject: Re: [Panel-devel] rfc: Plasma::Theme and Plasma::Svg
> To: panel-devel at kde.org
> Message-ID: <200703061550.58903.zack at kde.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tuesday 06 March 2007 14:27, Matt Broadstone wrote:
> > Also, it might be cool if Plasma::Svg could just be a QPaintDevice so
> > we could use it just like a QImage/QPixmap with all of this
> > checking/caching/refcounting going on behind the scene..
>
> I think you've confused QPaintDevice with something else. QPaintDevice's
> aren't shared by default at all. It's just so happens that these two specific
> ones are. QPaintDevice's aren't meant to be shared they're meant to be
> painted on, which is not the case for Plasma::Svg. Unless of course you want
> the use case to look like:
> Plasma::Svg svg(100,100);
> QPainter p(&svg);
> p.drawLine(0, 0, 100, 100);
> p.end();
> But I'm not sure what this is supposed to be doing. And if it's meant to be
> saving svg's then Qt 4.3 comes with QSvgGenerator that is a QPaintDevice and
> allows just that (meaning saving QPainter rendering as svg's)
>
> > images, it still provides the somewhat unintuitive api of svgrenderer
> > (the whole calling paint/render on some other class to paint the
> > image,
>
> It's not the image! Svg's /can/ be rendered to images, that's kinda the whole
> point behind Plasma::Svg. Svg's are not images because they don't have
> hardcoded resolutions and can be dynamically changing in time. It's just like
> saying that XHTML are images. The closest to a usecase of svg's in Qt is
> QMovie which emits frame's and would clearly not work for svg's because the
> whole point of QSvgRenderer is to have the ability to render vectors on any
> paint device not only QImage. So yeah, there's a reason it was done the way
> it is. And that reason is: any other way just doesn't come even close to
> cutting it. I kinda hoped that naming the darn thing QSvgRenderer would let
> people not think about it as of an image =)
>
> z
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 6 Mar 2007 14:55:26 -0700
> From: "Aaron J. Seigo" <aseigo at kde.org>
> Subject: Re: [Panel-devel] rfc: Plasma::Theme and Plasma::Svg
> To: panel-devel at kde.org
> Message-ID: <200703061455.26268.aseigo at kde.org>
> Content-Type: text/plain; charset="us-ascii"
>
> On March 6, 2007, Zack Rusin wrote:
> > On Tuesday 06 March 2007 13:46, Aaron J. Seigo wrote:
> > <snip>
> >
> > > i sat down last night and put together a design that will provide for
> > > these use cases to avoid duplicating this pattern over and over in the
> > > code.
> >
> > Sounds like a great idea.
>
> =)
>
> > > Plasma::Svg will provide the following public methods:
> > >
> > > - Svg(const QString& imagePath, const QSize& size)
> > > constructor that takes a path to be used with Plasma::Theme
> >
> > Right on.
>
> ah, and of course just Svg(const QString& imagePath) which will use the
> default size of the svg file.
>
> > > - paint( QPainter*, const QRect& )
> > > pretty obvious =)
> >
> > If Svg has a native size then I think the natural paint method for it would
> > simply take a point. Otherwise if you'd like to extand to the whole rect
> > (which will imply rerendering on the fly anyway) I'd suggest following the
> > Qt's scenario where you both accept the source rectangle and destination
> > rectangle. But yeah, the QPoint method would be enough.
>
> yeah, i considered adding a source rect as well. i'm holding off on that to
> see if have use cases first. it's easier to add API in these cases than it is
> to remove them later.
>
> i will add a QPoint version however.
>
> > Spot Waldo? :) When rendering the pixmap on the widget the painter is
>
> dammit; i always forget about transformations. pffft! who needs them! ;-P
>
> > > profiling should later show if/when/how the shared renderer should be
> > > instantiated and removed. e.g. it may make sense to create the renderer
> > > and after a certain amount of time w/out calls to resize to delete it to
> > > conserve memory.
> >
> > Sounds like a great plan. I'm not sure how well the refcounting of pixmaps
> > would work, but it's not a burning thing.
>
> in common use cases outside of this particular set, probably with highly
> varying results. but looking at the code that is already emerging there are
> patterns that are pretty obvious: the same svg gets used to paint a number of
> identical items.
>
> so as long as the Plasma::Svg's lifespan is matched with the need to paint
> that svg to screen, it should work out ok. the code will need to check that
> the item actually -does- exist in the cache, of course; the refcounting will
> only be there as a hint for when we know we can remove it because it simply
> isn't being used anymore.
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
>
> Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 189 bytes
> Desc: not available
> Url : http://mail.kde.org/pipermail/panel-devel/attachments/20070306/5aa4d564/attachment-0001.pgp
>
> ------------------------------
>
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
>
> End of Panel-devel Digest, Vol 23, Issue 6
> ******************************************
>
More information about the Panel-devel
mailing list