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
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 m...@apple.com:
I that case, starting async decoding at layout time makes sense if and only
if at layout to e you can predict
Hi, WebKit.
There are several implementations of threads, tasks and cross thread
communication. e.g. FileThread, DatabaseThread and StorageThread perform
blocking IO asynchronously and invoke callbacks using
ScriptExecutionContext. Each of these implementation is pretty similar, but
there is no
Hi,
We are looking for ways to improve page loading speed and reduce memory usage
for WebKit in general and for GTK port of WebKit in particular.
One of the ideas is to implement downscaling of the images during decoding for
image elements with rectangle less then original image size.
At the
On Mon, Aug 13, 2012 at 9:39 AM, Anton Obzhirov a.obzhi...@samsung.comwrote:
**
We are looking for ways to improve page loading speed and reduce memory
usage for WebKit in general and for GTK port of WebKit in particular.
One of the ideas is to implement downscaling of the images
Hi,
At the moment such images are full decoded to a full size buffer and get
downscaled during rendering.
WebKit has already a hard coded
ImageSource::s_maxPixelsPerDecodedImage value, in
WebCode/platform/graphics/ImageSource.cpp which defaults to 1024 *
1024 when WebKit's option
On Monday 13 August 2012, Anton Obzhirov wrote:
Hi,
We are looking for ways to improve page loading speed and reduce memory
usage for WebKit in general and for GTK port of WebKit in particular. One
of the ideas is to implement downscaling of the images during decoding for
image elements
Libjpeg has some internal support for downscaling already (2x, 4x). Not sure
about
Libpng and other libraries. In general probably it can be implemented by
downscaling decoded row of the pixels on the fly using callback API
provided.
From: tomhud...@google.com [mailto:tomhud...@google.com]
Yes, I noticed IMAGE_DECODER_DOWN_SAMPLING option.
I planned to reuse existing ImageDecoder API as much as possible. May be
will need to add
generic image downscaler with platform API. I need to think it through
and I will send my proposal. Should I create a bug for it?
-Original
Hi,
On Mon, Aug 13, 2012 at 3:46 PM, Anton Obzhirov a.obzhi...@samsung.com wrote:
Libjpeg has some internal support for downscaling already (2x, 4x). Not sure
about
Libpng and other libraries. In general probably it can be implemented by
downscaling decoded row of the pixels on the fly
I agree we should have a separate row-based downscaling phase.
JPEGImageDecoder.cpp already supports downscaling with a given width and
height, but it's using point sampling which has poor quality. It would be
nice to have a callback based downscaling API that we can implement better
algorithms.
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 hc...@google.com
On Aug 13, 2012, at 11:08 AM, Alpha Lam hc...@chromium.org 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
Hello WebKittens,
We have made a few improvements on our performance test infrastructure over
the last couple of weeks:
- run-perf-tests now *generates and opens up results page* at the end.
Sample results page:
https://bug-93296-attachments.webkit.org/attachment.cgi?id=156765
- We
Hi,
If such a callback API for row-based resizing comes to fruition, then
let's (also) not rule out whole-picture h/w accelerated resizing -
such as by making that new API a mandatory stage in the decoding
that's actually: such as by *not* making that new API a mandatory
stage in the decoding
On Mon, Aug 13, 2012 at 12:15 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hello WebKittens,
We have made a few improvements on our performance test infrastructure
over the last couple of weeks:
- run-perf-tests now *generates and opens up results page* at the end.
Sample results page:
Thanks for collecting and sharing this data. It'll be interesting to see
how this evolves over time.
-Darin
On Sun, Aug 12, 2012 at 7:43 PM, Kinuko Yasuda kin...@chromium.org wrote:
As a quick follow-up, in Chrome 21 the usage histogram tells ~80% of slice
call is still using webkitSlice (no
2012/8/13 Ilyes Gouta ilyes.go...@gmail.com
Hi,
If such a callback API for row-based resizing comes to fruition, then
let's (also) not rule out whole-picture h/w accelerated resizing -
such as by making that new API a mandatory stage in the decoding
that's actually: such as by *not*
I've got a style warning while preparing a patch for bug 51450:
Alphabetical sorting problem. [build/include_order] [4]
at Source/WebCore/platform/graphics/chromium/FontPlatformDataChromiumWin.cpp
Could someone please advice me if I should re-order the includes, or
ignore this warning? The 3
#include ~ need to appear below #include .
On Mon, Aug 13, 2012 at 1:52 PM, Koji Ishii kojii...@gmail.com wrote:
I've got a style warning while preparing a patch for bug 51450:
Alphabetical sorting problem. [build/include_order] [4]
at
Thanks for the prompt reply. These 3 includes are currently in
trunk. Can you please confirm:
1. Should I fix style errors in the original when I change their
neighbors (and therefore check-webkit-style complains)?
2. The following order passes the style, but it mixes Windows headers
into
On Mon, Aug 13, 2012 at 2:10 PM, Koji Ishii kojii...@gmail.com wrote:
Thanks for the prompt reply. These 3 includes are currently in
trunk. Can you please confirm:
1. Should I fix style errors in the original when I change their
neighbors (and therefore check-webkit-style complains)?
2. The
Hi,
Maintaining N rows is an implementation detail of the scaler. I mean by
having a simple one-scanline-in, zero-or-more-scanlines-out interface, like
this:
scaler.setSourceSize(10, 10);
scaler.setDestSize(100, 100);
while (decoder.hasMoreScanines()) {
On Thu, Jul 19, 2012 at 9:27 PM, Andreas Kling kl...@webkit.org wrote:
On Thu, Jul 19, 2012 at 7:20 PM, Filip Pizlo fpi...@apple.com wrote:
dataLog(foo %d bar %x baz %p\n, a, b, c);
Reasoning and valid arguments aside, that actually looks totally beautiful.
Do want.
+1 from this
On Tue, Aug 14, 2012 at 4:03 AM, Maciej Stachowiak m...@apple.com wrote:
On Aug 13, 2012, at 11:08 AM, Alpha Lam hc...@chromium.org 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
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
2012/8/13 KwangYul Seo sk...@company100.net
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
Currently, there is no code using WTF::Function in single-threaded code. It
seems WTF::Function is intended to be used for cross thread communication.
One evidence is that FunctionImplBase is thread-safe ref-counted, which is
not super efficient for single threaded use cases.
If we have no plan
2012/8/14 KwangYul Seo sk...@company100.net:
On Tue, Aug 14, 2012 at 4:03 AM, Maciej Stachowiak m...@apple.com wrote:
On Aug 13, 2012, at 11:08 AM, Alpha Lam hc...@chromium.org wrote:
That's a good point. I'm not sure but a safe bet would be after RenderView
is layout'ed then iterate
2012/8/14 Alpha Lam hc...@chromium.org:
2012/8/13 KwangYul Seo sk...@company100.net
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
30 matches
Mail list logo
