Hi,
see QWebSettings::clearMemoryCaches() (WebKit/qt/Api/qwebsettings.cpp) to
clear memory caches and qt_drt_garbageCollector_collect
(WebKit/qt/Api/qwebframe.cpp) to call the garbage collector.
Zoltan
> On Oct 1, 2009, at 6:24 PM, Peter Kasting wrote:
>
>> * Does anyone already know the likely
On Oct 1, 2009, at 6:24 PM, Peter Kasting wrote:
* Does anyone already know the likely footprint of the Glyph cache,
or how to clear it?
FontCache::purgeInactiveFontData().
If you’re using Safari then you can see Font and Glyph Caches
statistics in its Caches window, which also includes a
In Chromium, we have various events that we'd like to respond to by freeing
as much memory as possible. (One example is system sleep, where we'd like
to dump memory before sleeping to avoid having to page it back in after
waking.)
I'm trying to find what areas in WebCore are good candidates for t
OK, I agree as well - skipping is not a good solution here; I don't think
the status quo is perfect, yet probably not imperfect enough to do anything
about :)
I guess there's just a process wrinkle we need to address on the Chromium
side. It's easy to rebaseline a test in Chromium, but less easy to
On Oct 1, 2009, at 11:58 AM, Eric Seidel wrote:
I think more you're identifying that there is a test hierarchy
problem here. Chromium really wants to base its tests off of some
base "win" implementation, and then "win-apple", "win-chromium",
"win-cairo" results could derive from that, simi
I agree with Darin. I don't think that this is a good example of
where skipping would be useful.
I think more you're identifying that there is a test hierarchy problem
here. Chromium really wants to base its tests off of some base "win"
implementation, and then "win-apple", "win-chromium", "win-
On Thu, Oct 1, 2009 at 11:47 AM, Darin Adler wrote:
> On Oct 1, 2009, at 11:41 AM, Drew Wilson wrote:
>
>> I don't have an opinion about flakey tests, but flat-out-busted tests
>> should get skipped. Any thoughts/objections?
>
> I object.
>
> If a test fails on some platforms and succeeds on other
On Oct 1, 2009, at 11:41 AM, Drew Wilson wrote:
I don't have an opinion about flakey tests, but flat-out-busted
tests should get skipped. Any thoughts/objections?
I object.
If a test fails on some platforms and succeeds on others, we should
have the success result checked in as the default
I wanted to re-open this discussion with some real-world feedback.
In this case, there was a failure in one of the layout tests on the windows
platform, so following the advice below, aroben correctly checked in an
update to the test expectations instead of skipping the tests.
Downstream, this bus
9 matches
Mail list logo