[webkit-dev] What's up with the CHECK_CONSISTENCY macro?
Hello Webkittens, I'm trying to add some line boxes sanity checks and I've noticed there's a CHECK_CONSISTENCY macro guarding some consistency validation code (go figure!) but that's never defined in WebKit/Source. Anybody has an idea how that macro is used? Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Make accelerated compositing mandatory
The patch that makes AC mandatory has landed here: http://trac.webkit.org/changeset/163079. As I said before, no build systems were affected by the patch so port maintainers can adjust to the change as they see fit. Thanks, Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Make accelerated compositing mandatory
Hello! I¹ve posted a patch at https://bugs.webkit.org/show_bug.cgi?id=127833. There¹s also a comment detailing the scope of the patch. If there are no objections, I¹ll land it tomorrow. Thanks, Andrei. Hello webkittens, Do you happen to know if we still have ports that build WebKit without accelerated compositing? If not, I'd like to write a patch that removes the flag and makes AC mandatory. From IRC, I've heard that the Haiku port (not upstreamed) disables the AC flag, but they agree they should switch it on in the future. Thoughts? Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Make accelerated compositing mandatory
Hello webkittens, Do you happen to know if we still have ports that build WebKit without accelerated compositing? If not, I'd like to write a patch that removes the flag and makes AC mandatory. From IRC, I've heard that the Haiku port (not upstreamed) disables the AC flag, but they agree they should switch it on in the future. Thoughts? Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] CSS Regions diagrams
Hello WebKittens, I've built two diagrams that should help contributors ramp up on the CSS Regions code. https://docs.google.com/file/d/0Bw3uLBB0FreFWC1HZVM2YnRkeFE/edit The first diagram is a class map covering the relevant parts of the regions code. Two important missing pieces are the layers code and the auto-height specific code. Hopefully I'll find some time to add those as well. The diagram is pretty large so I recommend downloading it for easier navigation. The second diagram shows the structure of the render tree for a document with two named flows having a regions dependency between them. The diagram also presents the layout order of the renderers to ensure the content in the named flows is laid out correctly. Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] CSS Regions diagrams
It is a regular PDF. For some reasons zooming is limited in the browser previewer. The Google Docs toolbar should have a download button in the left (a down arrow). If it doesn't work I'll find a different place to host it. Andrei. From: ryosuke.n...@gmail.com [mailto:ryosuke.n...@gmail.com] On Behalf Of Ryosuke Niwa Sent: Thursday, May 09, 2013 11:30 AM To: Andrei Bucur Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] CSS Regions diagrams I can't zoom enough to see anything on the first diagram. Could you post a regular PDF or PNG/SVG somewhere? - R. Niwa On Thu, May 9, 2013 at 1:24 AM, Andrei Bucur abu...@adobe.commailto:abu...@adobe.com wrote: Hello WebKittens, I've built two diagrams that should help contributors ramp up on the CSS Regions code. https://docs.google.com/file/d/0Bw3uLBB0FreFWC1HZVM2YnRkeFE/edit The first diagram is a class map covering the relevant parts of the regions code. Two important missing pieces are the layers code and the auto-height specific code. Hopefully I'll find some time to add those as well. The diagram is pretty large so I recommend downloading it for easier navigation. The second diagram shows the structure of the render tree for a document with two named flows having a regions dependency between them. The diagram also presents the layout order of the renderers to ensure the content in the named flows is laid out correctly. Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] CSS Fragmentation in WebKit
Here is an introductory blog post I wrote a while back about fragmentation in WebKit. I think it's in line with Dave's presentation on pagination: http://blogs.adobe.com/webplatform/2013/03/05/css-fragmentation-in-webkit/ Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Multiple inheritance in the DOM
Hi Adam, On 7/27/12 1:55 AM, Adam Barth aba...@webkit.org wrote: Perhaps it would make sense to start with a smaller CSSOM for Regions that uses established patterns and techniques. That way we can gain experience with these patterns and techniques before jumping into API designs that don't follow existing patterns and introduce complexity across the entire platform. In the light of the recent discussions I think the best action to take is not to add the Region interface in WebKit at this moment. Instead of that, we should move the members from the Region interface to the Element interface and implement them there. The NamedFlow.getRegions()/getRegionsByContent() methods would then return a sequence of Elements. When other types of DOM/CSSOM objects will be able to become regions (such as pseudo-elements) we will take another look at implementing the supplemental interfaces mechanism. The downside with taking this path is the region sequences returned by the NamedFlow API functions will not contain the pseudo-elements that are regions. However, I think this is an issue we can live with :). Thoughts? Thanks, Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Multiple inheritance in the DOM
Identifying what the Region actually is sounds very similar with identifying the nature of a Node using NodeType? Is this pattern applicable here as well? https://developer.mozilla.org/en/nodeType Andrei. From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Adam Barth Sent: Friday, July 27, 2012 1:15 AM To: Alan Stearns Cc: Kentaro Hara; Elliott Sprehn; webkit-dev@lists.webkit.org; Sam Weinig Subject: Re: [webkit-dev] Multiple inheritance in the DOM For Alex's suggestion above, would there be any problems with a parameter (for the first method) and return type (for the second) that could be an Element or something else? Adding two helper methods seems messier to me than what's currently specced, but I'm open to the idea if it's much easier to implement. It depends on how many things will implement Region. If there are N things, you'll need to add N properties and you're essentially asking web developers to call QueryInterface on the object to see what sort of Region it really is. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] About WebIDL supplemental interfaces
Hello Webkitters! The latest WD for WebIDL defines a supplemental interface of an interface A as any element of the acyclic graph of interfaces that is connected to A through implements statements or through the inheritance chain of another supplemental interface: http://www.w3.org/TR/WebIDL/#dfn-supplemental-interface However, WebKitIDL defines Supplemental more like a partial interface: http://trac.webkit.org/wiki/WebKitIDL#Supplemental I'm asking this because CSS Regions spec defines the Region interface as an WebIDL supplemental interface that needs to be implemented by any object that can be a region (Element, Pseudo elements etc.). Is there a way in WebKit to write an interface that implements another as specified by WebIDL? Thanks, Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] About WebIDL supplemental interfaces
Hey Kentaro, On 7/19/12 6:20 PM, Kentaro Hara hara...@chromium.org wrote: Hi Andrei I'm asking this because CSS Regions spec defines the Region interface as an WebIDL supplemental interface that needs to be implemented by any object that can be a region (Element, Pseudo elements etc.). Is there a way in WebKit to write an interface that implements another as specified by WebIDL? Currently, no. (Correct me if I'm wrong.) However, WebKitIDL defines Supplemental more like a partial interface: http://trac.webkit.org/wiki/WebKitIDL#Supplemental The current WebKitIDL implementation is on the way. Eventually we want to remove the [Supplemental] IDL attribute and support the A implements B syntax as defined in the WebIDL. Do you have any alternative solution to make CSS Regions work without the A implements B syntax? If no, maybe it's time to consider supporting the A implements B syntax (, which would require a substantial amount of work though:-). The only way I can see this implemented without the new syntax is by writing some crazy hacks, probably very similar with how EventTarget works. And even then I'm not sure everything will work out well. Right now, hacking things in does not seem to worth the effort, especially if it's going to be removed once the implements syntax gets in. I'm open to suggestions though :). However, it would be nice to have the new syntax on board sooner than later. Is there a roadmap for adding this in WebKit? I'm sure you are very busy so having a timeline would allow other hackers help move the implementation forward :). Thanks, Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] About WebIDL supplemental interfaces
Hello Adam, Sure: http://www.w3.org/TR/2012/WD-css3-regions-20120503/#the-region-interface The spec does not explicitly states that the Region should be supplemental, however after raising some issues on www-style ( http://lists.w3.org/Archives/Public/www-style/2012Jul/0251.html ) and talking them through (offline) it seemed the best way to solve them was making Region supplemental for Element and any other object that could become region. Right now, I'm feeling out the situation to see how feasible this is to be implemented in WebKit. Andrei. From: Adam Barth aba...@webkit.orgmailto:aba...@webkit.org Date: Thursday, July 19, 2012 7:31 PM To: Andrei Bucur abu...@adobe.commailto:abu...@adobe.com Cc: Kentaro Hara hara...@chromium.orgmailto:hara...@chromium.org, webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] About WebIDL supplemental interfaces Can you say what specifically in the CSS regions spec is giving you trouble? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Web APIs and class name collisions
CSSRegion is it then! I'll also make a patch to rename WebKitNamedFlow into CSSNamedFlow. Thx! Andrei. On 7/12/12 10:37 PM, Alexis Menard alexis.men...@openbossa.org wrote: So far in the css/ directory we tried to renamed slowly classes so that : CSS* prefixed classes are the implementation of CSSOM whatevername is for internal classes. For example we renamed CSSStyleApplyProperty class to StyleBuilder because it's internal. Hope that helps. On Thu, Jul 12, 2012 at 2:52 PM, Simon Fraser simon.fra...@apple.com wrote: I'd prefer we keep Region for the low-level graphics primitive Region (just like Path), and use something prefixed for the higher-level layout concept. Simon On Jul 12, 2012, at 10:26 AM, Dana Jansens wrote: On Thu, Jul 12, 2012 at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote: I'd vote for CSSRegion or CSSOMRegion for the class you're adding but I'll also suggest we rename the existing Region class now that the term region has a specific semantic in CSS. Maybe LayoutRegion or ScreenRegion? IntRegion? It seems closer to an IntRect than a LayoutRect. - Ryosuke On Jul 12, 2012 10:13 AM, Eric Seidel e...@webkit.org wrote: I would go with CSSRegion, and stick it in the css/ folder. Much of the CSS folder is our implementation of the CSS Object Model (CSSOM). At some point it might make sense to pull all the classes which implement the CSSOM out of css/ into a new cssom/ similar to dom/, but that's a later discussion. -eric On Thu, Jul 12, 2012 at 10:03 AM, Andrei Bucur abu...@adobe.com wrote: From my knowledge the CSS prefix is reserved for the CSS engine classes in WebKit. Prefixing the Region class with CSS could prove confusing. Regards, Andrei. From: Alan Stearns stea...@adobe.com Date: Thursday, July 12, 2012 7:39 PM To: Adam Barth aba...@webkit.org, Andrei Bucur abu...@adobe.com Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Web APIs and class name collisions The spec itself consistently and deliberately calls them CSS Regions, so a CSS prefix could be appropriate. Thanks, Alan From: Adam Barth aba...@webkit.org To: Andrei Bucur abu...@adobe.com Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Web APIs and class name collisions One common thing we do is prefix DOM to DOM-level concepts. For example, DOMWindow and DOMFileSystem. I'm not sure if we have an established convention for CSS-level concepts. Adam On Thu, Jul 12, 2012 at 9:18 AM, Andrei Bucur abu...@adobe.com wrote: Hello Webkittens! While implementing the Region interface ( http://dev.w3.org/csswg/css3-regions/#the-region-interface ) I've noticed that the name Region is already taken by a class in platform/graphics. I'd like to know what's the best approach in these kind of situations: Rename the existing WebCore class to something else and use the name Region for the Web API so there's parity between the implementation and the spec Somehow prefix the Web API implementation class name? As the Web APIs expand I suppose this situation may occur again in the future and I suppose there should be a rule describing what's the best approach to take. Thanks! Andrei. ___ 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 ___ 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 -- Alexis Menard (darktears) Software Engineer openBossa @ INdT - Instituto Nokia de Tecnologia ___ 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] Web APIs and class name collisions
Hello Webkittens! While implementing the Region interface ( http://dev.w3.org/csswg/css3-regions/#the-region-interface ) I've noticed that the name Region is already taken by a class in platform/graphics. I'd like to know what's the best approach in these kind of situations: 1. Rename the existing WebCore class to something else and use the name Region for the Web API so there's parity between the implementation and the spec 2. Somehow prefix the Web API implementation class name? As the Web APIs expand I suppose this situation may occur again in the future and I suppose there should be a rule describing what's the best approach to take. Thanks! Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Web APIs and class name collisions
From my knowledge the CSS prefix is reserved for the CSS engine classes in WebKit. Prefixing the Region class with CSS could prove confusing. Regards, Andrei. From: Alan Stearns stea...@adobe.commailto:stea...@adobe.com Date: Thursday, July 12, 2012 7:39 PM To: Adam Barth aba...@webkit.orgmailto:aba...@webkit.org, Andrei Bucur abu...@adobe.commailto:abu...@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] Web APIs and class name collisions The spec itself consistently and deliberately calls them CSS Regions, so a CSS prefix could be appropriate. Thanks, Alan From: Adam Barth aba...@webkit.orgmailto:aba...@webkit.org To: Andrei Bucur abu...@adobe.commailto:abu...@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] Web APIs and class name collisions One common thing we do is prefix DOM to DOM-level concepts. For example, DOMWindow and DOMFileSystem. I'm not sure if we have an established convention for CSS-level concepts. Adam On Thu, Jul 12, 2012 at 9:18 AM, Andrei Bucur abu...@adobe.commailto:abu...@adobe.com wrote: Hello Webkittens! While implementing the Region interface ( http://dev.w3.org/csswg/css3-regions/#the-region-interface ) I've noticed that the name Region is already taken by a class in platform/graphics. I'd like to know what's the best approach in these kind of situations: 1. Rename the existing WebCore class to something else and use the name Region for the Web API so there's parity between the implementation and the spec 2. Somehow prefix the Web API implementation class name? As the Web APIs expand I suppose this situation may occur again in the future and I suppose there should be a rule describing what's the best approach to take. Thanks! Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto: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] Using ref tests for repaint bugs
I want to give everyone an update on how things are evolving. For now, I've focused most of the development on the Mac platform. For the ref-tests-as-repaint-tests path, I've added an optional parameter to LTC.display() that should control if the repaint rectangles are tracked or not. If not specified or true, the repaint rectangles are tracked. After running very basic experiments, this seems to detect if repaint artifacts are present in a test. For the repaint-rects-as-repaint-tests path, I have some questions about what should be the best testing methodology. I'm thinking about something along these lines: * I don't think a new script option or DRT parameter are necessary; the repaint rectangles for a test can be extracted together with the pixel results * The format for the rectangles data should be simple, maybe X,Y,W,H separated by new-lines? Or the smallest rectangle that includes all of the repaint rectangles? Or another suggestion? * When initially running a repaint test, both a PNG and RR (repaint-rectangles) files are generated as baselines. At subsequent executions of the test, the RR expected output is preferred over the pixel results. This means that if the test author modifies the expected PNG, the test should still pass because the RR baseline exists. However, if a pixel test in preferred, deleting the expected RR output will force the test runner to fallback on the classic image diff code path. * A port may chose to repaint everything, even for partial canvas invalidation. Do you think it's correct to evaluate a test as passed if the expected repaint rectangles are included in the actual repaint rectangles? The simplest and straightforward way to compare the actual results with the expected ones is a simple bytes diff, but I'm not convinced it's correct. Any thoughts on this? The chromium DRT project has a different strategy for masking with the repaint rectangles; could someone help me understand better what happens in the WebViewHost::paintInvalidatedRegion() method and why exactly is iterating 3 times through that code necessary? (the comment looks a little obsoleted and I'd appreciate some clarifications). Overall, I see some difficulties in keeping the repaint rectangles based testing to be platform independent. Do you have any suggestions that may help with this? Once I'm finished patching the Python scripts to support the RR tests, I'll upload a patch so people can look over the approach. Thx, Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using ref tests for repaint bugs
On Fri, May 25, 2012 at 4:05 PM, Julien Chaffraix julien.chaffr...@gmail.com wrote: I second Simon's fragility argument. His solution is more viable, platform agnostic and may even remove the need for dumping the pixel in some cases. Even if the existing harness has the subsequent paint issue, having the pixels for the repaint test is one of the few cases where they are useful IMHO (sometimes the exact area to repaint is a judgement call, see e.g. the differences between the platforms). Also there are several of techniques to make the pixel dump platform-agnostic which could minimize the number of baselines. On top of that, if both your test case and reference hit the same bug, it nullifies the value of your test - this may be a theoretical issue though as pointed out in the pixel vs ref-test thread. I didn't understand from your proposal how you would avoid this risk. Thanks, Julien In some cases I don't see how the reference and test files can hit the same bug that you are testing for if the test file is correctly designed. Imagine a simple scenario with a background repaint bug. The test document has an element that's 50px tall with a background color of red. After making the element 25px tall, the surface is not correctly cleared and the red background remains 50px tall. If the reference document contains the element directly with 25px height, it's pretty impossible WebKit will ever draw it with a 50px tall background, thus the ref-test will detect if that specific repaint bug exists. I never said ref-tests can replace all the pixel tests, but for bugs like the one I've mentioned above they seem to do quite a good job. Simon's idea sounds very good as well, but it has the disadvantage of a maintenance cost greater than the one for a ref-test. I suppose the best thing is to have both of them implemented and based on the specificity of the bug tested, use one or another. For straightforward repaint bugs, ref tests sound good. For more complex bugs, comparing repaint rectangles seems better. I'll start prototyping both of them as it doesn't look extremely difficult to extract the repaint rectangle information. Afterwards I'll try to see how both approaches can be applied to the current repaint testing battery. Thanks, Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using ref tests for repaint bugs
No, I need a way to force a paint operation, similar to what layoutTestController.display() achieves, but without tracking the paint rectangles. Does anyone you find value in adding an optional parameter to display (or create another method on LTC) that disables paint rectangle tracking. The main advantage for such a change would be in extending the ref tests power to also cover repaint tests (at least a part of them), thus making pixel tests less necessary. Repaint bugs appear usually when the layout changes but the old pixels are incorrectly invalidated. By making the reference HTML directly identical to the test document after the bug triggering changes have been applied, it is pretty certain that the output pixels for the reference file will not contain the repaint artifacts (there's no repaint operation involved). When running such a test with a client that has the bug, it will fail because the test file output will have artifacts and the reference output will not. On the other hand, using a client with the repaint bug fixed, the pixels output for the test and reference files should be identical. Thoughts? Andrei. On Thu, May 24, 2012 at 11:57 PM, Ojan Vafai o...@chromium.org wrote: Do you just need to force a layout at the end of repaintTest, e.g. document.body.offsetHeight;? On Thu, May 24, 2012 at 6:34 AM, Andrei Bucur andrei.bu...@gmail.comwrote: Hello WebKittens, I'm trying to simplify the patch for a certain repaint bug ( https://bugs.webkit.org/show_bug.cgi?id=59863 ) by using ref tests instead of pixel tests. The test HTML file should first render the document in state 1 and then, by modifying the DOM, render it again state 2. The bug appears when repainting from state 1 to state 2. The expected result HTML for the test is just a document directly written in state 2 (so there is no transition, no bug). This should work on all the platforms but there's problem with the time control between paints for state 1 and state 2 in the test HTML. I've tried three options: 1. Use setTimeout() to update the DOM - I really wouldn't like to use this because it slows down the test and can be flaky. 2. Use layoutTestController.display() before modifying the DOM to trigger a paint - calling this seems to make the test fail because display() starts tracking the paint rects which doesn't happen in the reference document. 3. Make use of requestAnimationFrame to time the paintings for state 1 and state 2 - doesn't work directly out-of-the-box because requestAnimationFrame schedules a full repaint after going into state 2 and the bug doesn't reproduce anymore. Is there a preferred solution to this problem or another one that I'm missing? Thanks, Andrei. ___ 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] Using ref tests for repaint bugs
Ojan, As Simon states, some repaint tests will likely not be possible to write correctly as ref tests, but some of them I think they fit very well in the happy-no-pixel-test bucket :). If people decide it's a direction worth investigating, I'll give the idea a spin. Simon, On Fri, May 25, 2012 at 2:07 AM, Simon Fraser simon.fra...@apple.comwrote: I think this will be too fragile. It relies on the fact that a subsequent paint won't obscure the repaint bug that you're trying to detect. I'm much rather we work towards detecting repaint bugs via dumping the list of repaint rectangles. I don't think every test has to be a ref test. Don't the pixel tests face the same kind of risk, of a subsequent paint masking the repaint bug? Preserving this risk, but reducing the maintenance cost for the test is still an important improvement. Thanks, Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Regarding cache memory leaks
I don't know if this is the use case but it should be noted that the CachedResourceLoader (the old DocLoader) never drops the CachedResource handles it has. This prevents resource deletion while the CachedResourceLoader is alive and kicking. This means that modifying the source of an img element from JS does not cause the old image to be released even though it is removed from the cache eventually. Andrei. On Mon, Oct 18, 2010 at 10:18 PM, Holger Freyther ze...@selfish.org wrote: On 10/18/2010 02:55 PM, sumanrap...@aim.com wrote: Hi Holger, Hi, (please keep the mailinglist in the loop) We have applied the patch(https://bug-44806-attachments.webkit.org/attachment.cgi?id=68154) to remove the deadResources, which is working fine. Because of this patch the duration to consume the entire available RAM has increased. But still the liveResources are not freeing, due to which its again consuming the entire available RAM. my time is limited right now so I can not help you in my spare time. But if the encoded data of the current page is more than fits into your RAM there is not much you can do, you can either wait to get killed by the kernel, or you can stop loading the page. Just imagine you would throw away images you have already downloaded, you would need to download them again.. in most cases where you have limited RAM you also have limited bandwidth... The two things that I can propose are: a) verify thay you are not leaking memory. Create a simple page, reload it in a loop, repaint it and see what happens to your memory... b) ask the Linux VM to overcommit memory and see how far you can push things. I just can't commit more of my spare time to look into memory usage of WebCore, I wish I could spend more time on WebKit... ___ 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
[webkit-dev] Cairo and -webkit-mask-clip: text
Hello! I'm trying to implement this CSS value on the Cairo backend and I'm stuck with a problem regarding the Porter-Duff composition operators (why is CAIRO_OPERATOR_DEST_IN unbound?). I've made the following changes to reach this point: 1. I implemented a version of GraphicsContext::clipToImageBuffer starting from this patch: https://bugs.webkit.org/show_bug.cgi?id=23526 , but saving the image mask and the masking rect on a stack and pushing only a group for the masked content. 2. In GraphicsContext::restorePlatformState when the save count is 0 for the current mask, I recover the masked content as a pattern, I clip it using the mask from the stack (I used a new group and operator CAIRO_OPERATOR_IN) and then I should apply the result on the destination surface using CAIRO_OPERATOR_DEST_IN, but bounded to the current mask. The problem here is that CAIRO_OPERATOR_DEST_IN is unbounded so it doesn't take into account the mask, thus affecting all the surface. 3. I modify RenderBoxModelObject::paintFillLayerExtended so that when drawing the background image to use the bgLayer-composite() operator if the clip is TextFillBox. Using CompositeSourceIn can't work because clipToImageBuffer started a new group which uses a different surface for drawing (so there is no destination text to composite with). This way the composition will be done in restorePlatformState. I know this is ugly and that it's highly unlikely to work in this form with SVG masking. For now I just need a hook to make this work. Do you have any other suggestions to make this CSS value work with Cairo? Thanks, Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
