regarding noscript, i didn't write that email but many people are realising what a bad extension it is. the sender's complaints are somewhat different from mine.. as i agree that it is indeed overhyped and everything can be managed with hostperm but having a gui for managing it is certainly needed, that's why i recommend policy manager as an alternative for noscript. my main concerns with noscript is; as we were porting the extension to make it work with kmeleon, we have discovered a lot of weird and unneeded coding (some may even regard as malicious)..it's without doubt that mr. malone has a hidden agenda.
k-meleon is certainly superior when it comes to resource management when compared to xul interface browsers. however with some websites that use plugins like java runtime or rely heavily on actionscript flash; it will appear that kmeleon is intensively using ram but the truth is the plugin the website is calling is the one actually using all that ram and not the other tabs with "normal" websites. that is npswf32.dll is using all that ram through one or 2 websites through kmeleon..and since it's a library, it will not show that the dll is the one actually using all that memory but the executable it's running from. for best cpu, memory tests for any browser; it's advised to test with sites that do not rely on 3rd party plugins.. particularly flash(especially actionscript). that flash 'bug' started appearing after the adobe acquisition and never happened when macromedia was in charge.
acid tests are not really standard compliancy tests as much as graphics rendering accuracy tests and have seldom effect on real browsing. the reason kmeleon has poor scores on acid3 is because kmeleon is still being built on the gecko 1.8 trunk.. so it's not a kmeleon problem per se but more to do with the rendering engine ofcourse. kmeleon gecko trunk is based on the equivalent seamonkey(mozilla) and not firefox because kmeleon was first released on the mozilla engine. kmeleon is more tied to seamonkey than firefox when updating the engine so when seamonkey 2.0 is officially released(still in alpha stages); kmeleon will naturally migrate to the gecko 1.9 trunk which has the better scores in acid3. in theory kmeleon can use the firefox trunk and hence can be kept up-to-date with the equivalent firefox trunk (like orca/lunascape for e.g) but this will require unnecessary coding because ultimately seamonkey will use the latest trunk. in the past mozilla/seamonkey engines were updated at the same pace(if not faster) but there has been a long delay with 1.9 because of some bugs that firefox devs normally ignore where the seamonkey devs prefer to update when everything has been resolved (they have to ensure that everything is working because they have more to work on)
qtweb/webkit engine is a very good engine but in the past has been notorious for unicode rendering(non-latin based characters).. they've come a long way but they still have some issues with unicode and utf-8,16 so when it comes to standard-compliance they're still missing a few things.
|