From simon.hausmann at nokia.com Fri Jul 2 08:29:48 2010 From: simon.hausmann at nokia.com (Simon Hausmann) Date: Fri, 2 Jul 2010 17:29:48 +0200 Subject: [webkit-qt] Qt version on bot that tests qtwebkit-2.0 Message-ID: <201007021729.53604.simon.hausmann@nokia.com> Hi Ossy, I've noticed that on the bot that tests qtwebkit-2.0 - http://www.sed.hu/webkit/qtbuildbot/builders/QtWebKit2.0-branch%20x86-32%20Linux%20Release some tests are timing out. Further debugging reveals that the timeout is because of a bug in Qt's GIF image reader. The tests in question do not time out on the trunk build bot, which appears to be using Qt 4.6.2. What version of Qt is the bot running on the 2.0 branch? Would it be possible to bump it to 4.6.2, too? Simon P.S.: Nice that we have backtraces on the crash dumps!! Could you run c++filt on them? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From dvdxvr at gmail.com Sat Jul 3 04:07:36 2010 From: dvdxvr at gmail.com (David Xavier) Date: Sat, 3 Jul 2010 12:07:36 +0100 Subject: [webkit-qt] Spellcheck in QtWebkit Message-ID: Hi, I have an HTML editor implemented in Qt 4.6.2 that uses a contenteditable QWebView. I'd like to enable webkit spell checking in the editable webview (with a line under misspelled words), but I can't seem to get it working. Here's my small test case:

Helo wurld!

