[Scummvm-devel] Memory consumption in GUI branch

[Max Horn]

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