[webkit-dev] WebKit image rendering performance
Hello, First time poster. While I admit I haven't worked on WebKit code (yet), I'm very familiar with its workings across different implementations (desktop, mobile and otherwise). In my research regarding WebKit rendering performance, I've stumbled upon an interesting artefact while animating spritesheet-based image animations. I've written up a an article on the effects and metrics, including a minimal test case to help demonstrate the effects on various implementations: http://gist.io/3639830 I remember reading somewhere in the WebKit archives (messages dated at least one year ago) about keeping render objects removed from the tree by caching them according to their URI, but have since been unable to locate that specific message. From what I understand, the effects described in the document seem to match up exactly with what I'm assuming is happening inside the engine and according to Levi Weintraub's high-level description of the rendering engine. I would greatly appreciate any feedback on the document, to help optimise my approach when dealing with graphically intensive games and applications. I wouldn't mind getting my hands dirty with the source if someone can point me in the right direction. Thanks, -Klemen -- *http://about.me/klemen.slavic * *It's who I am.* *It's what I do.* ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding reverse flag to Widget::SetFocus?
Hi Youifumi,
I'm a little bit confused about what you did. It seems like youalways
select the first subelement in your elemnt.
void DateTimeEditElement::focusByOwner()
{
if (DateTimeFieldElement* field = fieldAt(0))
field-focus();
}
I don't understand how Shift+Tab works in your code?
Thanks,
Fady
On Mon, Sep 10, 2012 at 9:39 PM, Yoshifumi Inoue yo...@google.com wrote:
Hi Fady,
I have same experience about focus in internal element within container
element. I tried to do same thing for multiple fields time input UI for
input type=time. In the implementation, fields are implemented in shadow
DOM hosted by input element.
We call fields are DateTimeFieldElement and container for them as
DateTimeEditElement.
On first implementation, DateTimeEditElement controlled focus. When input
element focused, DateTimeEditElement sets the first field. It worked fine
except for Shift+Tab.
http://trac.webkit.org/changeset/125263
I studied FocusController and EventHandler::defaultTabEventHandler.
http://trac.webkit.org/browser/trunk/Source/WebCore/page/FocusController.cpp
http://trac.webkit.org/browser/trunk/Source/WebCore/page/EventHandler.cpp
I thought two options:
1. Factor out defaultTabEventHandler.
= FocusController::advanceFocus requires keyboard event object for
Option+Tab on Mac.
2. Create fake-keyboard event containing Shift+Tab then pass to
defaultEventHandler.
It seems making fake-keyboard event is little bit ugly.
So, our conclusion is making DateTimeEditElement not to manage focus ==
FocusController manages focus.
http://trac.webkit.org/changeset/127226
As of this experiment, setFocus() with direction parameter doesn't solve
controlling focus by container. Container wants to know direction of focus
navigation from event object.
The pseudo code can be written as:
TimeInputElement::defaultEventHandler(Event* event)
{
if (event-isFocusEvent()) {
if (event-focuseDirection() == FocusDiectionForward)
setFocusToField(0);
else
setFocusToField(m_lastFieldIndex);
// Not sure about FocusDirectionUp/Down
// Need RTL support for FocusDirectionLeft/Right. Move focus
Left/Right on physical location.
}
}
On Tue, Sep 11, 2012 at 4:32 AM, Fady Samuel fsam...@chromium.org wrote:
Hi all,
I'm working on a plugin that needs to deal with focus. I'd like this
plugin to look an feel just like any other DOM element including the way it
deals with focus. The problem that I have is Widgets know about focus but
not focus direction (forward/reverse). My plugin has several logical
subelements. The initial subelement to select is based on the direction
taken to arrive to the plugin by keyboard (Tab v.s. Shift-Tab).
I'd like to add a new parameter with a flag or enum three states perhaps:
Foward Reverse, Neither to Widget::SetFocus.
This is going to require many one-line changes throughout a number of
files throughout WebCore.
Before I embark on such a change, I'd like to get some feedback at this
point. Is this a reasonable thing to add? Does anyone oppose this change?
Is there a cleaner way to add this support?
Thanks,
Fady
___
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] Regd. Remote debugging support in GtkLauncher
Hey, I think this question is off-topic for webkit-dev, please use webkit-gtk or webkit-help in the future. On Qui, 2012-09-06 at 10:49 +, debojyoti@wipro.com wrote: Also I couldn't find any option in GtkLauncher where I can provide the websocket server port, like chrome.exe --remote-debugging-port=9222. WebKitGTK+ currently lacks support for this. There's a WIP patch here to add support for WebKit2GTK+: https://bugs.webkit.org/show_bug.cgi?id=88094 Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit image rendering performance
On Tue, Sep 11, 2012 at 1:45 AM, Klemen Slavič krof.drak...@gmail.comwrote: First time poster. While I admit I haven't worked on WebKit code (yet), I'm very familiar with its workings across different implementations (desktop, mobile and otherwise). In my research regarding WebKit rendering performance, I've stumbled upon an interesting artefact while animating spritesheet-based image animations. I've written up a an article on the effects and metrics, including a minimal test case to help demonstrate the effects on various implementations: http://gist.io/3639830 The way decoded images is handled depends on great many things. I suggest you to ask questions on webkit-help. The mailing list webkit-dev is about the development of WebKit A quick run in Instruments shows that, on my machine, blitting the images is the problem in this case. The hotspot has nothing to do with decoding the images. I would appreciate if you could update or remove the article to make sure we do not spread erroneous informations about WebKit through the mailing list. I remember reading somewhere in the WebKit archives (messages dated at least one year ago) about keeping render objects removed from the tree by caching them according to their URI, but have since been unable to locate that specific message. From what I understand, the effects described in the document seem to match up exactly with what I'm assuming is happening inside the engine and according to Levi Weintraub's high-level description of the rendering engine. I would greatly appreciate any feedback on the document, to help optimise my approach when dealing with graphically intensive games and applications. I wouldn't mind getting my hands dirty with the source if someone can point me in the right direction. I suggest you to use a profiler like Instruments' time profile. It will give you an idea of where the time is spent without making assumptions based on behaviors. Regards, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit image rendering performance
I suggest you to ask questions on webkit-help. The mailing list webkit-dev is about the development of WebKit Sorry about that, I didn't know which list to address this to, and -dev seemed the appropriate place to pose such a question. A quick run in Instruments shows that, on my machine, blitting the images is the problem in this case. The hotspot has nothing to do with decoding the images. What exactly do you mean by blitting? The way I understand it, doesn't blitting mean every write to the screen buffer? I've only seen long-running paint operations when new images came into view (identified using console.timeStamp(frameNumber)), not on every frame. Even so, JPEGs rendered consistently faster than PNGs when coming into view. I'm just trying to understand what is done internally to avoid this behaviour. I would appreciate if you could update or remove the article to make sure we do not spread erroneous informations about WebKit through the mailing list. Updating the article is exactly what I intended to do, to clear up any errors due to my misinterpretation of the internal behaviour of WebKit. Since I have only a high-level overview of the workings of the rendering engine, I'd like to know more about what exactly the effects are so that I may clear things up. I suggest you to use a profiler like Instruments' time profile. It will give you an idea of where the time is spent without making assumptions based on behaviors. Sorry to sound completely uninformed, but what is Instruments? Bear in mind, I don't have a Mac, I'm a Windows/Linux user. If you can point me in the right direction, I can find my way around the documentation. I'll refrain from posting any more messages regarding this on webkit-div and instead divert any additional questions to -help. Thanks for the pointers so far! -- *http://about.me/klemen.slavic * *It's who I am.* *It's what I do.* ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New Feature: CSS Element
Hi Benjamin, Although I will not be here, the team is planning on continuing the work on the project. A good person to contact is: Larry Mclister lmcli...@adobe.com -- Anish Bhayani WebKit Engineering Intern Web Platform Authoring From: Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.org Date: Monday, September 10, 2012 7:21 PM To: Adobe bhay...@adobe.commailto:bhay...@adobe.com Cc: webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] New Feature: CSS Element On Mon, Sep 10, 2012 at 6:41 PM, Anish Bhayani bhay...@adobe.commailto:bhay...@adobe.com wrote: I am an intern on the Adobe Web Platform Authoring team. For the summer, I was working on implementing CSS Element [1] in WebKit. The specification itself is still being finalized, but Mozilla [2] has had this feature working since FireFox 4.0. CSS Element allows an element to use another element as its background and Mozilla has a handy page on it [3]. Unfortunately, my internship is coming to an end, but I am working hard to get the grammar and parsing for it to land. Will anyone finish the work after you finish the internship? Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] How to diagnose a failing early-warning failure that passes on my machine?
On Bug 96040 (https://bugs.webkit.org/show_bug.cgi?id=96040) I posted a patch. The little oval thingys are all green except cr-linux. Clicking the failing oval gives a long file including these lines: Regressions: Unexpected text failures : (1) inspector/extensions/extensions-panel.html = TEXT This is a file I changed so I would like to know what failed in that test. It passes on my linux box. Any hints? jjb ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] How to diagnose a failing early-warning failure that passes on my machine?
Currently, there's no way to get results from the bots. You might need to land your patch and see what the bots on build.webkit.org tell you. Adam On Tue, Sep 11, 2012 at 2:45 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Bug 96040 (https://bugs.webkit.org/show_bug.cgi?id=96040) I posted a patch. The little oval thingys are all green except cr-linux. Clicking the failing oval gives a long file including these lines: Regressions: Unexpected text failures : (1) inspector/extensions/extensions-panel.html = TEXT This is a file I changed so I would like to know what failed in that test. It passes on my linux box. Any hints? jjb ___ 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] How to diagnose a failing early-warning failure that passes on my machine?
The cr-linux bots used to upload the results to the bug itself. Maybe that changed? On Tue, Sep 11, 2012 at 3:20 PM, Adam Barth aba...@webkit.org wrote: Currently, there's no way to get results from the bots. You might need to land your patch and see what the bots on build.webkit.org tell you. Adam On Tue, Sep 11, 2012 at 2:45 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Bug 96040 (https://bugs.webkit.org/show_bug.cgi?id=96040) I posted a patch. The little oval thingys are all green except cr-linux. Clicking the failing oval gives a long file including these lines: Regressions: Unexpected text failures : (1) inspector/extensions/extensions-panel.html = TEXT This is a file I changed so I would like to know what failed in that test. It passes on my linux box. Any hints? jjb ___ 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] How to diagnose a failing early-warning failure that passes on my machine?
I think we disabled that because we didn't want to spam the bugs.webkit.org database with tons of zip files. Adam On Tue, Sep 11, 2012 at 3:25 PM, Eric Seidel e...@webkit.org wrote: The cr-linux bots used to upload the results to the bug itself. Maybe that changed? On Tue, Sep 11, 2012 at 3:20 PM, Adam Barth aba...@webkit.org wrote: Currently, there's no way to get results from the bots. You might need to land your patch and see what the bots on build.webkit.org tell you. Adam On Tue, Sep 11, 2012 at 2:45 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Bug 96040 (https://bugs.webkit.org/show_bug.cgi?id=96040) I posted a patch. The little oval thingys are all green except cr-linux. Clicking the failing oval gives a long file including these lines: Regressions: Unexpected text failures : (1) inspector/extensions/extensions-panel.html = TEXT This is a file I changed so I would like to know what failed in that test. It passes on my linux box. Any hints? jjb ___ 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] Adding reverse flag to Widget::SetFocus?
Hi Fady,
DateTimeEditElement::focusByOwner() is called on HTMLInputElement::focus()
function == JavaScript focus() method.
Other than other input types, input type time isn't focusable, but
DateTimeFieldElement, field, is focusable. So, Focus controller moves focus
around fields.
In other words, DateTime{Edit,Field}Element don't manage focus.
Thanks.
-yosi
On Wed, Sep 12, 2012 at 12:41 AM, Fady Samuel fsam...@chromium.org wrote:
Hi Youifumi,
I'm a little bit confused about what you did. It seems like youalways
select the first subelement in your elemnt.
void DateTimeEditElement::focusByOwner()
{
if (DateTimeFieldElement* field = fieldAt(0))
field-focus();
}
I don't understand how Shift+Tab works in your code?
Thanks,
Fady
On Mon, Sep 10, 2012 at 9:39 PM, Yoshifumi Inoue yo...@google.com wrote:
Hi Fady,
I have same experience about focus in internal element within container
element. I tried to do same thing for multiple fields time input UI for
input type=time. In the implementation, fields are implemented in shadow
DOM hosted by input element.
We call fields are DateTimeFieldElement and container for them as
DateTimeEditElement.
On first implementation, DateTimeEditElement controlled focus. When input
element focused, DateTimeEditElement sets the first field. It worked fine
except for Shift+Tab.
http://trac.webkit.org/changeset/125263
I studied FocusController and EventHandler::defaultTabEventHandler.
http://trac.webkit.org/browser/trunk/Source/WebCore/page/FocusController.cpp
http://trac.webkit.org/browser/trunk/Source/WebCore/page/EventHandler.cpp
I thought two options:
1. Factor out defaultTabEventHandler.
= FocusController::advanceFocus requires keyboard event object for
Option+Tab on Mac.
2. Create fake-keyboard event containing Shift+Tab then pass to
defaultEventHandler.
It seems making fake-keyboard event is little bit ugly.
So, our conclusion is making DateTimeEditElement not to manage focus ==
FocusController manages focus.
http://trac.webkit.org/changeset/127226
As of this experiment, setFocus() with direction parameter doesn't solve
controlling focus by container. Container wants to know direction of focus
navigation from event object.
The pseudo code can be written as:
TimeInputElement::defaultEventHandler(Event* event)
{
if (event-isFocusEvent()) {
if (event-focuseDirection() == FocusDiectionForward)
setFocusToField(0);
else
setFocusToField(m_lastFieldIndex);
// Not sure about FocusDirectionUp/Down
// Need RTL support for FocusDirectionLeft/Right. Move focus
Left/Right on physical location.
}
}
On Tue, Sep 11, 2012 at 4:32 AM, Fady Samuel fsam...@chromium.orgwrote:
Hi all,
I'm working on a plugin that needs to deal with focus. I'd like this
plugin to look an feel just like any other DOM element including the way it
deals with focus. The problem that I have is Widgets know about focus but
not focus direction (forward/reverse). My plugin has several logical
subelements. The initial subelement to select is based on the direction
taken to arrive to the plugin by keyboard (Tab v.s. Shift-Tab).
I'd like to add a new parameter with a flag or enum three states
perhaps: Foward Reverse, Neither to Widget::SetFocus.
This is going to require many one-line changes throughout a number of
files throughout WebCore.
Before I embark on such a change, I'd like to get some feedback at this
point. Is this a reasonable thing to add? Does anyone oppose this change?
Is there a cleaner way to add this support?
Thanks,
Fady
___
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
