Re: [webkit-dev] parallel painting

[Gustavo Noronha Silva]

On Mon, 2011-06-06 at 17:59 +0530, Monil Parmar wrote:
> How to use it for gtk launcher...I think it is for safari.

A bit late for this answer, but for completeness sake: GtkLauncher is
not a full browser, so it doesn't expose many features available in
WebKitGTK+.

You should use Epiphany or Midori preferably for trying these things. In
any of these browsers you can get to the inspector by right-clicking
anywhere on the page and selecting 'Inspect Element'.

Cheers,

-- 
Gustavo Noronha Silva 
GNOME Project

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] parallel painting

[Zoltan Herczeg]

Hi,

wow, your use case is really interesting. I have never thought about that.
Yeah, that would be a simple extension to the parallel painting system,
you could replay the commands anywhere, any times. It is basically a
vector graphics representation of the screen, you could scale it up.

Actually I am really happy that those techinques we were working on
eventually attracting others. We were the first one who played with
parallelization, SIMD instruction sets, and their usage is growing in
WebKit now. Devices (people) actually use them! It seems playing with new
approaches (even radical changes) are never a waste of time. We could
learn a lot from them.

Regards,
Zoltan

> 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 > > 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
>> 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

Re: [webkit-dev] parallel painting

[Charles Pritchard]

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 > 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
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

Re: [webkit-dev] parallel painting

[Pierre-Antoine LaFayette]

(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  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
>  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] parallel painting

[Monil Parmar]

How to use it for gtk launcher...I think it is for safari.

On Mon, Jun 6, 2011 at 4:39 PM, Mikhail Naganov wrote:

> Yes. Use the Timeline panel in WebKit Inspector:
> http://www.webkit.org/blog/1091/more-web-inspector-updates/#timeline_panel
>
> On Mon, Jun 6, 2011 at 14:44, monpar  wrote:
> >
> > Is there any way to find out how much time is taken "in parsing,
> > layout,rendering,  style resolution or java script execution", while
> loading
> > a webpage.
> >
> >
> > monpar wrote:
> >>
> >> Is there any way to find out how much time is taken "in parsing,
> >> layout,rendering,  style resolution or java script execution", while
> >> loading a webpage.
> >>
> >>
> >>
> >>
> >> Eric Seidel-6 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
> >>>  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
> >>>
> >>>
> >>
> >>
> >
> > --
> > View this message in context:
> http://old.nabble.com/parallel-painting-tp28131184p31782203.html
> > Sent from the Webkit mailing list archive at Nabble.com.
> >
> > ___
> > 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] parallel painting

[Mikhail Naganov]

Yes. Use the Timeline panel in WebKit Inspector:
http://www.webkit.org/blog/1091/more-web-inspector-updates/#timeline_panel

On Mon, Jun 6, 2011 at 14:44, monpar  wrote:
>
> Is there any way to find out how much time is taken "in parsing,
> layout,rendering,  style resolution or java script execution", while loading
> a webpage.
>
>
> monpar wrote:
>>
>> Is there any way to find out how much time is taken "in parsing,
>> layout,rendering,  style resolution or java script execution", while
>> loading a webpage.
>>
>>
>>
>>
>> Eric Seidel-6 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
>>>  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
>>>
>>>
>>
>>
>
> --
> View this message in context: 
> http://old.nabble.com/parallel-painting-tp28131184p31782203.html
> Sent from the Webkit mailing list archive at Nabble.com.
>
> ___
> 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] parallel painting

[monpar]

Is there any way to find out how much time is taken "in parsing,
layout,rendering,  style resolution or java script execution", while loading
a webpage.


monpar wrote:
> 
> Is there any way to find out how much time is taken "in parsing,
> layout,rendering,  style resolution or java script execution", while
> loading a webpage. 
> 
> 
> 
> 
> Eric Seidel-6 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
>>  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
>> 
>> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/parallel-painting-tp28131184p31782203.html
Sent from the Webkit mailing list archive at Nabble.com.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] parallel painting

[Holger Freyther]

On Tuesday 06 April 2010 13:42:30 Zoltan Herczeg wrote:
> Of course, I did a lot of profiling before (using oprofile), and painting
> was slow on my platform.

