[webkit-dev] question wrt knowing if some text or graphics will be drawn on next webkit render Thursday, June 9, 2011 10:11 AM From:
Hi there, I'm making enhancements to EWebLauncher the ewk backend on a low end mips box. A colleague of mine is disappointed that the screen goes blank for several seconds before displaying more complex pages like bbc news.# What we would like to be able to do is leave the old page on the screen until there is some text or graphics on the new page to be displayed. We are not using WebKit2. WebCore::FrameView::layout getting called only invalidates stuff on the screen doesn't gaurantee that WebCore::FrameView::paintContents has anything to draw other than blank the screen in the next redraw session D.J. Barrow Linux kernel developer email: dj_bar...@ariasoft.ie Mobile Ireland: +353-86-1715438 www.travelsmart.ie, everyones favourite carpool website, works beautifully on the apple iphone www.warehog.com, you thought ebay was good www.ariasoft.ie, See my GPL contributions ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote: On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak m...@apple.com wrote: 1) We definitely have consensus to fix the broken non-logically-const accessors by making them non-const; consensus on also adding const accessors is less clear. There are a surprising number of places that actually do const traversals. Simply making all these accessors non-const will require removing a lot of valid const usage from the existing code. I'm really uncomfortable with that. 2) We like to do things incrementally and fixing bad use of const before adding good use of const seems like this is a logical way to split the work and make it less of a megapatch. Incremental fixes are absolutely the way to go. Reviewing megapatches sucks and it's hard to catch subtle bugs like you changed this function to be not const, but there's no reason to do that. Perhaps a split that avoids removing existing, valid const usage would be to first change few (or no) function signatures, and simply modify caller code to be more consistent about type declarations. This would mean converting some callers from Node* to const Node* when they're doing true const traversals, and some the opposite direction when they're not. The goal would be to make eventual API changes a no-op in terms of caller effect. It'd be easy to make these sorts of patches arbitrarily small as well. How about posting a reasonable-sized patch that handles a few related, representative methods so we can evaluate. (As a separate technical comment, I think it may be better to have the const versions call non-const versions (casting away const on this), because the non-const versions are likely to be called much more often so it's helpful to have fewer levels of indirection to wade through before seeing the real code, e.g. when inspecting code or debugging.) I totally agree that these sorts of indirections are suboptimal (especially for common cases). The particular idea you propose isn't safe because there's no protection against the non-const impl actually causing side effects. Even if current implementations don't, it's easy to add a subtle bug like this in the future. And while compilers won't enforce this perfectly, they'll do a better and better job (better than nothing, for sure) as we change more APIs to enforce logical constness. (I hate to keep referencing it, but the end of Effective C++ Item 3 directly addresses this implementation idea in more detail. That whole section is really worth reading for anyone deeply interested in this issue.) If the best way to add const to the DOM is to add a level of indirection to all the non-const methods, then I'd probably think that is a reason to drop const entirely. But I'm not really convinced that casting away const from a return value is intrinsically safer than casting away const from this. However, I think we should at least try to limit the number of accessor pairs to only those cases which really need them. What about this plan: * I'll post a patch that just addresses the caller-side constness issues I've found from my work so far. * Then in my local checkout I'll start trying to see which accessor pairs I can collapse back to one accessor, be it const or non-const. I'll post patches to make any necessary caller-side changes here, too. * Finally I'll post a patch to change method signatures and add accessor pairs where necessary. * Then rinse and repeat with another class, e.g. Element. I'll go ahead and file a bug and start posting real diffs to look at unless this plan has fatal flaws. Hard to say without seeing the patches but I'd be glad to look at anything you post. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] question wrt knowing if some text or graphics will be drawn on next webkit render Thursday, June 9, 2011 10:11 AM From:
On Jun 9, 2011, at 2:29 AM, D.J. Barrow wrote: Hi there, I'm making enhancements to EWebLauncher the ewk backend on a low end mips box. A colleague of mine is disappointed that the screen goes blank for several seconds before displaying more complex pages like bbc news.# What we would like to be able to do is leave the old page on the screen until there is some text or graphics on the new page to be displayed. We are not using WebKit2. WebCore::FrameView::layout getting called only invalidates stuff on the screen doesn't gaurantee that WebCore::FrameView::paintContents has anything to draw other than blank the screen in the next redraw session WebKit1 on Mac has some logic for this. WebFrameLoaderClient::provisionalLoadStarted() turns off drawing, and it gets turned back on via WebFrameLoaderClient::dispatchDidFirstLayout() and WebFrameLoaderClient::frameLoadCompleted(). This leaves stale pixels on the screen while the new page is early in the loading process, preventing a flash between pages. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
On Thu, Jun 9, 2011 at 2:49 AM, Maciej Stachowiak m...@apple.com wrote: I'm not really convinced that casting away const from a return value is intrinsically safer than casting away const from this. Allowing the caller to mutate the return value is fine because the caller had a non-const |this| to begin with. We're not making anything less const-safe. Casting away const on |this|, OTOH, allows you to mutate objects even when you never had permission to begin with. Much different. In any case, my intent is to proceed as Darin and I discussed. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cherry-Pick Bug Comments
On Mon, Jun 6, 2011 at 11:13 AM, Ademar Reis ademar.r...@openbossa.org wrote: On Sun, Jun 5, 2011 at 2:03 AM, Eric Carlson eric.carl...@apple.com wrote: On Jun 3, 2011, at 2:30 PM, Adam Barth wrote: Either (1) or (2) is fine. Please pick one and do it. The status quo is very annoying. Yes, please! I'll post these comments only on [Qt] bugs until we implement a solution. One exception: I'll also add the comment to security bugs for now, just to make our lives easier. Since the inflow of security-fixes is very low, the noise should be minimal. Thanks, - Ademar -- Ademar de Souza Reis Jr. ademar.r...@openbossa.org Nokia Institute of Technology ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Building WebKit with Intel Compiler icc
Hello, I don't know if this is the right forum to ask this question. If it isn't I'd appreciate any pointers to where I should be asking this: I would like to build WebKit with Intel Compiler (ICC) and was wondering if this has been already done or if anyone has pointers on what would be the easiest way to do it. Thanks in advance for any help you can provide me with, CB ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS bindings: Adding EventTarget to the prototype chain
I don't think we should do this. EventTarget is really just an abstract
interface, and changing its implementation globally is of limited utility.
-Sam
On Jun 8, 2011, at 5:54 PM, Dominic Cooney wrote:
[If you don't care about JSC or V8 bindings you can safely ignore
this.]
TL;DR I want to change the JavaScript bindings to put EventTarget on
the prototype chain so it is easier to work with event targets from
JavaScript. What do you think?
Here is the prototype chain for a button today:
HTMLButtonElement-HTMLElement-Element-Node-Object
(add/removeEventListener and dispatchEvent are on Node.)
Here is how I think we should make it look:
HTMLButtonElement-HTMLElement-Element-Node-EventTarget-Object
(addEventListener etc. are on EventTarget.)
Here’s why I think we should do this:
- Specs are moving towards specifying EventTarget as living on the
prototype chain. DOM Core*, Notifications, Indexed DB, SVG and XHR
already do it this way. (* Editor’s draft.)
- Frameworks that want to hook add/removeEventListener will be able to
do it in one place: on EventTarget.prototype. In WebKit today they
have to hook the prototypes of window, Node, XMLHttpRequest, etc.
individually (Because WebKit implements EventTarget as a mixin
everywhere, there are 20+ different kinds of event targets to hook if
you want to be comprehensive.) If we make this change, it gets easier
to tell if a given object is an EventTarget; just do
EventTarget.prototype.isPrototypeOf(something).
- It will modestly simplify WebKit’s IDLs and bindings. Instead of
declaring addEventListener in two dozen places in IDLs, it will be in
one place; instead of calling visitJSEventListeners in dozens of
places for JSC GC, it will be called in one place; instead of assuming
that EventTarget parameters are all Node* under the covers for V8 code
generation, we can treat EventTargets uniformly; instead of
redundantly specifying EventTarget on Document and Node inheritance
will do what you want; etc.
Will doing this break the web? I don’t think so:
Anyone who calls or hooks addEventListener, etc. will continue to
work, just their foo.addEventListener might be resolved at one level
higher up the prototype chain than it is today. To really observe the
different placement of addEventListener, etc. minutely you need to
access __proto__ and hasOwnProperty. Other browsers are already differ
from WebKit in this regard, too: For example, Firefox reports
addEventListener is an own property on *every* step in the prototype
chain of DOM objects (until Object.)
Scripts that squirrel up the prototype chain themselves will see one
more link (EventTarget’s) but it is towards the top of the chain, past
most prototypes they care about (every prototype except Object.)
I tried changing half of the EventTargets in WebKit to put EventTarget
in the prototype chain, including Node and XHR (but not window) and
used it to surf the web for a few days. I didn’t notice anything break
:)
There is also the possibility that this could hurt performance,
because accessing addEventListener, etc. will have to search more
prototypes (usually just one more.) Accessing the properties of Object
on an event target via the prototype chain will have to squirrel
through one more prototype (EventTarget’s.) So I prototyped this
change in the JSC bindings and put EventTarget in the prototype chain
of a number of event targets in WebKit, including Node. Here are the
results for Dromaeo’s dom and jslib tests:
http://dromaeo.com/?id=141811,141813
(141811 on the left is the status quo.)
I expect the Prototype and jQuery events benchmarks are of particular
interest, and the result looks particularly bad for Prototype (~3%
slowdown). So I reran http://dromaeo.com/?event half a dozen times,
and couldn’t produce the poor result for Prototype; on average the
prototype was 1.0% slower for Prototype and 0.5% slower for jQuery. I
think Dromaeo is too noisy for measuring something as fine as this.
So I wrote three microbenchmarks:
1. Add/remove click listener on a button.
2. Add/remove progress listener on an XHR.
3. Test property presence with 'in':
if ('dispatchEvent' in target)
n++;
// return n outside of loop
where target is an XMLHttpRequest and n is a local var n = 0.
Here are the results. A brief note on methodology: release build
running in Mac Safari, JSC, averaging 500 samples with 1,000,000
iterations of the inner loop per sample.
1. Add/remove on button
Before (ms): min=409, median=434, mean=434.4, max=472
After (ms): min=410, median=453.5, mean=452.4, max=497 (mean is 1.04x)
2. Add/remove on XHR
Before (ms): min=286, median=298, mean=298.6, max=315
After (ms): min=287, median=300.5, mean=300.7, max=320 (mean is 1.01x)
3. 'dispatchEvent' in XHR
Before (ms): min=85, median=88, mean=87.7, max=91
After (ms): min=89, median=91, mean=91.0, max=95 (mean is 1.04x)
So this shows
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
Why should we implement this spec? We already have one flex box implementation that we can never remove (and corresponds closely to Firefox's) so it seems to me that we should work on standardizing that model. Adding a large bunch of code that duplicates existing functionality seems foolish. If the issue is the syntax for describing flexing, perhaps the spec should be written in a backwards compatible way, that supports both the new syntax and the old syntax, but the underlying implementation can remain. -Sam On Jun 8, 2011, at 10:57 AM, Tony Chang wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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] Adding ENABLE_FLEXBOX to WebCore
On Thu, Jun 9, 2011 at 1:19 PM, Sam Weinig wei...@apple.com wrote: Why should we implement this spec? We already have one flex box implementation that we can never remove (and corresponds closely to Firefox's) so it seems to me that we should work on standardizing that model. Adding a large bunch of code that duplicates existing functionality seems foolish. There was an attempt to standardize the old flexbox ( http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/), but that effort seems to have fizzled. I attempted to write some patches to make WebKit's old flexbox implementation match that spec, but Hyatt recommended against that because it can only break sites that are targetting WebKit's existing flexbox implementation. WebKit's implementation and Firefox's implementation are different enough that the current uses of flexbox are mostly browser specific (e.g., dashboard widgets). If the issue is the syntax for describing flexing, perhaps the spec should be written in a backwards compatible way, that supports both the new syntax and the old syntax, but the underlying implementation can remain. The new syntax describes a superset of features provided by the old syntax. I think it's possible to implement the old flexbox on top of the new flexbox implementation and that seems like a worthwhile goal, but it'll probably easier to see the similarities for refactoring after the code has been written. On Jun 8, 2011, at 10:57 AM, Tony Chang wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ ( http://dev.w3.org/csswg/css3-flexbox/http://dev.w3.org/csswg/css3-flexbox/#negative-flexibility ) This support will be behind the ENABLE_FLEXBOX feature define ( https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development ( https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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] Do we have a style preference about const member functions?
On Thu, Jun 9, 2011 at 3:51 PM, Maciej Stachowiak m...@apple.com wrote: In principle, the return value could have been retrieved from a container that the immediate callee only has a const reference to. So then casting away const on the return value would be a hazard. You're right; if the implementation of the const function accesses other objects besides |this|, it might be better to re-implement the non-const function rather than simply casting, so the compiler can at least check those accesses. This implies that in general we'd want to limit function pairs to accessors with fairly simple implementations, and only make exceptions where there's real value, lest the maintenance burden and bug surface outweigh any gain from providing caller const convenience. I'll try to keep this in mind before I try posting any patches that split accessors into pairs. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel painting
(Resending from correct email) For HTML5 canvas animations, painting speed is very significant. Android uses a retain mode rendering approach as well; where paint operations are recorded on a WebCore thread and painting is actually done on the UI thread. It isn't necessarily the best approach. But I suppose it depends the platform whether or not there is much to gain. You still need to worry about synchronization. On 6 April 2010 03:24, Eric Seidel e...@webkit.org wrote: Parallel painting would only be useful if the graphics layer is incredibly slow. In most WebKit ports we do not see very much time painting, rather time is more often spent in layout, style resolution, or javascript execution/bindings. -eric On Sat, Apr 3, 2010 at 10:32 PM, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: Hi, I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested. Zoltan ___ 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 -- Pierre. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS bindings: Adding EventTarget to the prototype chain
I don't have a personal opinion on which way is technically better myself. But
I think the key is getting our code aligned with where standards are going,
wether by changing he code or the standards. EventTarget in the prototype chain
seems neither especially awesome nor especially terrible to me, it is not
really clear to me why editor's drafts of the listed specs decided to change.
Cheers,
Maciej
On Jun 9, 2011, at 1:14 PM, Sam Weinig wrote:
I don't think we should do this. EventTarget is really just an abstract
interface, and changing its implementation globally is of limited utility.
-Sam
On Jun 8, 2011, at 5:54 PM, Dominic Cooney wrote:
[If you don't care about JSC or V8 bindings you can safely ignore
this.]
TL;DR I want to change the JavaScript bindings to put EventTarget on
the prototype chain so it is easier to work with event targets from
JavaScript. What do you think?
Here is the prototype chain for a button today:
HTMLButtonElement-HTMLElement-Element-Node-Object
(add/removeEventListener and dispatchEvent are on Node.)
Here is how I think we should make it look:
HTMLButtonElement-HTMLElement-Element-Node-EventTarget-Object
(addEventListener etc. are on EventTarget.)
Here’s why I think we should do this:
- Specs are moving towards specifying EventTarget as living on the
prototype chain. DOM Core*, Notifications, Indexed DB, SVG and XHR
already do it this way. (* Editor’s draft.)
- Frameworks that want to hook add/removeEventListener will be able to
do it in one place: on EventTarget.prototype. In WebKit today they
have to hook the prototypes of window, Node, XMLHttpRequest, etc.
individually (Because WebKit implements EventTarget as a mixin
everywhere, there are 20+ different kinds of event targets to hook if
you want to be comprehensive.) If we make this change, it gets easier
to tell if a given object is an EventTarget; just do
EventTarget.prototype.isPrototypeOf(something).
- It will modestly simplify WebKit’s IDLs and bindings. Instead of
declaring addEventListener in two dozen places in IDLs, it will be in
one place; instead of calling visitJSEventListeners in dozens of
places for JSC GC, it will be called in one place; instead of assuming
that EventTarget parameters are all Node* under the covers for V8 code
generation, we can treat EventTargets uniformly; instead of
redundantly specifying EventTarget on Document and Node inheritance
will do what you want; etc.
Will doing this break the web? I don’t think so:
Anyone who calls or hooks addEventListener, etc. will continue to
work, just their foo.addEventListener might be resolved at one level
higher up the prototype chain than it is today. To really observe the
different placement of addEventListener, etc. minutely you need to
access __proto__ and hasOwnProperty. Other browsers are already differ
from WebKit in this regard, too: For example, Firefox reports
addEventListener is an own property on *every* step in the prototype
chain of DOM objects (until Object.)
Scripts that squirrel up the prototype chain themselves will see one
more link (EventTarget’s) but it is towards the top of the chain, past
most prototypes they care about (every prototype except Object.)
I tried changing half of the EventTargets in WebKit to put EventTarget
in the prototype chain, including Node and XHR (but not window) and
used it to surf the web for a few days. I didn’t notice anything break
:)
There is also the possibility that this could hurt performance,
because accessing addEventListener, etc. will have to search more
prototypes (usually just one more.) Accessing the properties of Object
on an event target via the prototype chain will have to squirrel
through one more prototype (EventTarget’s.) So I prototyped this
change in the JSC bindings and put EventTarget in the prototype chain
of a number of event targets in WebKit, including Node. Here are the
results for Dromaeo’s dom and jslib tests:
http://dromaeo.com/?id=141811,141813
(141811 on the left is the status quo.)
I expect the Prototype and jQuery events benchmarks are of particular
interest, and the result looks particularly bad for Prototype (~3%
slowdown). So I reran http://dromaeo.com/?event half a dozen times,
and couldn’t produce the poor result for Prototype; on average the
prototype was 1.0% slower for Prototype and 0.5% slower for jQuery. I
think Dromaeo is too noisy for measuring something as fine as this.
So I wrote three microbenchmarks:
1. Add/remove click listener on a button.
2. Add/remove progress listener on an XHR.
3. Test property presence with 'in':
if ('dispatchEvent' in target)
n++;
// return n outside of loop
where target is an XMLHttpRequest and n is a local var n = 0.
Here are the results. A brief note on methodology: release build
running in Mac Safari, JSC, averaging 500 samples with 1,000,000
iterations of the inner loop per sample.
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
On Jun 9, 2011, at 3:00 PM, Tony Chang wrote: On Thu, Jun 9, 2011 at 1:19 PM, Sam Weinig wei...@apple.com wrote: Why should we implement this spec? We already have one flex box implementation that we can never remove (and corresponds closely to Firefox's) so it seems to me that we should work on standardizing that model. Adding a large bunch of code that duplicates existing functionality seems foolish. There was an attempt to standardize the old flexbox (http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/), but that effort seems to have fizzled. I attempted to write some patches to make WebKit's old flexbox implementation match that spec, but Hyatt recommended against that because it can only break sites that are targetting WebKit's existing flexbox implementation. WebKit's implementation and Firefox's implementation are different enough that the current uses of flexbox are mostly browser specific (e.g., dashboard widgets). If the issue is the syntax for describing flexing, perhaps the spec should be written in a backwards compatible way, that supports both the new syntax and the old syntax, but the underlying implementation can remain. The new syntax describes a superset of features provided by the old syntax. I think it's possible to implement the old flexbox on top of the new flexbox implementation and that seems like a worthwhile goal, but it'll probably easier to see the similarities for refactoring after the code has been written. If it's a superset then I would much prefer to see the old code incrementally enhanced to support the extended features and new syntax, then to first rewrite from scratch and merge. Maybe the right step 1 is refactoring and cleaning up the old code. Rewriting from scratch throws away accumulated knowledge, and in cases where we have to keep the old implementation too, bloats the code. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel painting
On 6/9/2011 8:24 PM, Pierre-Antoine LaFayette wrote: Android uses a retain mode rendering approach as well; where paint operations are recorded on a WebCore thread and painting is actually done on the UI thread. It isn't necessarily the best approach. But I suppose it depends the platform whether or not there is much to gain. You still need to worry about synchronization. ... On 6 April 2010 03:24, Eric Seidel e...@webkit.org mailto:e...@webkit.org wrote: Parallel painting would only be useful if the graphics layer is incredibly slow. In most WebKit ports we do not see very much time ... On Sat, Apr 3, 2010 at 10:32 PM, Zoltan Herczeg zherc...@inf.u-szeged.hu mailto:zherc...@inf.u-szeged.hu wrote: Hi, I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation Is this something that could be used to duplicate painting commands? I'm very interested in enabling secondary painting contexts, to enable better representation of Zoom, and other common assistive techniques. Example: If the recording is used, prefixed with scale and crop, a user could be presented with a crisp and clear magnification of a focused region or other sub-region. Such techniques could also be useful for remote viewing, via serialization, and for efficient screen dumps [assuming the render works, of course]. It'd be great, if some time, secondary user agents, like the popular ZoomText Magnifier, were able to interact with WebKit and request regions to be painted at a higher resolution, so as to display the magnified image at native resolution. Does that make sense? Is that something that this technique might eventually provide? I suspect that screen mirroring and other forms of screen sharing will become more common in use, as more and more physical screens become common in our common lives. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
