[webkit-dev] Creating a new MouseEvent type
Dear developers, I am experimenting with a new event type that will contain additional information compared to MouseEvent. In particular since the event is generated for 3D content, there will be 3D hitpoint position and normal. However I am little confused with event generation system and picking. Please let me explain in more detail. I have a number of new element types that I have introduced into WebKit. The only element that has a renderer is 3D scene root element (XML3DXml3dElement). Renderer overrides RenderBox::nodeAtPoint, which returns the node that corresponds to the actual element in the DOM that is under the mouse. Now I need to create XML3DMouseEvent instead of MouseEvent somewhere. I have tried to figure out how the mouse events are generated by stepping through the code. I have learned that for mouse move events WebKit::WebKitImpl::mouseMove starts picking process (that reaches XML3DRenderer::nodeAtPoint at some point), then generates and dispatches the event in Node::dispatchMouseEvent. Should I override Node::dispatchMouseEvent? How can I pass the extra information that I need to put into event from RenderBox::nodeAtPoint to Node::displayMouseEvent? Do I need to extend PlatformMouseEvent class? Thank you for your answers. Sergiy Byelozyorov Computer Graphics Chair Universitat des Saarlandes Tel.: +49 (681) 302-3837 Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse event position related to actual element content
Hello, After some experimenting I have figured out that computing mouse position relative to the actual content (also ignoring all borders, margins and padding) can be done as following: int innerX = xPos - tx - x(); int innerY = yPos - ty - y(); It has worked for me for a long time already. Please let me know if I am wrong and not taking some special cases into account. Sergiy Byelozyorov Computer Graphics Chair Universitat des Saarlandes Tel.: +49 (681) 302-3837 Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/ On Thu, Mar 3, 2011 at 13:50, Sergiy Byelozyorov byelozyo...@cs.uni-saarland.de wrote: Hello, I develop an extension to WebKit which adds support for XML3Dhttp://www.xml3d.org. For mouse events on XML3D element I have created custom event type XML3DMouseEvent that inherits from MouseEvent. In addition to normal coordinates it also has 3D position and normal of the element under the cursor. In order to avoid massive changes into WebKit I have decided to convert existing event from MouseEvent into XML3DMouseEvent when going though overloaded XML3DElement::dispatchEvent which allows me to create custom event class only for XML3D elements. There I also need to perform picking again to actually receive normal and position. However at this stage I don't have actual coordinates where mouse was relative to the actual rendered image (line x, y, tx and ty in RenderObject::nodeAtPoint). All I get is MouseEvent with all it's parameters and the element itself. Originally I tried using pageX and pageY and deducted offsetTop and offsetLeft from them, but this does not take borders and padding into account. I have tried accessing computedStyle to get border and padding width, but the value in there has type Length and I am not sure how to convert it to actual pixels. Please let me know how can mouse event position relative to element content (not to border or padding). If there is a nicer and more straitforward way to implement XML3DMouseEvent I would be happy to hear them. Sergiy Byelozyorov Computer Graphics Chair Universitat des Saarlandes Tel.: +49 (681) 302-3837 Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ImageLoader class
Hello, It took me long before I have figured these things on my own. May be this will be useful for someone. 1. How do I know that the image was loaded already? Can I set up callback somehow? ImageLoader::imageChanged is called whenever new piece of data is decoded (even if this is only part of the whole image). 1. What should functions sourceURI() and dispatchLoadEvent() do? sourceURI should return actual URI while being passed an attribute that contains. dispatchLoadEvent dispatches load event to the DOM. I use implementation similar to HTMLImageLoader for these two methods. 1. What is pixel format for m_imageLoader.image()-image()-data()-data()? Is this the right way to access loaded image raw pixel data? The right way to get an image is the following: Image* image = m_imageLoader.image()-image(); Then depending on the rendering engine one should use different classes. I have only implemented it for SKIA as following: const NativeImageSkia* skiaImage = image-nativeImageForCurrentFrame(); SkBitmap::Config config = skiaImage-config(); // this contains pixel format 1. How can I handle animations (e.g. GIF files)? How do I know when the next image in the animation suquence is ready? Another callback? ImageLoader::imageChanged is also called for animated images. 1. Which image formats are supported? Can I add my own, like HDR? This one I do not know yet :). Thank you. Sergiy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Is vendor-prefixing JavaScript APIs a waste of time?
The IE blog has had a couple posts recently about new JavaScript APIs that are vendor prefixed: http://blogs.msdn.com/b/ie/archive/2011/07/05/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-1.aspx http://blogs.msdn.com/b/ie/archive/2011/07/08/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-2.aspx Here's one of their code examples: 8 // Future-proof: when feature is fully standardized if (window.requestAnimationFrame) window.requestAnimationFrame(draw); // IE implementation else if (window.msRequestAnimationFrame) window.msRequestAnimationFrame(draw); // Firefox implementation else if (window.mozRequestAnimationFrame) window.mozRequestAnimationFrame(draw); // Chrome implementation else if (window.webkitRequestAnimationFrame) window.webkitRequestAnimationFrame(draw); // Other browsers that do not yet support feature else setTimeout(draw, PERIOD); 8 There are a couple things to notice: 1) The requestAnimationFrame API has a vendor prefix in all of these implementations, making this code ugly. 2) The vendor prefix isn't buying us anything because this code assumes that the final, non-prefixed version of the API will work the same way that the vendor prefixed version works! If web developers are going to assume that future, non-prefixed versions of the APIs work the same way as current prefixed versions of the APIs anyway, we shouldn't bother with prefixed versions because we're already locked in to the current behavior, even without the prefix. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is vendor-prefixing JavaScript APIs a waste of time?
I share this concern, but I don't think there's anything special here with
respect to JavaScript APIs. The same argument applies to how people are
often encouraged to use CSS property vendor prefixing.
div {
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}
I'm fairly ambivalent on this. It's not clear to me how much it buys us, but
I can think of examples where it has worked well (e.g. gradients) because we
were able to push the code out and get just enough usage to get useful
feedback, but the usage wasn't so widespread that our hands were tied for
the final API.
There's been an immense uproar about vendor-prefixing on a number of w3c and
whatwg mailing lists in the past year or two. Noone seems especially happy
with the current tradeoffs, but noone has made a better proposal yet either.
Ojan
On Sat, Jul 9, 2011 at 12:56 PM, Adam Barth aba...@webkit.org wrote:
The IE blog has had a couple posts recently about new JavaScript APIs
that are vendor prefixed:
http://blogs.msdn.com/b/ie/archive/2011/07/05/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-1.aspx
http://blogs.msdn.com/b/ie/archive/2011/07/08/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-2.aspx
Here's one of their code examples:
8
// Future-proof: when feature is fully standardized
if (window.requestAnimationFrame) window.requestAnimationFrame(draw);
// IE implementation
else if (window.msRequestAnimationFrame)
window.msRequestAnimationFrame(draw);
// Firefox implementation
else if (window.mozRequestAnimationFrame)
window.mozRequestAnimationFrame(draw);
// Chrome implementation
else if (window.webkitRequestAnimationFrame)
window.webkitRequestAnimationFrame(draw);
// Other browsers that do not yet support feature
else setTimeout(draw, PERIOD);
8
There are a couple things to notice:
1) The requestAnimationFrame API has a vendor prefix in all of these
implementations, making this code ugly.
2) The vendor prefix isn't buying us anything because this code
assumes that the final, non-prefixed version of the API will work the
same way that the vendor prefixed version works!
If web developers are going to assume that future, non-prefixed
versions of the APIs work the same way as current prefixed versions of
the APIs anyway, we shouldn't bother with prefixed versions because
we're already locked in to the current behavior, even without the
prefix.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is vendor-prefixing JavaScript APIs a waste of time?
ArrayBuffer has gone [mostly?] without vendor prefixing,
CSS transforms and RAF (requestAnimationFrames) went with.
createObjectUrl has been touch-and-go.
As a dev, I look at RAF and CSS transforms and wonder why vendors couldn't
agree to those two ahead of time.
Then there is createObjectUrl and ArrayBuffer, which
have had their unexpected changes in (WebIDL) specs and prefixing.
It'd be nice to see a -fast track- decision process which might be tapped
upon for future methods. If the four large vendors agree on a method name
through a fast track process, perhaps devs could skip some vendor prefixing.
The issue there, of course, is that vendors would be tacitly agreeing
to implement such methods. And while they may agree internally
and add it to their road-map, company policy may prohibit
public acknowledgment.
For example, I doubt any vendors object to the basic Typed Array types,
and those types are not currently prefixed.
-Charles
On 7/9/2011 1:33 PM, Ojan Vafai wrote:
I share this concern, but I don't think there's anything special here
with respect to JavaScript APIs. The same argument applies to how
people are often encouraged to use CSS property vendor prefixing.
div {
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}
I'm fairly ambivalent on this. It's not clear to me how much it buys
us, but I can think of examples where it has worked well (e.g.
gradients) because we were able to push the code out and get just
enough usage to get useful feedback, but the usage wasn't so
widespread that our hands were tied for the final API.
There's been an immense uproar about vendor-prefixing on a number of
w3c and whatwg mailing lists in the past year or two. Noone seems
especially happy with the current tradeoffs, but noone has made a
better proposal yet either.
Ojan
On Sat, Jul 9, 2011 at 12:56 PM, Adam Barth aba...@webkit.org
mailto:aba...@webkit.org wrote:
The IE blog has had a couple posts recently about new JavaScript APIs
that are vendor prefixed:
http://blogs.msdn.com/b/ie/archive/2011/07/05/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-1.aspx
http://blogs.msdn.com/b/ie/archive/2011/07/08/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-2.aspx
Here's one of their code examples:
8
// Future-proof: when feature is fully standardized
if (window.requestAnimationFrame) window.requestAnimationFrame(draw);
// IE implementation
else if (window.msRequestAnimationFrame)
window.msRequestAnimationFrame(draw);
// Firefox implementation
else if (window.mozRequestAnimationFrame)
window.mozRequestAnimationFrame(draw);
// Chrome implementation
else if (window.webkitRequestAnimationFrame)
window.webkitRequestAnimationFrame(draw);
// Other browsers that do not yet support feature
else setTimeout(draw, PERIOD);
8
There are a couple things to notice:
1) The requestAnimationFrame API has a vendor prefix in all of these
implementations, making this code ugly.
2) The vendor prefix isn't buying us anything because this code
assumes that the final, non-prefixed version of the API will work the
same way that the vendor prefixed version works!
If web developers are going to assume that future, non-prefixed
versions of the APIs work the same way as current prefixed versions of
the APIs anyway, we shouldn't bother with prefixed versions because
we're already locked in to the current behavior, even without the
prefix.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is vendor-prefixing JavaScript APIs a waste of time?
On Jul 9, 2011, at 22:46 , Charles Pritchard wrote: It'd be nice to see a -fast track- decision process which might be tapped upon for future methods. If the four large vendors agree on a method name through a fast track process, perhaps devs could skip some vendor prefixing. The issue there, of course, is that vendors would be tacitly agreeing to implement such methods. And while they may agree internally and add it to their road-map, company policy may prohibit public acknowledgment. The problem isn't with the naming, but more with the signature, with design changes, and with specification bugs. There are regularly some slight tweaks (e.g. the nullability of a parameter) that will change behaviour, sometimes quite radically. I think that part of the problem is that developers are treating prefixed methods in the same way as they treat prefixed CSS properties. With the latter, chances are that if the code was intended to be anywhere near production, you have a fallback for browsers that don't support the property at all, prefixed or not. Therefore, if the syntax changes and the unprefixed variant you've included fails to do anything, the site is still usable (barring bad luck in how the new syntax interprets data written to the old, which is unlikely). If you do the same with methods though, you risk blowing things up. I think method prefixing is very useful — it gives a lot more leeway for the standards process to fix bugs even in the face of an experimental feature having shipped to tens of millions of users (in fact it's probably more useful for JS than for CSS). But we should do a better job explaining to authors that prefixed methods are meant to be experimental, and that until such a time as a stable definition for a given method is produced the unprefixed variant should simply never be used. Yes, this means a need to update code later. It's just the cost of using experimental methods. I can't fault authors for making this mistake though, code like the one in that IE blog is a common fixture and a quick search couldn't seem to unearth decent advice in this area. -- Robin Berjon - http://berjon.com/ - @robinberjon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is vendor-prefixing JavaScript APIs a waste of time?
Vendor prefixing has proven to be vital to allowing one vendor to experiment with an idea before it has broad support for implementation by other vendors. It also means that we don't need to have coordination between vendors about release schedules for new APIs. Related to that, it also means that we don't dig ourselves a hole by introducing APIs we might later regret, which helps avoid web platform fragmentation. We get the opportunity, via renaming, to greatly alter the behavior of an API and converge on standards. Despite the blog post you quote, RAF is actually a great example of vendor prefixing working well. The original version of mozRAF doesn't work like the current one [ http://weblogs.mozillazine.org/roc/archives/2010/08/mozrequestanima.html]. Note, how it didn't take any arguments, but instead signaled the user via a MozPaintEvent! When we built webkitRAF, we decided that a function argument was better. Mozilla agreed and then changed their implementation. Note, I believe they had never shipped the first version to a stable channel, so it was easy for them to make the change. Sometimes, you can think you are confident enough and have enough agreement on an API to go ahead with a non-vendor prefixed implementation. We did that with Blob.slice. The spec was written by Arun from Mozilla, and there was a lot of review and debate about the API. Mozilla even had an implementation, but they had not shipped it yet. We figured it was unlikely to require vendor prefixing. Well, it turns out that on the eve of Firefox 4, someone realized that it should change to be more like Array.slice. Unfortunately, we had already shipped the old Blob.slice. Our remedy in this case was pretty awful. See http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0222.html. Safari hadn't yet shipped Blob.slice, so only Chrome was impacted by the change. Brendan made a pretty convincing argument that one vendor shipping non-prefixed shouldn't shackle others into implementing the same API [ http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0201.html]. The FileSystem API is another interesting case. Opera has had a FS API forever, but it is totally different than the one that we implemented. The one we implemented for WebKit has not yet been implemented by other vendors, and we haven't really received much feedback. One can imagine that once others begin to implement that they will have interesting feedback that might lead us to wish the API were different. Hence, it makes a lot of sense for the FileSystem API to be vendor prefixed. We get the chance for the non-prefixed version to be materially different. Back to the blog you quoted, I think it is very unfortunate that Microsoft (or any browser vendor) would advocate that people write code using untestable codepaths involving hypothetical unprefixed API. I hope the folks responsible for this one see this thread and fix the issue. Or, maybe someone knows how to get in touch with the right people at Microsoft? -Darin On Sat, Jul 9, 2011 at 12:56 PM, Adam Barth aba...@webkit.org wrote: The IE blog has had a couple posts recently about new JavaScript APIs that are vendor prefixed: http://blogs.msdn.com/b/ie/archive/2011/07/05/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-1.aspx http://blogs.msdn.com/b/ie/archive/2011/07/08/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-2.aspx Here's one of their code examples: 8 // Future-proof: when feature is fully standardized if (window.requestAnimationFrame) window.requestAnimationFrame(draw); // IE implementation else if (window.msRequestAnimationFrame) window.msRequestAnimationFrame(draw); // Firefox implementation else if (window.mozRequestAnimationFrame) window.mozRequestAnimationFrame(draw); // Chrome implementation else if (window.webkitRequestAnimationFrame) window.webkitRequestAnimationFrame(draw); // Other browsers that do not yet support feature else setTimeout(draw, PERIOD); 8 There are a couple things to notice: 1) The requestAnimationFrame API has a vendor prefix in all of these implementations, making this code ugly. 2) The vendor prefix isn't buying us anything because this code assumes that the final, non-prefixed version of the API will work the same way that the vendor prefixed version works! If web developers are going to assume that future, non-prefixed versions of the APIs work the same way as current prefixed versions of the APIs anyway, we shouldn't bother with prefixed versions because we're already locked in to the current behavior, even without the prefix. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org
Re: [webkit-dev] Transformation of German ß to SS and Editing
On Jul 8, 2011, at 1:53 PM, Ryosuke Niwa wrote: I don't fully understand how we're transforming small ß to SS in rendering engine. The function that does it is RenderText::transformText. It is called in RenderText::setTextInternal but also in RenderText::textWithoutTranscoding. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