Can you use oparchive to make the profile available? Also when you say 
painting? Do you mean function (inclusive) spend below QWebFrame::render? or 
really the work on QPainter and the RenderTree doing the painting?

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] parallel painting

[Zoltan Herczeg]

Of course, I did a lot of profiling before (using oprofile), and painting
was slow on my platform.

Zoltan

> 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
>  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

Re: [webkit-dev] parallel painting

[Mike Marchywka]

> Date: Mon, 5 Apr 2010 17:54:35 -0800
> From: barbi...@profusion.mobi
> To: zherc...@inf.u-szeged.hu
> CC: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] parallel painting
>
> On Sat, Apr 3, 2010 at 9:32 PM, Zoltan Herczeg  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.
>
> EFL port would be interested in this. Could you provide more details
> on the implementation? Is the painting thread a single thread, or is
> it being split to N cores?
>
> Did you consider the alternative that is isolate webkit layout in
> another thread as well? From our environment tests (embedded systems),
> re-layout process can take few seconds without any paint... that being
> done in the main thread hurts the whole experience as the event
> processing of menus, animations and others are blocked. In an ideal
> world WebKit would never block, it would just proxy input and output

What prevents this right now? That is, what puts work on an event thread
instead of launching a worker thread? Generally of course event threads
handle and record events- set flags, manage workers, maybe do simple 
things with existing data but no IO or unpredictable operations that may 
encounter contention( block). Certainly you don't want to use it to execute
things that may require user intervention. 

I guess besides watching the disk light blink for "VM" while I'm trying to do 
something
simple, I've personally found little more that is annoying than an 
unresponsive GUI thread. From the developer standpoint, you are stuck
with options for responding to exceptional or pathological conditions
with, say webpages or network conditions, if you can't count on a 
responsive GUI thread to process user input. I guess on limited resource
devices threads are limited and launching new threads does create
problems, often slowing things down overall when parallelism is the intent,
but in this case you are only trying to preserve one thread's response time.
Indeed, on phone's the first rule has been "don't hang the UI thread" since
this allows user to report bugs and have a live menu system for recovery from
wierd conditions. 




> events to its thread (hard, error-prone... :-/), there it would
> layout, render and when ready release the main thread to use the
> painted contents (maybe tiles as the Qt port now enables).
>
> BR,
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
  
_
Hotmail is redefining busy with tools for the New Busy. Get more from your 
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] parallel painting

[Eric Seidel]

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
 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

Re: [webkit-dev] parallel painting

[Zoltan Herczeg]

Hi,

Thank all of you for your feedbacks!

Let's continue this discussion in the bug report, I will provide more
details there.

Zoltan

> On Sat, Apr 3, 2010 at 9:32 PM, Zoltan Herczeg 
> 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.
>
> EFL port would be interested in this. Could you provide more details
> on the implementation? Is the painting thread a single thread, or is
> it being split to N cores?
>
> Did you consider the alternative that is isolate webkit layout in
> another thread as well? From our environment tests (embedded systems),
> re-layout process can take few seconds without any paint... that being
> done in the main thread hurts the whole experience as the event
> processing of menus, animations and others are blocked. In an ideal
> world WebKit would never block, it would just proxy input and output
> events to its thread (hard, error-prone... :-/), there it would
> layout, render and when ready release the main thread to use the
> painted contents (maybe tiles as the Qt port now enables).
>
> BR,
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] parallel painting

[Gustavo Sverzut Barbieri]

On Sat, Apr 3, 2010 at 9:32 PM, Zoltan Herczeg  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.

EFL port would be interested in this. Could you provide more details
on the implementation? Is the painting thread a single thread, or is
it being split to N cores?

Did you consider the alternative that is isolate webkit layout in
another thread as well? From our environment tests (embedded systems),
re-layout process can take few seconds without any paint... that being
done in the main thread hurts the whole experience as the event
processing of menus, animations and others are blocked. In an ideal
world WebKit would never block, it would just proxy input and output
events to its thread (hard, error-prone... :-/), there it would
layout, render and when ready release the main thread to use the
painted contents (maybe tiles as the Qt port now enables).

BR,

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev