2012/8/21 James Robinson :
>
> - James
>
After reading your writing, I could understand why Chromium team is
implementing deferred image decoder. I definitely agree on your
opinion that we cannot accept the implementation which worsens user
experience.
As mentioned above, we have two approaches t
On Fri, Aug 17, 2012 at 1:54 AM, Dong Seong Hwang
wrote:
> 2012/8/14 Dong Seong Hwang
> > Trigger image decoding early in layout and scroll will certainly
> > relieve flashing though it can’t completely remove the problem. We
> > will apply this optimization to parallel image decoder.
> >
>
> I c
2012/8/14 Dong Seong Hwang
> Trigger image decoding early in layout and scroll will certainly
> relieve flashing though it can’t completely remove the problem. We
> will apply this optimization to parallel image decoder.
>
I changed parallel image decoder to trigger decoding on layout as
Alpha su
2012/8/14 Alpha Lam :
>
>
> 2012/8/13 KwangYul Seo
>>>
>>>
>>> This approach is probably safe (as far as I know) but would have the
>>> downside of an extra pass over the whole render tree, or else overhead of
>>> maintaining an up-to-date list of rendered images; and it would happen very
>>> clos
2012/8/14 KwangYul Seo :
>
>
> On Tue, Aug 14, 2012 at 4:03 AM, Maciej Stachowiak wrote:
>>
>>
>> On Aug 13, 2012, at 11:08 AM, Alpha Lam wrote:
>>
>> That's a good point. I'm not sure but a safe bet would be after RenderView
>> is layout'ed then iterate through images to start decoding.
>>
>> Th
2012/8/13 KwangYul Seo
>
>> This approach is probably safe (as far as I know) but would have the
>> downside of an extra pass over the whole render tree, or else overhead of
>> maintaining an up-to-date list of rendered images; and it would happen very
>> close to painting.
>>
>>
I agree on getti
BTW, we are discussing the very same topic on the master bug. For those of
you who are interested in this topic, please refer to the master bug for
other concerns and probable solutions:
https://bugs.webkit.org/show_bug.cgi?id=90375
On Tue, Aug 14, 2012 at 8:32 AM, KwangYul Seo wrote:
>
>
> On
On Tue, Aug 14, 2012 at 4:03 AM, Maciej Stachowiak wrote:
>
> On Aug 13, 2012, at 11:08 AM, Alpha Lam wrote:
>
> That's a good point. I'm not sure but a safe bet would be after RenderView
> is layout'ed then iterate through images to start decoding.
>
> The same thing would be needed for scrolli
On Aug 13, 2012, at 11:08 AM, Alpha Lam wrote:
> That's a good point. I'm not sure but a safe bet would be after RenderView is
> layout'ed then iterate through images to start decoding.
>
> The same thing would be needed for scrolling too, as page scrolls need to
> iterate images in the viewp
That's a good point. I'm not sure but a safe bet would be after RenderView
is layout'ed then iterate through images to start decoding.
The same thing would be needed for scrolling too, as page scrolls need to
iterate images in the viewport.
Alpha
2012/8/13 Alpha (Hin-Chung) Lam
> That's a good
The thing I'm not confident of is whether an image's position in absolute
coordinates can be changed by an ancestor after RenderImage::layout completes.
It would be helpful if a layout expert would weigh in.
- Maciej
On Aug 13, 2012, at 3:20 AM, Dong Seong Hwang wrote:
> https://bugs.webkit
https://bugs.webkit.org/show_bug.cgi?id=90375#c80
In the above link, Hin-Chung shows how to determine whether an image
is actually painted.
2012/8/13 Maciej Stachowiak :
> I that case, starting async decoding at layout time makes sense if and only
> if at layout to e you can predict what you will
Thanks for raising this issue. It's a very valid issue. This is a
topic I want to discuss more broadly.
There is no behavior change in rendering small images. Parallel image
decoders decode only large images (over 300x300). Although parallel
image decoders change the rendering behavior of large im
I that case, starting async decoding at layout time makes sense if and only if
at layout to e you can predict what you will paint. I don't know enough about
our rendering to know of that is the case.
- Maciej
On Aug 12, 2012, at 5:34 PM, Peter Kasting wrote:
> On Sun, Aug 12, 2012 at 1:24
On Sun, Aug 12, 2012 at 1:24 PM, Maciej Stachowiak wrote:
> Why not start asynchronous decoding immediately as the image is loading,
> and synchronize at paint time? What is the benefit of waiting until layout
> time to start decoding the image data?
>
Uninformed guess (since I haven't touched t
On Aug 10, 2012, at 3:47 PM, Alpha Lam wrote:
> 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 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
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
> t
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
19 matches
Mail list logo
