[Scummvm-devel] Memory consumption in GUI branch

Vicent Marti tanoku at gmail.com
Sun Oct 5 14:53:33 CEST 2008


Heh, of course we have a deal. Let's see what does everyone else have
to say. Meanwhile, I'll try cross-compiling some builds and testing
them on small platform emulators. That won't give good feedback on
performance, but will probably give good insight on usability and
obvious bugs/regressions.

Vicent Martí
----------------
http://www.smartlikearoboc.com



On Sun, Oct 5, 2008 at 2:16 PM, Max Horn <max at quendi.de> wrote:
>
> Am 05.10.2008 um 13:56 schrieb Vicent Marti:
>
>> Hello Max, everyone:
>>
>> I've also ran my own memory benchmarks; overall, I'd say that the
>> memory consumption on the new GUI is very acceptable, specially when
>> comparing the new features vs the old branch.
>> You are right on those two enormous memory buffers. They are also on
>> the trunk GUI (although they are not called the same) because of a
>> limitation on the SDL/generic backend system. We need to cache the
>> whole overlay in memory and then blit parts of it through the OSystem
>> call because OSystem doesn't offer support for *actually* drawing on
>> the overlay. Maybe this is something that could be worked on.
>>
>> I've implemented a fixed memory pool on the XML parser this morning,
>> together with a new svnmerge and a round of fixes (jeez, looks like
>> everyone loves to break my branch). The speed increase on my computer
>> is only marginal, but I'm guessing it'll be much more significant on
>> other platforms where memory allocation is a problem.
>>
>> I'll keep looking for more places I can cut down to save more memory
>> -- it would be awesome if the new GUI used less memory than the old
>> one. Meanwhile, I can't wait for that merge to happen. :)
>
> Well, from my point of view, I'd prefer merging it ASAP, so that the vkeybd
> branch can be adapted to it, as well as some pending tracker items (like the
> common load dialog patch).
>
> Let's try to be aggressive about it. From our tests, it seems there are no
> regressions at least for desktop users (maybe there still are some tiny
> graphics problems, but if that is the case, they can be fixed on trunk just
> as well in the branch. Plus, the trunk look of the GUI is not set in stone,
> either -- improvements are welcome).
>
> So, the primary blocker is lack of testing on small devices. Fact is, nobody
> is willing to do it right now, it seems. I guess the only way to get it is
> by forcing it...
>
> So here's the deal: If by October 12 (next week), nobody spoke up *against*
> it, I propose we merge the GUI branch into trunk then. And of course after
> that we'll happily collaborate with any and all porters & testers reporting
> regressions of any kind, trying to fix them.
>
> Deal?
>
>
> Cheers,
> Max
>




More information about the Scummvm-devel mailing list