On Sat, Mar 7, 2009 at 8:23 AM, Christian Packmann <Christian.Packmann@xxxxxx> wrote: > > This will not be much of a problem on high-end machines, where web browsers > cannot tax the CPU anyway, but on lower-spec machines this should be very > noticeable, especially when rendering complex pages. This is a serious > problem, as web browsers are one of the main applications in todays world. > IMHO it wouldn't do to release Haiku R1, have people test it only to find > that their web browsers work half as fast on Haiku than on Windows or Linux. > This will certainly make an impression... just not a good one. Since this is somewhat my current area of expertise/interest (web browsers on Haiku), I'd be interested in any advice you might have to solve or mitigate these issues. Since a lot of the browser computation intensive code (box model, CSS calculations) are in the browser's code and not the OS, could using higher optimization levels in GCC (assuming the browser still works right) solve the speed issues you brought up? Since all the modern browser code we would want to use (WebKit, FF3) relies on newer compilers anyhow, we really aren't stuck with GCC2, but we would still need to make sure the proper GCC4 optimizations are turned on. I am not a compiler expert, but I assume optimizations that might not work on Haiku as a whole could still potentially be used in application code. Plus maybe selective parts of Haiku could be compiled with certain optimizations and then thoroughly tested to be sure they still work right. In this way maybe Haiku could get all the optimizations eventually by a divide and conquer approach. I am very interested in having Haiku perform as well or better than BeOS, and intend to test my browser work on slower machines, so I will soon find out just how true your worries are (and I think they are warranted.) Any advice is appreciated. Regards, Ryan