Linked by Thom Holwerda on Sat 14th Feb 2009 12:55 UTC
Thread beginning with comment 348885
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
What native toolkit would this be, as Chrome by definition doesn't have one as a cross-platform application?
Chrome isn't cross platform...yet. It was built with a lot of Windows specific libraries.
While I won't debate the number of users thing (not really at issue here), it doesn't get away from the fact that porting a cross-platform application to specific native platforms, and have it work in the same way, is a world of hurt and pain we have already been through with Firefox and SWT on Linux.
I think you're confused. Firefox and SWT suffered from emulating GTK+, not implementing it. From what I gather from the article Chrome will be using native GTK+ which will make the interface much more consistent with other GNOME/GTK+ applications.
I think you're confused. Firefox and SWT suffered from emulating GTK+, not implementing it. From what I gather from the article Chrome will be using native GTK+ which will make the interface much more consistent with other GNOME/GTK+ applications.
This is not quite true.
Firefox suffers from trying to hook into parts of GTK+. Unfortunately, GTK+ isn't very well-designed, so it is not possible to tell it to draw a random widget. The drawing API has no way of expressing "get me a picture of a GtkButton at this size". The background color must be premultiplied and most themes require an actual instance of a widget as the detail string isn't well-specified. The result is that, whenever Firefox needs to draw a widget, it must have a hidden instance of that widget, and then it must draw it twice, on both black and white background. Then the pixmaps get pulled over from the X server, every pair of pixel is compared in software to recover the original alpha, the image is sent back to the X server, and only then can it be displayed. QGtkStyle has a similar problem and caches all the pixmaps --- I imagine Firefox does the same.
For added fun, since GTK+ was never designed to be embedded into anything, many themes assume they draw their own background and that's why some of them draw ugly borders at the corners of buttons in Firefox.
SWT suffers from another problem. Unlike Firefox, they actually use GTK+ directly, but wrap it in a cross-platform API. Unfortunately, the SWT widget model is slightly different from GTK+'s (it instead matches that of... pretty much every toolkit on the planet). GTK+ itself isn't very flexible, so SWT has to do many many hacks to get around this. As a result, it gets double the performance hit: once for using GTK+ at all and once more for the hacks.
Chrome isn't cross platform...yet. It was built with a lot of Windows specific libraries.
Hmmmm. So it's 'native'..........to Windows? Kind of the point really. It tries to be native, but it isn't at all.
Firefox and SWT suffered from emulating GTK+, not implementing it. From what I gather from the article Chrome will be using native GTK+....
No. They're not emulating it at all, and that's the problem. They are wrapping it so they can use 'native' system calls on each platform.
...which will make the interface much more consistent with other GNOME/GTK+ applications.
That won't happen, because they will have to make cross-platform trade-offs to make it work across all platforms.





Member since:
2005-07-06
What native toolkit would this be, as Chrome by definition doesn't have one as a cross-platform application?
While I won't debate the number of users thing (not really at issue here), it doesn't get away from the fact that porting a cross-platform application to specific native platforms, and have it work in the same way, is a world of hurt and pain we have already been through with Firefox and SWT on Linux.
You end up being a third class citizen behind the platforms and operating systems that have the most users ;-).