[Kde-games-devel] Moving first parts of Tagaro into kdegames for 4.6?

[Parker Coates]

On Tue, Sep 21, 2010 at 10:10, Parker Coates wrote:
> On Tue, Sep 21, 2010 at 02:59, Stefan Majewsky wrote:
>> as you might have noticed, we (mostly Brian) are stuck with the KBlocks port.
>> Those games which are being ported from QGraphicsSvgItem to KGameRenderedItem
>> actually become more complex because one has to add new code to determine the
>> renderSize. It would be best if the items could automagically determine their
>> renderSize.
>
> Hello Stefan,
>
> I know this is kind of obvious, but I thought I'd point it out anyway:
> we don't really /need/ to port everything to KGameRenderer. If KBlocks
> (and other QGraphicsSvgItem based games) are running fine, then is
> there really a problem? KGameRenderer was introduced to reduce the
> duplication of and improve the average quality of
> SVG-to-cache-to-pixmap rendering code in our games. QGraphicsSvgItem
> based code had no such code to begin with so there's no way that
> adding a rendering framework with simplify the code. (I understand
> that the performance of QGraphicsSvgItem leaves a lot to be desired,
> but are any of the games currently using it noticeably slow?)
>
> So unless there are currently issues that I'm not aware of, I think
> leaving KBlocks alone should be considered a perfectly valid option
> for SC4.6.

Okay, so according to bug 249849 [1], it seems KBlocks performance is
an issue. Maybe I was wrong and the status quo isn't actually
acceptable.

Parker

[1] https://bugs.kde.org/show_bug.cgi?id=240849