Looks promising to me. However, as you mentioned, using gpu wastes constant
times. You have to handle trade-off carefully, because decoding small jpeg
is light.
You can work in parallel with Bug 90375 as Niwa mentioned. Bug 90375 tried
to change WebKit architecture to decode off the main thread. Y
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
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 lay
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
ld be needed for scrolling too, as page scrolls need to
>>> iterate images in the viewport.
>>>
>>> Alpha
>>>
>>> 2012/8/13 Maciej Stachowiak
>>>>
>>>>
>>>> The thing I'm not confident of is whether an image's po
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
Hello, folks.
We updated the test results.
http://webkit.org/b/90375#c49
We think the performance improvement is promising.
@ Summary of the results
1. The response time of interactive web pages were improved by
approximately 20%.
2. An embedded device shows a similar performance enhancement as
Given all the discussion that had gone on, ACCELERATED_2D_CANVAS was
created using Skia GPU instead of GraphicsContext3D.
Now, ACCELERATED_2D_CANVAS can be used by only Chromium, and
IOSURFACE_CANVAS_BACKING_STORE
is only for Mac.
Is there any plan of other ports similar to ACCELERATED_2D_CANVAS?
Excellent!!
2012년 2월 27일 오전 10:08, Gyuyoung Kim 님의 말:
> Hello WebKit folks,
>
> Finally, EFL build bot starts to run the layout test (as well as WebKit
> build) from Yesterday.
> - url : http://build.webkit.org/builders/EFL%20Linux%20Release
>
> => Results: 19475/28486 tests passed (68.4%)
> =
Hi,
I ported ACCELERATED_2D_CANVAS to android in the last year at Dorothy team.
ACCELERATED_2D_CANVAS became very different between the last year and
upstream.
The old ACCELERATED_2D_CANVAS used GraphicsContext3D (for WebGL) made
by Kenneth Russell.
However, removed the old ACCELERATED_2D_CANVAS at
I think Mr. Russell has changed tesseleration code from glu tesseleration to
LoopBlinn algorithm.
Does it mean that LoopBlinn algorithm is better than glu tesseleration? If
yes, why?
You mentioned your second trial was Kokojima's algorithm that was
detrimental to performance.
Why is the LoopBlinn a
12 matches
Mail list logo
