Bug 109627 - [GTK] Remove the GLib unicode backend
Summary: [GTK] Remove the GLib unicode backend
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Martin Robinson
Depends on:
Reported: 2013-02-12 16:21 PST by Martin Robinson
Modified: 2013-02-13 09:30 PST (History)
10 users (show)

See Also:

Patch (65.67 KB, patch)
2013-02-12 21:31 PST, Martin Robinson
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Robinson 2013-02-12 16:21:30 PST
The GLib unicode backend is unused in Gnome and incomplete at the moment. Additionally it requires conversion to UTF-8 everywhere, so it will never match the performance of the ICU one. ICU is used by almost all other ports and gives us consistency.
Comment 1 Martin Robinson 2013-02-12 16:23:34 PST
Carlos did a lot of really nice cleanup to the GLib backend a few years back, so I'm a bit sad to be proposing this. At the same time, the design of the GLib API (UTF-8 only) suggest that the performance characteristics of the backend will be worse than those of the ICU backend. Since this is used throughout WebCore we really need this code to be fast.
Comment 2 Martin Robinson 2013-02-12 21:31:20 PST
Created attachment 188006 [details]
Comment 3 Benjamin Poulain 2013-02-12 22:03:54 PST
Comment on attachment 188006 [details]

I think focusing on ICU is a great idea.
Comment 4 WebKit Review Bot 2013-02-12 22:32:21 PST
Comment on attachment 188006 [details]

Clearing flags on attachment: 188006

Committed r142724: <http://trac.webkit.org/changeset/142724>
Comment 5 WebKit Review Bot 2013-02-12 22:32:24 PST
All reviewed patches have been landed.  Closing bug.
Comment 6 Andrew Wilson 2013-02-13 02:11:44 PST
Reopening to attach new patch.
Comment 7 Andrew Wilson 2013-02-13 02:12:51 PST
Sorry, didn't mean to reopen this.
Comment 8 Zoltan Arvai 2013-02-13 02:32:43 PST
It seems some traces of GLib unicode are still present in the sources:

WTF/WTF.gypi:258:            'wtf/unicode/glib/UnicodeGLib.cpp',
WTF/WTF.gypi:259:            'wtf/unicode/glib/UnicodeGLib.h',
WTF/wtf/unicode/Unicode.h:34:#include <wtf/unicode/glib/UnicodeGLib.h>

WebCore/platform/text/TextEncoding.cpp:40:#elif USE(GLIB_UNICODE)
WebCore/platform/text/TextEncoding.cpp:107:#elif USE(GLIB_UNICODE)
WebCore/platform/text/TextEncodingRegistry.cpp:48:#if USE(GLIB_UNICODE)
WebCore/platform/text/TextEncodingRegistry.cpp:229:#if USE(GLIB_UNICODE)
WebCore/platform/text/TextEncodingRegistry.cpp:301:#if USE(GLIB_UNICODE)
WebCore/platform/KURL.cpp:47:#elif USE(GLIB_UNICODE)
WebCore/platform/KURL.cpp:1483:#elif USE(GLIB_UNICODE)
WTF/wtf/unicode/Unicode.h:33:#elif USE(GLIB_UNICODE)
Comment 9 Andrew Wilson 2013-02-13 02:37:28 PST
I'm fixing the .gypi references since they break the chromium bots. I'm not doing anything with the #defines in the code, though.
Comment 10 Dominik Röttsches (drott) 2013-02-13 04:13:05 PST
*sniff* Feeling nostalgic to see my first ever WebKit contribution going away...

But agree it makes sense. Performance isn't the only thing where it wouldn't match ICU. Word breaking behavior was not really identical.
Comment 11 Martin Robinson 2013-02-13 09:30:05 PST
Cleanup is here: https://bugs.webkit.org/show_bug.cgi?id=109707