Re: [webkit-dev] WebKit Text Rendering
Line breaking is done in findNextLineBreak in RenderBlockLineLayout. There is a talk on Youtube from me which touches on some of this. The RenderTexts get broken into lines, then the bidi algorithm is run and then line boxes are created. The text contents of the line boxes are passed individually to the paint functions at paint time. -eric On Tue, Apr 19, 2011 at 7:48 AM, Soheil Servati Beiragh sserv...@yahoo.comwrote: Hi I'm working on text rendering of WebKit. I tried to find my path through it and I was a bit successful but I'm wondering in a gtk build when there is a large paragraph of text to be shown on screen where does the length of each line decided? I know that to show text a drawText function in the Font.cpp is called but the issue is it gets a string for each line, my question is for a large paragraph where does the code cuts the text in lines and decides the length and prepare it for drawText function? Thanks *Soheil Servati Beiragh* *PhD Candidate, ECE Department, * *Research Center for Integrated Microsystems,* *University of Windsor.* Room 268 Essex Hall 401 Sunset Avenue Windsor, Ontario Canada, N9B 3P4 Phone: 519-253-3000 Ext 3396 Email: serv...@uwindsor.ca ___ 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] font-face-uri question/issue
My phone failed to reply-all. Silly phone. https://bugs.webkit.org/show_bug.cgi?id=15443 is the bug, btw. On Tue, Apr 19, 2011 at 8:33 AM, Eric Seidel esei...@google.com wrote: SVGImage (svg content in an image tag) does not load any subresources (yet). There is a bug on file. On Apr 19, 2011 8:10 AM, Michael Oapos;Rourke mkoro...@adobe.com wrote: ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] new-run-webkit-tests new results.html format
As of r84294, new-run-webkit-tests's results.html has a new format. Non-chromium people, feel free to take a look and see if this addresses your concerns in https://bugs.webkit.org/show_bug.cgi?id=37736. Chromium people, if you encounter problems or have feature requests, please let me know or file bugs. Some of the new features: -View actual/expected results inline. -View actual/expected/diff images at 3x zoom to better see what changed. -Control showing expected failures with a checkbox instead of a commandline flag to new-run-webkit-tests. -Link to the httpd error logs. -Show failure type and expected failure type. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] choosing a unit test framework
In the interest of moving this along, I'll move to using the criteria listed in the previous email to evaluate the test frameworks. *Musts:* - Compatible license with WebKit - Builds/Can be built on the many platforms and build systems supported by WebKit (ideally without extra installs). TestWebKitAPI and gtest meet these criteria. I don't think that QTest does. *Useful:* - Easy to write tests - Maintained TestWebKitAPI, gtest have these. - Hackable to suit our needs TestWebKitAPI meets this better as it is solely in WebKit. gtest is an open source project with outside contributions accepted. Also, gtest is flexible to allow for many uses and widely used in many scenarios so it is less likely to need modifications. - Supports filtering of tests so you can run just the test you care about (and easily listing the tests). TestWebKitAPI and gtest supports listing the tests and running a single test. Also, gtest supports running all tests, or matching a simple pattern (Xml*). - Well tested features (to support hackability/stability) - Supports writing out values when there is test failure. (For example, if the is verifying that A == B but that is not true, then the values of A and B should be printed.) - Well documented gtest has these features. To me, both gtest and TestWebKitAPI seem close. I feel like there is a slight edge for gtest in these criteria (plus it has other features that aren't used as often but are nice when you have the scenario). I'm sure that TestWebKitAPI could meet these criteria as well. One nice thing about having these features already done, tested and documented is that it will allow us to focus on other places where we can add value (as opposed to working on another unit test framework). dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] new-run-webkit-tests new results.html format
Would be nice to have a live demo to see all the new javascripty-ness. Do you have an example from a NRWT run on build.webkit.org or build.chromium.org? Thanks for all your work on this, Ojan. -eric On Tue, Apr 19, 2011 at 2:29 PM, Ojan Vafai o...@chromium.org wrote: As of r84294, new-run-webkit-tests's results.html has a new format. Non-chromium people, feel free to take a look and see if this addresses your concerns in https://bugs.webkit.org/show_bug.cgi?id=37736. Chromium people, if you encounter problems or have feature requests, please let me know or file bugs. Some of the new features: -View actual/expected results inline. -View actual/expected/diff images at 3x zoom to better see what changed. -Control showing expected failures with a checkbox instead of a commandline flag to new-run-webkit-tests. -Link to the httpd error logs. -Show failure type and expected failure type. Ojan ___ 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] choosing a unit test framework
On Tue, Apr 19, 2011 at 2:36 PM, David Levin le...@chromium.org wrote: In the interest of moving this along, I'll move to using the criteria listed in the previous email to evaluate the test frameworks. *Useful:* - Easy to write tests - Maintained Can we see examples of tests that use TestWebKitAPI / gtest? I think it'll be helpful for people who don't know how the said two testing frameworks work. Ideally, we compare the same test written in TestWebKitAPI and gtest to decide which framework is better. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] choosing a unit test framework
On Tue, Apr 19, 2011 at 2:42 PM, Ryosuke Niwa rn...@webkit.org wrote:
Can we see examples of tests that use TestWebKitAPI / gtest? I think it'll
be helpful for people who don't know how the said two testing frameworks
work.
Ideally, we compare the same test written in TestWebKitAPI and gtest to
decide which framework is better.
Here's a test using TestWebKitAPI
#include Test.h
#include JavaScriptCore/Vector.h
TEST(WTF, VectorBasic)
{
Vectorint intVector;
TEST_ASSERT(intVector.isEmpty());
TEST_ASSERT(intVector.size() == 0);
TEST_ASSERT(intVector.capacity() == 0);
}
Here's the same test written using gtest:
#include gtest.h
#include JavaScriptCore/Vector.h
TEST(WTF, VectorBasic)
{
Vectorint intVector;
ASSERT_TRUE(intVector.isEmpty());
ASSERT_EQ(0, intVector.size());
ASSERT_EQ(0, intVector.capacity());
}
With respect to writing a simple test, they both make it easy to write one,
so I don't think this is the deciding factor.
Dave
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal to Reorganize Position Classes
To update you all, my colleagues and I have made a design documenthttps://docs.google.com/document/d/1vzzi_wQHO0GtLnu-1IYutUKbcpAYlHqZwQlwbfLuowM/edit?hl=enauthkey=CLOa9cgN. You should all be able to view the document. I've given editing rights to people who have replied to this thread but please let me know if you're interested in commenting on the document. Best, Ryosuke Niwa Software Engineer Google Inc. On Tue, Feb 1, 2011 at 6:51 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, * * *While I'm not intending to write a patch for the following proposal anytime soon, I'd really like to get your feedback.* * * As you might all know, Position classes in WebCore need refactoring and cleanup. Part of it is due to legacy editing positions that do many magics, and we're currently in the process of removing them (see the bug 52099 http://webkit.org/b/52099). However, even if we didn't have legacy editing positions, we still have rather clattered code base - there are many global functions in visible_units.cpp and VisiblePosition is used all over in WebCore/rendering - and reorganization of Position-related classes is needed (see the bug 52098 http://webkit.org/b/52098). I spent the last couple months to figure out what's the right solution and realized that there are generally two use cases of VisiblePosition: - To differentiate upstream/downstream to express caret positions - To iterate through editable regions to implement editing commands For the former use case, triggering layout or respecting editing boundary is not needed at all, and the use of VisiblePosition seems an overkill. I concluded that these two use cases should be addressed by two different classes. So I propose to implement the following 3 classes in lieu of the existing Position and VisiblePosition: - *DOMPosition* or *SimplePosition* - This class solely works on DOM, and is agnostic of renderers and other parts of WebCore. It's meant to be used in utility functions and classes or passed along between renderers and WebCore/dom. It doesn't know anything about upstream or downstream. - *RenderedPosition* - This positions is an enhanced version of the current Position. It represents every possible visible position and or DOM position and communicates vocabularies between WebCore/rendering and WebCore/editing. It knows about line boundary and upstream/downstream but it doesn't trigger a layout, doesn't canonicalize, and doesn't know anything about editing boundary. Its life-time is tied to layout cycle, and needs to be re-created every time DOM mutation or style change occurs. Many functions in visible_units.cpp can belong to this class as member functions. Furthermore, PositionIterator could be merged into this class because RenderedPosition can cache pointers and other invariants as needed since RenderedPosition's lifetime is tied to layout cycle. It can also share some code with TextIterator as well. - *EditingPosition* or *VisiblePosition* - This class is almost identical to the existing VisiblePosition. It knows everything DOMPosition and RenderedPosition knows, and respects editing boundary. A significant difference with VisiblePosition is that this class remembers the editable root element to which it belongs. So when crossing editing boundary, it can figure out whether or not we're still inside the same root editable root or not. It also knows how to canonicalize itself so editing commands can canonicalize positions as needed although canonicalization could be optional. I'm also not sure if this class should trigger a layout inside its constructor like VisiblePosition does or not yet. The introduction of RenderedPosition is particularly useful in rendering engine because it allows to express any caret/insertion point position with a guarantee that it doesn't trigger a layout. Now, I request for your comments! Best regards, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is ActiveDOMObject::scriptExecutionContext virtual or not?
Hi, guys. I understand. WebSocket also inherits EventTarget, and scriptExecutionContext is defined as virtual in EventTarget. Sorry for bothering you. Thanks, On Tue, Apr 19, 2011 at 11:30 AM, Takashi Toyoshima toyos...@chromium.org wrote: Hi, webkit guys. I have a question on ActiveDOMObject::scriptExecutionContext(). Now is was defined as non-virtual function. But currently, half of its inheritors defined this function as virtual. In my understanding, this virtual could not work because it's defined as non-virtual in its super class. Of course if they had its inheritors itself, it could work under their class context, but it doesn't as ActiveDOMObject. For example, WebSocket inherits ActiveDOMObject and define scriptExecutionContext as virtual function. But its implementation is just calling ActiveDOMObject::scriptExecutionContext and returning its result. It has no inheritor. Could I think it's a dead code or never used one? Does anyone know some historical or technical reason for that? Thanks, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