This works as expected in Firefox 3.6.6 and Safari 5.0 (the misspelled words are underlined in red), but not in my QWebView based editor. Is this feature currently supported in QtWebkit? Is there something else I have to do to enable it? Thanks David From jedrzej.nowacki at nokia.com Mon Jul 5 00:17:56 2010 From: jedrzej.nowacki at nokia.com (Jedrzej Nowacki) Date: Mon, 5 Jul 2010 09:17:56 +0200 Subject: [webkit-qt] Qt version on bot that tests qtwebkit-2.0 In-Reply-To: <201007021729.53604.simon.hausmann@nokia.com> References: <201007021729.53604.simon.hausmann@nokia.com> Message-ID: <201007050917.56550.jedrzej.nowacki@nokia.com> On Friday 2. July 2010 17.29.48 Hausmann Simon (Nokia-MS-Qt/Oslo) wrote: > Hi Ossy, > > I've noticed that on the bot that tests qtwebkit-2.0 - > > http://www.sed.hu/webkit/qtbuildbot/builders/QtWebKit2.0-branch%20x86-32%20 > Linux%20Release > > some tests are timing out. Further debugging reveals that the timeout is > because of a bug in Qt's GIF image reader. > > The tests in question do not time out on the trunk build bot, which appears > to be using Qt 4.6.2. > > What version of Qt is the bot running on the 2.0 branch? Would it be > possible to bump it to 4.6.2, too? > > > Simon > > P.S.: Nice that we have backtraces on the crash dumps!! Could you run > c++filt on them? :) If I well remember it use the 4.6.2. Jedrek From benjamin.poulain at nokia.com Mon Jul 5 01:28:11 2010 From: benjamin.poulain at nokia.com (benjamin.poulain at nokia.com) Date: Mon, 5 Jul 2010 10:28:11 +0200 Subject: [webkit-qt] Spellcheck in QtWebkit In-Reply-To: References: Message-ID: <779888E5-7BD5-4EFE-8812-AC5924004BA6@nokia.com> Hi, On Jul 3, 2010, at 1:07 PM, ext David Xavier wrote: > I have an HTML editor implemented in Qt 4.6.2 that uses a > contenteditable QWebView. I'd like to enable webkit spell checking in > the editable webview (with a line under misspelled words), but I can't > seem to get it working. > [...] > Is this feature currently supported in QtWebkit? Is there something > else I have to do to enable it? It is not supported. There is no API for spell checking in Qt so this feature cannot be implemented in WebKit. cheers, Benjamin From jonathan.morton at movial.com Wed Jul 7 07:06:52 2010 From: jonathan.morton at movial.com (Jonathan Morton) Date: Wed, 07 Jul 2010 17:06:52 +0300 Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps Message-ID: <1278511612.29985.40.camel@localhost.localdomain> We're trying to figure out a severe performance problem with Webkit on Qt, on hardware which has a very large penalty for software fallbacks. To maximise the hardware's capabilities, we have already added rudimentary support for accelerating linear gradients to both QtGui and the X11/EXA driver for this hardware. This is effective for some instances of linear gradients (eg. on form buttons that appear on a page), but others (such as CSS animations) don't even seem to hit the abstraction layer in Webkit that would pass these commands on to Qt. Breakpoints set in WebCore/platform/graphics/qt/GradientQt.cpp are triggered by the accelerated case but not by the non-accelerated cases. Similarly, atlas maps (used on some high-profile websites to minimise HTTP request count) appear to similarly evade the abstraction layer and result in expensive client-side software fallbacks. As far as we know, no special hardware features are needed to support these - we have made sure that support for sufficiently large image dimensions is available. Where should we be looking in the code to figure out the difference between these cases, and is there any good reason for them? -- ------ From: Jonathan Morton jonathan.morton at movial.com From noam.rosenthal at nokia.com Wed Jul 7 07:21:47 2010 From: noam.rosenthal at nokia.com (noam.rosenthal at nokia.com) Date: Wed, 7 Jul 2010 16:21:47 +0200 Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps In-Reply-To: <1278511612.29985.40.camel@localhost.localdomain> References: <1278511612.29985.40.camel@localhost.localdomain> Message-ID: <3E1170DEF188104E81C5A1C2CDB207E15B7ECE79B7@NOK-EUMSG-01.mgdnok.nokia.com> First of all, which version are you using? If it's 4.7 or 4.6 + a new webkit: I'd check paltform/graphics/qt/GraphicsLayerQt.cpp, and try to disable QWebSettings::AcceleratedCompositingEnabled and see if it helps. That code accelerates CSS animations by drawing the animated components into pixmaps; after which they wouldn't have to repaint themselves with gradients or anything else; my guess is that that's what you're seeing... see http://labs.trolltech.com/blogs/2010/05/17/qtwebkit-now-accelerates-css-animations-3d-transforms/ No'am ________________________________________ From: webkit-qt-bounces at lists.webkit.org [webkit-qt-bounces at lists.webkit.org] On Behalf Of ext Jonathan Morton [jonathan.morton at movial.com] Sent: Wednesday, July 07, 2010 7:06 AM To: webkit-qt at lists.webkit.org Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps We're trying to figure out a severe performance problem with Webkit on Qt, on hardware which has a very large penalty for software fallbacks. To maximise the hardware's capabilities, we have already added rudimentary support for accelerating linear gradients to both QtGui and the X11/EXA driver for this hardware. This is effective for some instances of linear gradients (eg. on form buttons that appear on a page), but others (such as CSS animations) don't even seem to hit the abstraction layer in Webkit that would pass these commands on to Qt. Breakpoints set in WebCore/platform/graphics/qt/GradientQt.cpp are triggered by the accelerated case but not by the non-accelerated cases. Similarly, atlas maps (used on some high-profile websites to minimise HTTP request count) appear to similarly evade the abstraction layer and result in expensive client-side software fallbacks. As far as we know, no special hardware features are needed to support these - we have made sure that support for sufficiently large image dimensions is available. Where should we be looking in the code to figure out the difference between these cases, and is there any good reason for them? -- ------ From: Jonathan Morton jonathan.morton at movial.com _______________________________________________ webkit-qt mailing list webkit-qt at lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt From jonathan.morton at movial.com Wed Jul 7 07:39:36 2010 From: jonathan.morton at movial.com (Jonathan Morton) Date: Wed, 07 Jul 2010 17:39:36 +0300 Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps In-Reply-To: <3E1170DEF188104E81C5A1C2CDB207E15B7ECE79B7@NOK-EUMSG-01.mgdnok.nokia.com> References: <1278511612.29985.40.camel@localhost.localdomain> <3E1170DEF188104E81C5A1C2CDB207E15B7ECE79B7@NOK-EUMSG-01.mgdnok.nokia.com> Message-ID: <1278513576.29985.54.camel@localhost.localdomain> On Wed, 2010-07-07 at 16:21 +0200, noam.rosenthal at nokia.com wrote: > First of all, which version are you using? > If it's 4.7 or 4.6 + a new webkit: It's Qt 4.6.x plus some local patches for the extra accelerated paths, and we're looking at the main svn trunk for Webkit. I think we had a "Webkit 2.0" tree as well, but the behaviour was very similar - I'm not entirely certain what the differences between them are. > I'd check paltform/graphics/qt/GraphicsLayerQt.cpp, and try to disable > QWebSettings::AcceleratedCompositingEnabled and see if it helps. > That code accelerates CSS animations by drawing the animated > components into pixmaps... Seems counter-intuitive, but we'll give it a try. I don't see any direct references to gradients in that file, so presumably they are a mere property of objects passed around in there. Solving this is fairly important - our customer is not pleased with 30sec+ page loads and very difficult scrolling on one of their users' most-visited pages. Pages which don't hit this problem are fine. -- ------ From: Jonathan Morton jonathan.morton at movial.com From jonathan.morton at movial.com Wed Jul 7 08:10:54 2010 From: jonathan.morton at movial.com (Jonathan Morton) Date: Wed, 07 Jul 2010 18:10:54 +0300 Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps In-Reply-To: <3E1170DEF188104E81C5A1C2CDB207E15B7ECE79B7@NOK-EUMSG-01.mgdnok.nokia.com> References: <1278511612.29985.40.camel@localhost.localdomain> <3E1170DEF188104E81C5A1C2CDB207E15B7ECE79B7@NOK-EUMSG-01.mgdnok.nokia.com> Message-ID: <1278515454.29985.56.camel@localhost.localdomain> On Wed, 2010-07-07 at 16:21 +0200, noam.rosenthal at nokia.com wrote: > ...try to disable QWebSettings::AcceleratedCompositingEnabled... It didn't help. Everything that was slow is as slow as before, and the things that were fast are now not so fast. -- ------ From: Jonathan Morton jonathan.morton at movial.com From noam.rosenthal at nokia.com Wed Jul 7 09:12:26 2010 From: noam.rosenthal at nokia.com (noam.rosenthal at nokia.com) Date: Wed, 7 Jul 2010 18:12:26 +0200 Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps In-Reply-To: <1278515454.29985.56.camel@localhost.localdomain> References: <1278511612.29985.40.camel@localhost.localdomain> <3E1170DEF188104E81C5A1C2CDB207E15B7ECE79B7@NOK-EUMSG-01.mgdnok.nokia.com>, <1278515454.29985.56.camel@localhost.localdomain> Message-ID: <3E1170DEF188104E81C5A1C2CDB207E15B7ECE79B8@NOK-EUMSG-01.mgdnok.nokia.com> That path is ruled out then :) Maybe someone else would have an idea... ~No'am ________________________________________ From: ext Jonathan Morton [jonathan.morton at movial.com] Sent: Wednesday, July 07, 2010 8:10 AM To: Rosenthal Noam (Nokia-MS-Qt/RedwoodCity) Cc: webkit-qt at lists.webkit.org Subject: RE: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps On Wed, 2010-07-07 at 16:21 +0200, noam.rosenthal at nokia.com wrote: > ...try to disable QWebSettings::AcceleratedCompositingEnabled... It didn't help. Everything that was slow is as slow as before, and the things that were fast are now not so fast. -- ------ From: Jonathan Morton jonathan.morton at movial.com From ariya.hidayat at gmail.com Wed Jul 7 09:15:47 2010 From: ariya.hidayat at gmail.com (Ariya Hidayat) Date: Wed, 7 Jul 2010 09:15:47 -0700 Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps In-Reply-To: <1278511612.29985.40.camel@localhost.localdomain> References: <1278511612.29985.40.camel@localhost.localdomain> Message-ID: > This is effective for some instances of linear gradients (eg. on form > buttons that appear on a page), but others (such as CSS animations) > don't even seem to hit the abstraction layer in Webkit that would pass > these commands on to Qt. ?Breakpoints set in > WebCore/platform/graphics/qt/GradientQt.cpp are triggered by the > accelerated case but not by the non-accelerated cases. Do you manage to trace the code path from a simple reproduceable example (e.g. CSS animation) to some functions in GraphicsContext class? Do you have that simple example which I can try? -- Ariya Hidayat http://www.linkedin.com/in/ariyahidayat From jonathan.morton at movial.com Wed Jul 7 09:23:14 2010 From: jonathan.morton at movial.com (Jonathan Morton) Date: Wed, 07 Jul 2010 19:23:14 +0300 Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps In-Reply-To: References: <1278511612.29985.40.camel@localhost.localdomain> Message-ID: <1278519794.29985.65.camel@localhost.localdomain> On Wed, 2010-07-07 at 09:15 -0700, Ariya Hidayat wrote: > > This is effective for some instances of linear gradients (eg. on form > > buttons that appear on a page), but others (such as CSS animations) > > don't even seem to hit the abstraction layer in Webkit that would pass > > these commands on to Qt. Breakpoints set in > > WebCore/platform/graphics/qt/GradientQt.cpp are triggered by the > > accelerated case but not by the non-accelerated cases. > > Do you manage to trace the code path from a simple reproduceable > example (e.g. CSS animation) to some functions in GraphicsContext > class? Do you have that simple example which I can try? We have a relatively simple test case for the gradients with CSS animation, but we've been asked to keep distribution of it low for the time being, as it's a prototype for an upcoming site design. I can send it to individual people for serious testing. We also have a (very) simplified version of the AOL UK website which triggers the atlas-maps problem. I've attached that one. -- ------ From: Jonathan Morton jonathan.morton at movial.com -------------- next part -------------- A non-text attachment was scrubbed... Name: aol-1.tar.bz2 Type: application/x-bzip-compressed-tar Size: 6966 bytes Desc: not available URL: From ariya.hidayat at gmail.com Wed Jul 7 10:21:34 2010 From: ariya.hidayat at gmail.com (Ariya Hidayat) Date: Wed, 7 Jul 2010 10:21:34 -0700 Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps In-Reply-To: <1278519794.29985.65.camel@localhost.localdomain> References: <1278511612.29985.40.camel@localhost.localdomain> <1278519794.29985.65.camel@localhost.localdomain> Message-ID: > We have a relatively simple test case for the gradients with CSS > animation, but we've been asked to keep distribution of it low for the > time being, as it's a prototype for an upcoming site design. ?I can send > it to individual people for serious testing. Would it be possible to reduce this into a very simple test case and attach it in bugs.webkit.org as a new bug? If this is related to gradients, it should not be complicated to recreate without exposing any specific site design at all. A full-blown test would be still useful. However, reduced test case would save everyone's time. Regards, Ariya From jonathan.morton at movial.com Wed Jul 7 10:38:36 2010 From: jonathan.morton at movial.com (Jonathan Morton) Date: Wed, 07 Jul 2010 20:38:36 +0300 Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps In-Reply-To: References: <1278511612.29985.40.camel@localhost.localdomain> <1278519794.29985.65.camel@localhost.localdomain> Message-ID: <1278524316.29985.75.camel@localhost.localdomain> On Wed, 2010-07-07 at 10:21 -0700, Ariya Hidayat wrote: > > We have a relatively simple test case for the gradients with CSS > > animation, but we've been asked to keep distribution of it low for the > > time being, as it's a prototype for an upcoming site design. I can send > > it to individual people for serious testing. > > Would it be possible to reduce this into a very simple test case and > attach it in bugs.webkit.org as a new bug? If this is related to > gradients, it should not be complicated to recreate without exposing > any specific site design at all. > > A full-blown test would be still useful. However, reduced test case > would save everyone's time. The atlas maps seem to be the same kind of problem, and we already have a test case for those. Can you work with that? (It's also at bug #41682.) Meanwhile, we're trying to use Callgrind to narrow down the gradient case ourselves. Callgrind doesn't seem to like the JIT, so it's taking extra time to disable it. -- ------ From: Jonathan Morton jonathan.morton at movial.com From ariya.hidayat at gmail.com Wed Jul 7 11:09:07 2010 From: ariya.hidayat at gmail.com (Ariya Hidayat) Date: Wed, 7 Jul 2010 11:09:07 -0700 Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps In-Reply-To: <1278524316.29985.75.camel@localhost.localdomain> References: <1278511612.29985.40.camel@localhost.localdomain> <1278519794.29985.65.camel@localhost.localdomain> <1278524316.29985.75.camel@localhost.localdomain> Message-ID: > The atlas maps seem to be the same kind of problem, and we already have > a test case for those. ?Can you work with that? ?(It's also at bug > #41682.) The test case is hardly qualified as a reduced one. I would imagine that CSS gradient test would consists of a few lines of HTML and inlined CSS only, though. It's not rocket science. Well, then I will have a look at it once someone reduce the test. Or when I find some spare cycles to do it myself. > Meanwhile, we're trying to use Callgrind to narrow down the gradient > case ourselves. ?Callgrind doesn't seem to like the JIT, so it's taking > extra time to disable it. It's probably overkill to use Callgrind for this case, especially if you haven't figured out the code path via Graphics Context down to QPainter yet. Oh BTW, it's a long shot, but did you try to draw the web page's main frame via QWebFrame::render operating on a QPainter WITHOUT antialiasing in its render hints? -- Ariya Hidayat http://www.linkedin.com/in/ariyahidayat From jonathan.morton at movial.com Wed Jul 7 11:34:17 2010 From: jonathan.morton at movial.com (Jonathan Morton) Date: Wed, 07 Jul 2010 21:34:17 +0300 Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps In-Reply-To: References: <1278511612.29985.40.camel@localhost.localdomain> <1278519794.29985.65.camel@localhost.localdomain> <1278524316.29985.75.camel@localhost.localdomain> Message-ID: <1278527657.29985.98.camel@localhost.localdomain> > > Meanwhile, we're trying to use Callgrind to narrow down the gradient > > case ourselves. Callgrind doesn't seem to like the JIT, so it's taking > > extra time to disable it. > > It's probably overkill to use Callgrind for this case, especially if > you haven't figured out the code path via Graphics Context down to > QPainter yet. Tracing things down isn't the problem. We're trying to find the *top* of the stack to trace down from, and so far we only know that it *doesn't* go through some small piece of code that *should* be relevant. We're not exactly Webkit experts (yet). > Oh BTW, it's a long shot, but did you try to draw the web page's main > frame via QWebFrame::render operating on a QPainter WITHOUT > antialiasing in its render hints? That I don't know, but I've mentioned it to people who know how to look into it. -- ------ From: Jonathan Morton jonathan.morton at movial.com From dvdxvr at gmail.com Wed Jul 7 14:58:35 2010 From: dvdxvr at gmail.com (David Xavier) Date: Wed, 7 Jul 2010 22:58:35 +0100 Subject: [webkit-qt] Spellcheck in QtWebkit In-Reply-To: <779888E5-7BD5-4EFE-8812-AC5924004BA6@nokia.com> References: <779888E5-7BD5-4EFE-8812-AC5924004BA6@nokia.com> Message-ID: Hi Benjamin, Thanks for the response. > It is not supported. There is no API for spell checking in Qt so this feature cannot be implemented in WebKit. You say that "this feature cannot be implemented in WebKit" - I thought that it already *was* in webkit as we can see this feature in webkit based browsers such as FireFox and Safari . Also, surely there are lots of aspects of webkit that don't have specific APIs in Qt, yet we still use them in QtWebkit. For example, my Qt based app is happily using the contentEditable and CSS features of WebKit, and there is no specific Qt API for these features. I thought you'd just enable it spell checking by setting a property of an html element, like in my example (as mentioned, this example works as expected in other webkit browsers, which made me believe the feature was already implemented somewhere in webkit, but perhaps not yet in QtWebkit.) David From benjamin.poulain at nokia.com Wed Jul 7 15:38:55 2010 From: benjamin.poulain at nokia.com (benjamin.poulain at nokia.com) Date: Thu, 8 Jul 2010 00:38:55 +0200 Subject: [webkit-qt] Spellcheck in QtWebkit In-Reply-To: References: <779888E5-7BD5-4EFE-8812-AC5924004BA6@nokia.com>, Message-ID: <7061A5DC481BA440B186A36D61EB921D633B58D29F@NOK-EUMSG-04.mgdnok.nokia.com> > > It is not supported. There is no API for spell checking in Qt so this feature cannot be implemented in WebKit. > > You say that "this feature cannot be implemented in WebKit" - I > thought that it already *was* in webkit as we can see this feature in > webkit based browsers such as FireFox and Safari . I was obviously mentioning our port of WebKit. :) Firefox is not using WebKit, its engine is Gecko. cheers, Benjamin From tonikitoo at gmail.com Wed Jul 7 20:13:24 2010 From: tonikitoo at gmail.com (Antonio Gomes (:tonikitoo)) Date: Wed, 7 Jul 2010 23:13:24 -0400 Subject: [webkit-qt] Spellcheck in QtWebkit In-Reply-To: References: Message-ID: Hi David. In my opinion it worth investigation. Please file a bug as feature request in bugzilla. The following link has more detailed instructions: http://trac.webkit.org/wiki/QtWebKitBugs On Sat, Jul 3, 2010 at 7:07 AM, David Xavier wrote: > Hi, > > I have an HTML editor implemented in Qt 4.6.2 that uses a > contenteditable QWebView. I'd like to enable webkit spell checking in > the editable webview (with a line under misspelled words), but I can't > seem to get it working. > > Here's my small test case: > > > > >

