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
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
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 co
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 mom
On Mon, Aug 13, 2012 at 9:39 AM, Anton Obzhirov wrote:
>
> **
>
> 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
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 ENABLE(IMAG
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 element
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: [email protected] [mailto:[email protected]] O
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 Message-
Hi,
On Mon, Aug 13, 2012 at 3:46 PM, Anton Obzhirov 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 using callback API
>
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
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
> That's a good
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
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 no
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
On Mon, Aug 13, 2012 at 12:15 PM, Ryosuke Niwa 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:
>https:
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 wrote:
> As a quick follow-up, in Chrome 21 the usage histogram tells ~80% of slice
> call is still using webkitSlice (no wonder as unprefix
2012/8/13 Ilyes Gouta
> 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 th
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 wrote:
> 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/FontPlatformDataChro
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 WebKit
On Mon, Aug 13, 2012 at 2:10 PM, Koji Ishii 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 following o
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()) {
> scaler.supplyScanLine(deco
On Thu, Jul 19, 2012 at 9:27 PM, Andreas Kling wrote:
> On Thu, Jul 19, 2012 at 7:20 PM, Filip Pizlo 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 shameless printfer.
___
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
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
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
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 to
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/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
31 matches
Mail list logo
