[webkit-dev] prototype for adding new feature in CSS using webkit
Dear All, I want to make prototype for adding new feature in CSS using webkit_clutter and try to launch css application using ClutterLuancher. For that, I have chosen Animation properties for my understanding, Under which I have chosen only to add replicate of duration properties. Say for example, if flag is webkit-animation-duration then I wants to add same feature with different name like webkit-animation-duration1.For that I made some changes in following class Path: Source\WebCore\css CSSComputedStyleDeclaration CSSParser CSSProperty CSSPropertyNames.in StyleBuilder Path:Source\WebCore\rendering\ style RenderStyle And some changes related to Animation in folder Path:source\webcore\platform\animation Animation.h AnimationList.cpp (source\webcore\platform\animation): Problem Statement: I am setting duration like Like webkit-animation-duration1=2 and able to set the duration in api setDuration1()(replicate of setDuration). But problem is that it is not giving same behaviour as webkit-animation-duration. I mean object is not animating. I have attached sample css based application for your reference. Working file File.html and not working file File1.html Thanks Regards, Muke Note: This example does not work in Internet Explorer. Note: This example does not work in Internet Explorer. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Followup on removing webkitNotifications.createHTMLNotification
Hmmm. Does FeatureObserver detect features invoked from web apps like Gmail? Because I'm fairly certain that Gmail and Google Calendar still use webkitNotifications for their notifications. Not to say that we shouldn't land this patch anyway - just pointing out that this may still be used more often than your stats would indicate. -atw On Wed, Jan 23, 2013 at 1:47 AM, Adam Barth aba...@webkit.org wrote: As discussed in February 2012 [1], we have been deprecating the webkitNotifications.createHTMLNotification API for almost a year. According to FeatureObserver, the API is used in only 0.0008% of web page views, indicating that we have been successful in depreciating it. I've posted a patch to remove it: https://bugs.webkit.org/show_bug.cgi?id=107598 Thanks, Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-February/019354.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Followup on removing webkitNotifications.createHTMLNotification
On Wed, Jan 23, 2013 at 12:45 AM, Andrew Wilson atwil...@google.com wrote: Hmmm. Does FeatureObserver detect features invoked from web apps like Gmail? Yes. Because I'm fairly certain that Gmail and Google Calendar still use webkitNotifications for their notifications. Not to say that we shouldn't land this patch anyway - just pointing out that this may still be used more often than your stats would indicate. As Morrita-san writes: On Wed, Jan 23, 2013 at 12:50 AM, Hajime Morrita morr...@google.com wrote: It looks the patch is removing a specific API called createHTMLNotification(). Unless these apps are showing HTML-based notification, it should keep working even after this change. If Gmail is still using the vendor-prefixed webkitNotifications version of the API, they should update to the unprefixed new Notification version of the API, which is implemented by a number of different browsers. I know there's some amount of confusion about the current status of the web notification APIs. I'm working with Chrome's developer relation folks to update our various pieces of documentation and tutorials. Adam On Wed, Jan 23, 2013 at 1:47 AM, Adam Barth aba...@webkit.org wrote: As discussed in February 2012 [1], we have been deprecating the webkitNotifications.createHTMLNotification API for almost a year. According to FeatureObserver, the API is used in only 0.0008% of web page views, indicating that we have been successful in depreciating it. I've posted a patch to remove it: https://bugs.webkit.org/show_bug.cgi?id=107598 Thanks, Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-February/019354.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Followup on removing webkitNotifications.createHTMLNotification
Apologies for the confusion - I should have finished my coffee before reading my mail. I didn't realize this only impacts HTML notifications. It's still a good reminder that Google really should migrate to the new notification APIs, though. I'll get the ball rolling on gmail, at least. -atw On Wed, Jan 23, 2013 at 9:58 AM, Adam Barth aba...@webkit.org wrote: On Wed, Jan 23, 2013 at 12:45 AM, Andrew Wilson atwil...@google.com wrote: Hmmm. Does FeatureObserver detect features invoked from web apps like Gmail? Yes. Because I'm fairly certain that Gmail and Google Calendar still use webkitNotifications for their notifications. Not to say that we shouldn't land this patch anyway - just pointing out that this may still be used more often than your stats would indicate. As Morrita-san writes: On Wed, Jan 23, 2013 at 12:50 AM, Hajime Morrita morr...@google.com wrote: It looks the patch is removing a specific API called createHTMLNotification(). Unless these apps are showing HTML-based notification, it should keep working even after this change. If Gmail is still using the vendor-prefixed webkitNotifications version of the API, they should update to the unprefixed new Notification version of the API, which is implemented by a number of different browsers. I know there's some amount of confusion about the current status of the web notification APIs. I'm working with Chrome's developer relation folks to update our various pieces of documentation and tutorials. Adam On Wed, Jan 23, 2013 at 1:47 AM, Adam Barth aba...@webkit.org wrote: As discussed in February 2012 [1], we have been deprecating the webkitNotifications.createHTMLNotification API for almost a year. According to FeatureObserver, the API is used in only 0.0008% of web page views, indicating that we have been successful in depreciating it. I've posted a patch to remove it: https://bugs.webkit.org/show_bug.cgi?id=107598 Thanks, Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-February/019354.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Followup on removing webkitNotifications.createHTMLNotification
On Wed, Jan 23, 2013 at 1:08 AM, Andrew Wilson atwil...@google.com wrote: Apologies for the confusion - I should have finished my coffee before reading my mail. I didn't realize this only impacts HTML notifications. It's still a good reminder that Google really should migrate to the new notification APIs, though. I'll get the ball rolling on gmail, at least. Thanks! Let me know if you run into any trouble. Adam On Wed, Jan 23, 2013 at 9:58 AM, Adam Barth aba...@webkit.org wrote: On Wed, Jan 23, 2013 at 12:45 AM, Andrew Wilson atwil...@google.com wrote: Hmmm. Does FeatureObserver detect features invoked from web apps like Gmail? Yes. Because I'm fairly certain that Gmail and Google Calendar still use webkitNotifications for their notifications. Not to say that we shouldn't land this patch anyway - just pointing out that this may still be used more often than your stats would indicate. As Morrita-san writes: On Wed, Jan 23, 2013 at 12:50 AM, Hajime Morrita morr...@google.com wrote: It looks the patch is removing a specific API called createHTMLNotification(). Unless these apps are showing HTML-based notification, it should keep working even after this change. If Gmail is still using the vendor-prefixed webkitNotifications version of the API, they should update to the unprefixed new Notification version of the API, which is implemented by a number of different browsers. I know there's some amount of confusion about the current status of the web notification APIs. I'm working with Chrome's developer relation folks to update our various pieces of documentation and tutorials. Adam On Wed, Jan 23, 2013 at 1:47 AM, Adam Barth aba...@webkit.org wrote: As discussed in February 2012 [1], we have been deprecating the webkitNotifications.createHTMLNotification API for almost a year. According to FeatureObserver, the API is used in only 0.0008% of web page views, indicating that we have been successful in depreciating it. I've posted a patch to remove it: https://bugs.webkit.org/show_bug.cgi?id=107598 Thanks, Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-February/019354.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit
On 01/23/2013 01:43 AM, Allan Sandfeld Jensen wrote: On Wednesday 23 January 2013, Balazs Kelemen wrote: On 01/22/2013 05:14 PM, Zoltan Herczeg wrote: Where in WebKit do you experience problems with color conversion? As for me WebKit2 transmits BGRA images, which needs to be converted to RGBA before it is uploaded to a texture on GLES 2.0. These conversions seems computation heavy for certain animations, and I was wondered whether do we really need to use BGRA here. It would be nice to invent something to avoid that. You explained the symptom but not the source of the problem. So, do you know _why_ do we have BGRA before the texture upload? If this is a software rendered image buffer, why can't we just use the appropriate format when doing the software rendering? Anybody? Because it is a 32bit buffer of ARGB values. On a little endian CPU like i386, 32bit ARGB is stored bytewise as BGRA. In Qt we always have 32bit ARGB values because that is the internal color format of the Qt renderer (QRgb). In the grand scheme of things it is probably easier up to upload BGRA textures than trying to double the rendering paths of QPainter to support RGBA. A quick little overview of what I am talking about: ARGB format aka RGBA32 (32bit ordered) As 32bit math 8bit big endian 8bit little endian 24-31bit: A 1.byte: A 1.byte B 16-23bit: R 2.byte. R 2.byte G 8-15bit: G3.byte. G 3.byte R 0-7bit: B4.byte. B 4.byte A RGBA format aka RGBA8 (byte-ordered) As byte format32bit big endian 32bit little endian 1.byte: R 24-31bit: R 24-31bit: A 2.byte: G 16-23bit: G 16-23bit: B 3.byte: B 8-15bit: B 8-15bit: G 4.byte: A0-7bit: A0-7bit: R Ofcourse the confusion can be avoided if RGBA8 is only accesed bytewise, and ARGB only 32bit wise, but when uploading to textures or otherwise serializing it we need to deal with the mess. Thanks, that was useful to me. I did not know that the internal format is byte order agnostic. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] build.webkit.org down
build.webkit.org went down over night due to running out of disk space. I'm working to bring it back as soon as possible. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] build.webkit.org down
build.webkit.org is back up. I reduced the retention of build archives from 2 weeks to 1 week to regain enough space to get the master running again. I'm still waiting on space calculations to figure out what ate up all of the space (the server uses 9TB of space currently after deleting 1TB of archives). We had over 2TB free last I checked manually, but our server monitor had a typo in its config that made the build.webkit.org's space usage report 5x lower than it actually was, so I did not get any alarms until it was too late. The server might be slow for a while due to the extra CPU and IO load of my space calculations. -Bill On Jan 23, 2013, at 7:57 AM, William Siegrist wsiegr...@apple.com wrote: build.webkit.org went down over night due to running out of disk space. I'm working to bring it back as soon as possible. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Followup on removing webkitNotifications.createHTMLNotification
Happy to hear about this! As a follow-up question, what numbers are you seeing with the rest of the legacy API? (webkitNotifications.createNotification, webkitNotifications.checkPermission, and webkitNotifications.requestPermission) Jon On Jan 23, 2013, at 1:11 AM, Adam Barth aba...@webkit.org wrote: On Wed, Jan 23, 2013 at 1:08 AM, Andrew Wilson atwil...@google.com wrote: Apologies for the confusion - I should have finished my coffee before reading my mail. I didn't realize this only impacts HTML notifications. It's still a good reminder that Google really should migrate to the new notification APIs, though. I'll get the ball rolling on gmail, at least. Thanks! Let me know if you run into any trouble. Adam On Wed, Jan 23, 2013 at 9:58 AM, Adam Barth aba...@webkit.org wrote: On Wed, Jan 23, 2013 at 12:45 AM, Andrew Wilson atwil...@google.com wrote: Hmmm. Does FeatureObserver detect features invoked from web apps like Gmail? Yes. Because I'm fairly certain that Gmail and Google Calendar still use webkitNotifications for their notifications. Not to say that we shouldn't land this patch anyway - just pointing out that this may still be used more often than your stats would indicate. As Morrita-san writes: On Wed, Jan 23, 2013 at 12:50 AM, Hajime Morrita morr...@google.com wrote: It looks the patch is removing a specific API called createHTMLNotification(). Unless these apps are showing HTML-based notification, it should keep working even after this change. If Gmail is still using the vendor-prefixed webkitNotifications version of the API, they should update to the unprefixed new Notification version of the API, which is implemented by a number of different browsers. I know there's some amount of confusion about the current status of the web notification APIs. I'm working with Chrome's developer relation folks to update our various pieces of documentation and tutorials. Adam On Wed, Jan 23, 2013 at 1:47 AM, Adam Barth aba...@webkit.org wrote: As discussed in February 2012 [1], we have been deprecating the webkitNotifications.createHTMLNotification API for almost a year. According to FeatureObserver, the API is used in only 0.0008% of web page views, indicating that we have been successful in depreciating it. I've posted a patch to remove it: https://bugs.webkit.org/show_bug.cgi?id=107598 Thanks, Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-February/019354.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Followup on removing webkitNotifications.createHTMLNotification
On Wed, Jan 23, 2013 at 11:28 AM, Jon Lee jon...@apple.com wrote: Happy to hear about this! As a follow-up question, what numbers are you seeing with the rest of the legacy API? (webkitNotifications.createNotification, webkitNotifications.checkPermission, and webkitNotifications.requestPermission) The only other API we're measuring is createNotification, which seems to be used about 4x as often as createHTMLNotification. That's certainly in the range where we should consider removing support for the prefixed version in favor of the unprefixed version. The reason I haven't done it yet is that there isn't very good developer documents explaining how to use the unprefixed API. As I mentioned earlier in this thread, I'm working with our developer relations folks to improve that situation. Once we have some good documentation out, we should consider removing the prefixed API as well. Adam On Jan 23, 2013, at 1:11 AM, Adam Barth aba...@webkit.org wrote: On Wed, Jan 23, 2013 at 1:08 AM, Andrew Wilson atwil...@google.com wrote: Apologies for the confusion - I should have finished my coffee before reading my mail. I didn't realize this only impacts HTML notifications. It's still a good reminder that Google really should migrate to the new notification APIs, though. I'll get the ball rolling on gmail, at least. Thanks! Let me know if you run into any trouble. Adam On Wed, Jan 23, 2013 at 9:58 AM, Adam Barth aba...@webkit.org wrote: On Wed, Jan 23, 2013 at 12:45 AM, Andrew Wilson atwil...@google.com wrote: Hmmm. Does FeatureObserver detect features invoked from web apps like Gmail? Yes. Because I'm fairly certain that Gmail and Google Calendar still use webkitNotifications for their notifications. Not to say that we shouldn't land this patch anyway - just pointing out that this may still be used more often than your stats would indicate. As Morrita-san writes: On Wed, Jan 23, 2013 at 12:50 AM, Hajime Morrita morr...@google.com wrote: It looks the patch is removing a specific API called createHTMLNotification(). Unless these apps are showing HTML-based notification, it should keep working even after this change. If Gmail is still using the vendor-prefixed webkitNotifications version of the API, they should update to the unprefixed new Notification version of the API, which is implemented by a number of different browsers. I know there's some amount of confusion about the current status of the web notification APIs. I'm working with Chrome's developer relation folks to update our various pieces of documentation and tutorials. Adam On Wed, Jan 23, 2013 at 1:47 AM, Adam Barth aba...@webkit.org wrote: As discussed in February 2012 [1], we have been deprecating the webkitNotifications.createHTMLNotification API for almost a year. According to FeatureObserver, the API is used in only 0.0008% of web page views, indicating that we have been successful in depreciating it. I've posted a patch to remove it: https://bugs.webkit.org/show_bug.cgi?id=107598 Thanks, Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-February/019354.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
