Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
Hi Simon. Thank you join the discussion! On Tue, Jul 6, 2010 at 1:46 AM, Simon Fraser simon.fra...@apple.com wrote: On Jul 5, 2010, at 7:35 PM, Antonio Gomes (:tonikitoo) wrote: * adds a Document::nodesFromRect method, exposing the functionality to the dom. It returns a NodeList with all nodes that intersect the given hit-tested area. Is there a reason to use different terminology from the existing elementFromPoint, which would suggest that yours be named elementsFromRect? We (dhyatt and I) originally considered that on irc, but for now it was decided to keep it as nodesFromRect, specially because text nodes are being returned, which is interesting for hit testing matters, in fact. Do you see other objections against the naming, apart from the terminology discrepancy with elementFromPoint? As-is nodesFromRect will be store all nodes whose area intersects the given rect hit test 'til it finds a node whose boundary encloses it completely. At this point hit test will stop at any node in the tree hierarchy. Sample outputs of nodesFromRect for an hypothetical rect X and a html Y are [p , div, body]. For another hypothetical rect Z and the same html Y, nodesFromRect might return [span,div] I assume the nodes are listed in front-to-back z-order? They are, yes. In the later sample output, note that it did not reach body , whose boundary obvious intersects any possible given Z rect. That would happen if the div in case encloses the rect Z completely, and it would be the stop point for the hit test. In Mozilla's implementation, nodesFromRect does not care if a node encloses the hit test rect completely or partially. The test will continue until the body. What would be the preferable behavior for our implementation? The latter behavior may actually make the method useful for things other than hit testing, if that sways your decision at all. I can imagine page authors finding it useful to be able to find out all the elements that are under a given point (which in turn suggests that elementsFromRect with zero padding should still find all the hit elements in z-order). Exactly the point. For hit test matters, stopping as soon as it gets fully enclosed makes total sense to me. On the other hand, as you said, I bet there might be use cases like give me all nodes under X, Y, with padding W, H (where they can be '0'). I thought about making this stop an optional flag for HitTestResult or HitTestRequest. Would it be acceptable? One thing that this functionality does not allow you to do is to find the *closest* node to the given point that matches some set of criteria (like being clickable). This might be a more useful thing for a mobile browser. Right, as for mozilla's implementation, this method main goal is to provide the list of nodes. Any post-processing over the resulting list would be responsibility of the caller site, including calculating the shortest distance rect, or consider the more frequently visited elements (in case of links), etc. -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
On Jul 6, 2010, at 5:54 AM, Antonio Gomes (:tonikitoo) wrote: Hi Simon. Thank you join the discussion! On Tue, Jul 6, 2010 at 1:46 AM, Simon Fraser simon.fra...@apple.com wrote: On Jul 5, 2010, at 7:35 PM, Antonio Gomes (:tonikitoo) wrote: * adds a Document::nodesFromRect method, exposing the functionality to the dom. It returns a NodeList with all nodes that intersect the given hit-tested area. Is there a reason to use different terminology from the existing elementFromPoint, which would suggest that yours be named elementsFromRect? We (dhyatt and I) originally considered that on irc, but for now it was decided to keep it as nodesFromRect, specially because text nodes are being returned, which is interesting for hit testing matters, in fact. Do you see other objections against the naming, apart from the terminology discrepancy with elementFromPoint? If it's a considered decision, I'm OK with it. In the later sample output, note that it did not reach body , whose boundary obvious intersects any possible given Z rect. That would happen if the div in case encloses the rect Z completely, and it would be the stop point for the hit test. In Mozilla's implementation, nodesFromRect does not care if a node encloses the hit test rect completely or partially. The test will continue until the body. What would be the preferable behavior for our implementation? The latter behavior may actually make the method useful for things other than hit testing, if that sways your decision at all. I can imagine page authors finding it useful to be able to find out all the elements that are under a given point (which in turn suggests that elementsFromRect with zero padding should still find all the hit elements in z-order). Exactly the point. For hit test matters, stopping as soon as it gets fully enclosed makes total sense to me. On the other hand, as you said, I bet there might be use cases like give me all nodes under X, Y, with padding W, H (where they can be '0'). I thought about making this stop an optional flag for HitTestResult or HitTestRequest. Would it be acceptable? I'd resist adding this until we have a use case for it. One thing that this functionality does not allow you to do is to find the *closest* node to the given point that matches some set of criteria (like being clickable). This might be a more useful thing for a mobile browser. Right, as for mozilla's implementation, this method main goal is to provide the list of nodes. Any post-processing over the resulting list would be responsibility of the caller site, including calculating the shortest distance rect, or consider the more frequently visited elements (in case of links), etc. Got it. What you have sounds fine. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web SQL Database API - openDatabaseSync
Andrei, On page: http://www.ibm.com/developerworks/library/x-html5mobile4/ I see: Starting with Android 2.0, the Android browser has had full support for the HTML 5 Web Worker specification. Is the quoted page incorrect about Web Workers on Android? (It seems to contradict what you wrote below). I was hoping to do some prototyping with Web Workers and Google Gears on Android until such time as the sync database API is available. But perhaps I will need to limit testing to desktop Chrome for the moment. -Original Message- From: Andrei Popescu [mailto:andr...@google.com] Sent: Friday, July 02, 2010 3:54 AM To: Eric Uhrhane Cc: Evan Ireland; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Web SQL Database API - openDatabaseSync Hi, On Fri, Jul 2, 2010 at 2:40 AM, Eric Uhrhane er...@google.com wrote: I doubt that it's been pushed to any Android phone yet. It only went into webkit in the past couple of months, and there's a bit of lag as they incorporate new code. You'd have to ask Android folks when they plan to ship it. Async Web SQL Database is available on Android since version 2.0. Sync Web SQL Database and Web Workers are not currently available on Android (not even on 2.2). Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] [svg] anti-aliasing artifacts
How hard would it be to add full-scene anti-aliasing to WebKit's SVG implementation? I love SVG, but I'm often stymied by jaggies and color bleeding that appear between contiguous shapes.* I can sometimes avoid aliasing artifacts, say by shape-rendering: crispEdges. Similarly, I can round pixel locations to avoid subpixels. However, these work-arounds have obvious drawbacks, by disabling anti-aliasing and disallowing precise path geometry. Furthermore, other artifacts are unavoidable, as shape-rendering / image-rendering doesn't work for images, nor transformed clipPaths, and integer pixels don't help if the containing g element has transform=scale(...). Thanks, Mike * For example: https://bugs.webkit.org/show_bug.cgi?id=35211 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [62546] trunk/WebCore
We do sometimes land changes that are reviewed on IRC and that don't correspond to bugs. The main criteria for when this is appropriate are: - the change is simple, and doesn't need many eyes looking at it; - there is no historical trail to maintain, no one is going to look at svn blame and wonder why this change was made 10 years ago. A change that modifies cross platform code to fix a platform specific (?) crash, and that doesn't even include a test case definitely needs to be tracked in WebKit Bugzilla. - WBR, Alexey Proskuryakov 06.07.2010, в 5:52, k...@webkit.org написал(а): Revision 62546 Author k...@webkit.org Date 2010-07-06 05:52:30 -0700 (Tue, 06 Jul 2010) Log Message 2010-07-06 Gustavo Noronha Silva gustavo.noro...@collabora.co.uk Rubber-stamped by Xan Lopez. Crash when hitting back on some pages http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575236 Also NULL-check document, in hopes of fixing this hard to reproduce crash that we are getting reported quite a bit. * page/FrameView.cpp: (WebCore::FrameView::windowClipRect): Modified Paths trunk/WebCore/ChangeLog trunk/WebCore/page/FrameView.cpp Diff Modified: trunk/WebCore/ChangeLog (62545 = 62546) --- trunk/WebCore/ChangeLog 2010-07-06 12:11:06 UTC (rev 62545) +++ trunk/WebCore/ChangeLog 2010-07-06 12:52:30 UTC (rev 62546) @@ -1,3 +1,16 @@ +2010-07-06 Gustavo Noronha Silva gustavo.noro...@collabora.co.uk + +Rubber-stamped by Xan Lopez. + +Crash when hitting back on some pages +http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575236 + +Also NULL-check document, in hopes of fixing this hard to +reproduce crash that we are getting reported quite a bit. + +* page/FrameView.cpp: +(WebCore::FrameView::windowClipRect): + 2010-07-05 Ilya Tikhonovsky loi...@chromium.org Reviewed by Yury Semikhatsky. Modified: trunk/WebCore/page/FrameView.cpp (62545 = 62546) --- trunk/WebCore/page/FrameView.cpp 2010-07-06 12:11:06 UTC (rev 62545) +++ trunk/WebCore/page/FrameView.cpp 2010-07-06 12:52:30 UTC (rev 62546) @@ -1670,7 +1670,7 @@ // Set our clip rect to be our contents. IntRect clipRect = contentsToWindow(visibleContentRect(! clipToContents)); -if (!m_frame || !m_frame-document()-ownerElement()) +if (!m_frame || !m_frame-document() || !m_frame-document()- ownerElement()) return clipRect; // Take our owner element and get the clip rect from the enclosing layer. ___ webkit-changes mailing list webkit-chan...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit3D for Android?
Hello WebKitters... Is anyone working on / has an implementation of WebKit3D for Android powered devices? Any info anyone might have would be helpful. Thanks! -Hafez Rouzati ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [62546] trunk/WebCore
Hello, On Tue, 2010-07-06 at 11:13 -0700, Alexey Proskuryakov wrote: We do sometimes land changes that are reviewed on IRC and that don't correspond to bugs. The main criteria for when this is appropriate are: - the change is simple, and doesn't need many eyes looking at it; - there is no historical trail to maintain, no one is going to look at svn blame and wonder why this change was made 10 years ago. A change that modifies cross platform code to fix a platform specific (?) crash, and that doesn't even include a test case definitely needs to be tracked in WebKit Bugzilla. You are right. I at first believed the bug report I mentioned along with the change description would suffice (since mentioning non-webkit-bugzilla trackers is fairly common, and the trace is pretty straightforward), but I believe for this change a webkit bug with a bit more information on the problem we're addressing is in order indeed! I have opened https://bugs.webkit.org/show_bug.cgi?id=41710 and will add that as reference to the ChangeLog. Thanks! -- Gustavo Noronha Silva gustavo.noro...@collabora.co.uk Collabora Ltd. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [62546] trunk/WebCore
06.07.2010, в 12:18, Gustavo Noronha Silva написал(а): I have opened https://bugs.webkit.org/show_bug.cgi?id=41710 and will add that as reference to the ChangeLog. Thanks! Editing ChangeLog post factum is less useful that having it right from the start, since svn logs for the source file will only have the original version, but a determined person may be able to find the modified version. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
