The display-list dump is now a central feature for graphics debugging and will now be used by the profiler to visualize painting. We should make this available by default.

Comment on attachment 8539515 [details] [diff] [review] patch Review of attachment 8539515 [details] [diff] [review]: ----------------------------------------------------------------- What's the reason for the gfxUtils.cpp change? I think checking an env variable just once on startup should be fine, performance-wise.

I didn’t want to check an env variable for something that would never get used

Forgot to remove the #ifdef for nsDisplayGeneric::mName.

does what I said in v2 but properly this time.

minor tweaks

UniqueSelector calls operator new whichs gets translated to valgrind's memcheck malloc, but the UniquePtr reset() calls memchecks operator delete. Could this be a bug in either memcheck or our memory shim? Outwardly we're calling both opeator new / operator delete.

(In reply to Benoit Girard (:BenWa) from comment #8) > Could this be a bug in either memcheck or our memory shim? Outwardly we're > calling both opeator new / operator delete. The Gecko code is fine; you can safely ignore this. FWIW it happens because |operator new| is inlined into its caller |detail::UniqueSelector| ==47856== by 0x7625757: moz_xmalloc (mozalloc.cpp:52) ==47856== by 0x9807C96: operator new (mozalloc.h:210) ==47856== by 0x9807C96: mozilla::detail::UniqueSelector<std::basic_st[..] whereas |operator delete| isn't ==47856== at 0x4C2827E: operator delete(void*) (in /usr/lib64/valgrin[..] ==47856== by 0x54F5D6C: std::basic_stringstream<char, std::char_trait[..] so Memcheck can intercept calls to |delete| but there's no call to |new| to intercept; instead it intercepts only the |malloc| called by |new|. For now you can run with --show-mismatched-frees=no. Alternatively try building Fx with -O2, since I suspect that increases the inlining aggressiveness and causes both |new| and |delete| to get inlined, removing the asymmetry.