Re: [webkit-dev] Status of multithreaded image decoding

2012-08-10 Thread Alpha Lam 
This is a very valid concern. The question you raised is one topic I want
to discuss more broadly.

Chromium has a separate rasterization stage so there is some time for
decoders to work, synchronization can happen in rasterization stage. This
doesn't mean Chromium won't benefit if decoding starts before draw time.

For other ports without rasterization stage this approach alone would have
the problem you mentioned. Just like you suggested decoding have to start
before paint time and then synchronize at paint time. One approach is to
start asynchronous decoding during layout time. When an image is downloaded
metadata is decoded synchronously and triggers a layout when intrinsic
dimension is available. This could be the time to check with current
viewport and start asynchronous decoding. For image used as background of a
RenderBox we can also start decoding if the rectangle of the RenderBox
intersect with viewport.

Alpha

2012/8/10 James Robinson 

>
>
> On Thu, Aug 9, 2012 at 5:10 PM, Alpha Lam  wrote:
>
>> Hi everyone!
>>
>> A few weeks ago some folks from company100.net have started a thread of
>> multithreaded (parallel) image decoding in WebKit. We have worked together
>> since then to get a better idea how to complete this feature. I would like
>> to report on the progress and our plan.
>>
>> (The goal for Chromium is slightly different but it will reuse most of
>> the architecture discussed here.)
>>
>> Master bug: https://bugs.webkit.org/show_bug.cgi?id=90375
>>
>> In WebKit today image rendering is progressive, meaning that image is
>> rendered as bytes are received from the network. This is done through
>> ImageObserver
>>  and 
>> CachedImageClient
>>  interfaces.
>> Multithreaded image decoding uses the same notification architecture,
>> clients of BitmapImage are notified when a new region is decoded and
>> available for painting.
>>
>> Today image decoding happens synchronously when a BitmapImage is drawn
>> into a GraphicsContext. We plan to use the draw operation as a trigger to
>> start image decoding asynchronously. Which means the first draw of
>> BitmapImage will get a transparent image, subsequent draws will have the
>> most recently decoded bitmap.
>>
>>
> I don't think this approach will work terribly well (at least not by
> itself).  It seems to require that we flash at least one frame without the
> image data even when we really do have it available.  For instance, imagine
> a page with a number of small image resources (small enough that they all
> load completely in roughly the same instant), or cached image resources,
> that impact the layout of the page.  Today, when the images load we will
> redo the layout to accomodate the resources size, then at paint time decode
> the images and render them.  The user never sees an intermediate state
> unless the resources isn't fully loaded at paint time.  With this proposal,
> the user would always see a flash where the images occupy layout space but
> are not actually rendered.  I think that will be an unacceptably bad user
> experience.
>
> To do this, I think you either need deeper integration with the raster
> system to make sure that it actually renders the images on the first paint
> (perhaps by deferring the actual raster ops to give the decoder some time),
> or kicking off the decode steps sooner and adding synchronization at paint
> time to make sure we actually see the pixels.
>
> I'm really happy someone is looking into these difficult issues.
>
> - James
>
>  This architecture will take several steps:
>>
>> https://bugs.webkit.org/show_bug.cgi?id=93467
>>
>> This modifies ImageSource to be asynchronous. ImageSource is used as the
>> public interface for decoding images. By making this interface asynchronous
>> individual port can implement parallel image decoding or a similar
>> architecture. This change is ready for review. I would like to get more
>> feedback on the interface since this touches all ports.
>>
>> https://bugs.webkit.org/show_bug.cgi?id=93590
>>
>> Progressive painting of an image may not be possible everywhere. For
>> example  and accelerated-composited  requires synchronous
>> decoding. We plan to keep synchronous decoding the default case. This
>> change identifies code location where asynchronous decoding is possible and
>> tell BitmapImage asynchronous image decoding is requested.
>>
>> After these two changes we will be able to implement multithreaded image
>> decoder inside BitmapImage and ImageSource. I will report on the progress
>> once we get to this point.
>>
>> Alpha
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.w

Re: [webkit-dev] Status of multithreaded image decoding

2012-08-10 Thread James Robinson 
On Thu, Aug 9, 2012 at 5:10 PM, Alpha Lam  wrote:

> Hi everyone!
>
> A few weeks ago some folks from company100.net have started a thread of
> multithreaded (parallel) image decoding in WebKit. We have worked together
> since then to get a better idea how to complete this feature. I would like
> to report on the progress and our plan.
>
> (The goal for Chromium is slightly different but it will reuse most of the
> architecture discussed here.)
>
> Master bug: https://bugs.webkit.org/show_bug.cgi?id=90375
>
> In WebKit today image rendering is progressive, meaning that image is
> rendered as bytes are received from the network. This is done through
> ImageObserver
>  and 
> CachedImageClient
>  interfaces.
> Multithreaded image decoding uses the same notification architecture,
> clients of BitmapImage are notified when a new region is decoded and
> available for painting.
>
> Today image decoding happens synchronously when a BitmapImage is drawn
> into a GraphicsContext. We plan to use the draw operation as a trigger to
> start image decoding asynchronously. Which means the first draw of
> BitmapImage will get a transparent image, subsequent draws will have the
> most recently decoded bitmap.
>
>
I don't think this approach will work terribly well (at least not by
itself).  It seems to require that we flash at least one frame without the
image data even when we really do have it available.  For instance, imagine
a page with a number of small image resources (small enough that they all
load completely in roughly the same instant), or cached image resources,
that impact the layout of the page.  Today, when the images load we will
redo the layout to accomodate the resources size, then at paint time decode
the images and render them.  The user never sees an intermediate state
unless the resources isn't fully loaded at paint time.  With this proposal,
the user would always see a flash where the images occupy layout space but
are not actually rendered.  I think that will be an unacceptably bad user
experience.