Helo wurld!

> > > > This works as expected in Firefox 3.6.6 and Safari 5.0 (the misspelled > words are underlined in red), but not in my QWebView based editor. > > Is this feature currently supported in QtWebkit? Is there something > else I have to do to enable it? > > Thanks > > David > _______________________________________________ > webkit-qt mailing list > webkit-qt at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt > -- --Antonio Gomes From jonathan.morton at movial.com Thu Jul 8 05:49:08 2010 From: jonathan.morton at movial.com (Jonathan Morton) Date: Thu, 08 Jul 2010 15:49:08 +0300 Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps In-Reply-To: References: <1278511612.29985.40.camel@localhost.localdomain> <1278519794.29985.65.camel@localhost.localdomain> <1278524316.29985.75.camel@localhost.localdomain> Message-ID: <1278593348.29985.115.camel@localhost.localdomain> On Wed, 2010-07-07 at 11:09 -0700, Ariya Hidayat wrote: > > Meanwhile, we're trying to use Callgrind to narrow down the gradient > > case ourselves. Callgrind doesn't seem to like the JIT, so it's taking > > extra time to disable it. > > Oh BTW, it's a long shot, but did you try to draw the web page's main > frame via QWebFrame::render operating on a QPainter WITHOUT > antialiasing in its render hints? Yes, and again it has paradoxically made things worse rather than better. > It's probably overkill to use Callgrind for this case, especially if > you haven't figured out the code path via Graphics Context down to > QPainter yet. What Callgrind is now telling us is that Qt's raster engine is being called for two reasons: - To draw a tiled image. - To draw the background of some text. This might itself be tiled. It's not immediately obvious how to enable QtGui to pass these on to XRender, if it isn't already able to do that. Someone mentioned Qt 4.7 earlier. Would upgrading to that help at all? -- ------ From: Jonathan Morton jonathan.morton at movial.com From jonathan.morton at movial.com Thu Jul 8 09:31:34 2010 From: jonathan.morton at movial.com (Jonathan Morton) Date: Thu, 08 Jul 2010 19:31:34 +0300 Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps In-Reply-To: <1278593348.29985.115.camel@localhost.localdomain> References: <1278511612.29985.40.camel@localhost.localdomain> <1278519794.29985.65.camel@localhost.localdomain> <1278524316.29985.75.camel@localhost.localdomain> <1278593348.29985.115.camel@localhost.localdomain> Message-ID: <1278606694.29985.131.camel@localhost.localdomain> On Thu, 2010-07-08 at 15:49 +0300, Jonathan Morton wrote: > What Callgrind is now telling us is that Qt's raster engine is being > called for two reasons: > > - To draw a tiled image. > > - To draw the background of some text. This might itself be tiled. > > It's not immediately obvious how to enable QtGui to pass these on to > XRender, if it isn't already able to do that. It looks very much as though this is something that QtGui can already pass straight to XRender. So why is the Raster backend being used for it instead? -- ------ From: Jonathan Morton jonathan.morton at movial.com From ariya.hidayat at gmail.com Thu Jul 8 09:41:16 2010 From: ariya.hidayat at gmail.com (Ariya Hidayat) Date: Thu, 8 Jul 2010 09:41:16 -0700 Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps In-Reply-To: <1278606694.29985.131.camel@localhost.localdomain> References: <1278511612.29985.40.camel@localhost.localdomain> <1278519794.29985.65.camel@localhost.localdomain> <1278524316.29985.75.camel@localhost.localdomain> <1278593348.29985.115.camel@localhost.localdomain> <1278606694.29985.131.camel@localhost.localdomain> Message-ID: > It looks very much as though this is something that QtGui can already > pass straight to XRender. ?So why is the Raster backend being used for > it instead? There are several cases where the painter falls back to the raster engine. But, as I mentioned before, without knowing the code path from the client side (WebKit) which hits some specific QPainter function in some particular use case, it's hard to find the root cause. While I'm still learning graphics, usually it's not difficult for me to find out why, if the information above is provided. Regards, -- Ariya Hidayat http://www.linkedin.com/in/ariyahidayat From jonathan.morton at movial.com Thu Jul 8 10:25:03 2010 From: jonathan.morton at movial.com (Jonathan Morton) Date: Thu, 08 Jul 2010 20:25:03 +0300 Subject: [webkit-qt] Inconsistent acceleration of linear gradients and atlas maps In-Reply-To: References: <1278511612.29985.40.camel@localhost.localdomain> <1278519794.29985.65.camel@localhost.localdomain> <1278524316.29985.75.camel@localhost.localdomain> <1278593348.29985.115.camel@localhost.localdomain> <1278606694.29985.131.camel@localhost.localdomain> Message-ID: <1278609903.29985.155.camel@localhost.localdomain> On Thu, 2010-07-08 at 09:41 -0700, Ariya Hidayat wrote: > > It looks very much as though this is something that QtGui can already > > pass straight to XRender. So why is the Raster backend being used for > > it instead? > > There are several cases where the painter falls back to the raster engine. > > But, as I mentioned before, without knowing the code path from the > client side (WebKit) which hits some specific QPainter function in > some particular use case, it's hard to find the root cause. > > While I'm still learning graphics, usually it's not difficult for me > to find out why, if the information above is provided. Here are some suspicious places that showed up in the tracebacks from XGetImage(): WebCore::GraphicsContext::fillRect WebCore::GraphicsContext::drawRect WebCore::Image::drawPattern WebCore::RenderTableCell::paintCollapsedBorder WebCore::Font::drawComplexText QCommonStyle::drawPrimitive All of these go straight to the Raster backend without going through any intermediate X11 backend methods. -- ------ From: Jonathan Morton jonathan.morton at movial.com From rich at kde.org Thu Jul 8 13:20:17 2010 From: rich at kde.org (Richard Moore) Date: Thu, 8 Jul 2010 21:20:17 +0100 Subject: [webkit-qt] Currently Missing Features with QtWebkit / QNetworkAccessManager Message-ID: These are the issues I'm aware of with the QtWebkit/QNAM combination as a platform for browsers. It's possible that some of these issues are incorrect and are supported somehow I'm not aware of, if so please say so as that would be great! Note, don't take this as a criticism, it's intended more as a way of organising what remains to be done. * No support for OCSP (online certificate status protocol) * No support for SNI (server name indication) see QTBUG-1352 * No support for EV certificates * No support for DNS pinning (a way of avoiding DNS rebinding attacks) * Incorrect case-sensitivity in MIME type handling (webkit bug #28654). This one is waiting on me (or someone else) finding time to write the test cases. Anyone got anything to add to this todo list? Cheers Rich. From adawit at kde.org Fri Jul 9 00:38:17 2010 From: adawit at kde.org (Dawit A) Date: Fri, 9 Jul 2010 03:38:17 -0400 Subject: [webkit-qt] Currently Missing Features with QtWebkit / QNetworkAccessManager In-Reply-To: References: Message-ID: <201007090338.20681.adawit@kde.org> Here is my 2 cents worth... QtWebKit -------------- 1.) Spell checking support that was just recently discussed in another thread. I personally thing this should be doable since both Chrome & Safari seem to provide this functionality. 2.) Form completion support (bug #36668). Again this is also present in Chrome, not sure about Safari. 3.) Java support (bug # 33044). 4.) HTML 5 media tag support (specially