To do this, I think you either need deeper integration with the raster
system to make sure that it actually renders the images on the first paint
(perhaps by deferring the actual raster ops to give the decoder some time),
or kicking off the decode steps sooner and adding synchronization at paint
time to make sure we actually see the pixels.

I'm really happy someone is looking into these difficult issues.

- James

This architecture will take several steps:
>
> https://bugs.webkit.org/show_bug.cgi?id=93467
>
> This modifies ImageSource to be asynchronous. ImageSource is used as the
> public interface for decoding images. By making this interface asynchronous
> individual port can implement parallel image decoding or a similar
> architecture. This change is ready for review. I would like to get more
> feedback on the interface since this touches all ports.
>
> https://bugs.webkit.org/show_bug.cgi?id=93590
>
> Progressive painting of an image may not be possible everywhere. For
> example  and accelerated-composited  requires synchronous
> decoding. We plan to keep synchronous decoding the default case. This
> change identifies code location where asynchronous decoding is possible and
> tell BitmapImage asynchronous image decoding is requested.
>
> After these two changes we will be able to implement multithreaded image
> decoder inside BitmapImage and ImageSource. I will report on the progress
> once we get to this point.
>
> Alpha
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?

2012-08-10 Thread Levi Weintraub 
We're back!

On Fri, Aug 10, 2012 at 8:07 AM, Peter Beverloo  wrote:

> It's been down for the past hour, again.  Just a nudge in case it slipped
> through.
>
> Peter
>
>
> On Thu, Aug 9, 2012 at 10:41 AM, Osztrogonac Csaba 
> wrote:
>
>> Hi,
>>
>> bugs.webkit.org and trac.webkit.org is unavailable again. :(
>> Could you check it, please?
>>
>> br,
>> Ossy
>>
>> Osztrogonac Csaba írta:
>>
>>  It seems bugs.webkit.org and trac.webkit.org is unavailable
>>> now. (at least from Hungary) Have you got any idea what happened?
>>>
>> __**_
>> 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] bugs.webkit.org returning 500 errors

2012-08-10 Thread Levi Weintraub 
I'm getting Internal Server Errors accessing anything in bugs.webkit.org.

TGIF I guess? :)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?

2012-08-10 Thread Peter Beverloo 
It's been down for the past hour, again.  Just a nudge in case it slipped
through.

Peter

On Thu, Aug 9, 2012 at 10:41 AM, Osztrogonac Csaba wrote:

> Hi,
>
> bugs.webkit.org and trac.webkit.org is unavailable again. :(
> Could you check it, please?
>
> br,
> Ossy
>
> Osztrogonac Csaba írta:
>
>  It seems bugs.webkit.org and trac.webkit.org is unavailable
>> now. (at least from Hungary) Have you got any idea what happened?
>>
> __**_
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/**mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Chromium for Android builders have been added to the EWS

2012-08-10 Thread Kenneth Rohde Christiansen 
Nice to hear and congratulation with getting so far!

I am very happy that you are aiming at having a working mobile port in
trunk; similar goals that we have for the Qt port.

Cheers
Kenneth

On Fri, Aug 10, 2012 at 12:06 PM, Peter Beverloo  wrote:

> Hi WebKit,
>
> Starting yesterday, a queue is now available for the Early Warning System
> (EWS) which will be building --but not testing-- all patches uploaded to
> Bugzilla for the Chromium for Android configuration.
>
> Compared to Chromium Linux, the main differences are that Android will
> cross-compile the entire project to the ARMv7 architecture (thumb, with
> NEON disabled); the list of enabled features is slightly different[1], and
> some source files have Android-specific implementations. Finally, after
> building the .so libraries is complete, it will create .apk (Android
> Application Package) files for each major target.
>
> The queue[2] currently still has more than 300 patches pending, which
> seems to include every patch that's still pending review or commit. If you
> get build failure notices on patches that haven't been touched for months,
> please feel free to ignore them.
>
> We plan to add a tester to the waterfall in the next few weeks, which will
> also be running all unit tests, API tests and Layout Tests on actual
> devices.
>
> Thanks,
> Peter
>
> [1]
> http://trac.webkit.org/browser/trunk/Source/WebKit/chromium/features.gypi#L148
> [2] http://webkit-commit-queue.appspot.com/queue-status/cr-android-ews
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>


-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit. org

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

[webkit-dev] Chromium for Android builders have been added to the EWS

2012-08-10 Thread Peter Beverloo 
Hi WebKit,

Starting yesterday, a queue is now available for the Early Warning System
(EWS) which will be building --but not testing-- all patches uploaded to
Bugzilla for the Chromium for Android configuration.

Compared to Chromium Linux, the main differences are that Android will
cross-compile the entire project to the ARMv7 architecture (thumb, with
NEON disabled); the list of enabled features is slightly different[1], and
some source files have Android-specific implementations. Finally, after
building the .so libraries is complete, it will create .apk (Android
Application Package) files for each major target.

The queue[2] currently still has more than 300 patches pending, which seems
to include every patch that's still pending review or commit. If you get
build failure notices on patches that haven't been touched for months,
please feel free to ignore them.

We plan to add a tester to the waterfall in the next few weeks, which will
also be running all unit tests, API tests and Layout Tests on actual
devices.

Thanks,
Peter

[1]
http://trac.webkit.org/browser/trunk/Source/WebKit/chromium/features.gypi#L148
[2] http://webkit-commit-queue.appspot.com/queue-status/cr-android-ews
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev