[chromium-dev] Re: extensions and memory usage

[Mike Belshe]

2-3MB is basically the minimum size.
Mike


On Fri, Jul 10, 2009 at 6:00 PM, Paweł Hajdan Jr.
wrote:

>
> How big the V8 heap is? I think that it would be very useful to know
> how the memory is used inside the extension process. Are there good
> tools to do that? I heard about "heap profilers"...
>
> On Fri, Jul 10, 2009 at 17:57, Matt Perry wrote:
> > I suspect a big chunk of the memory is the V8 heap.  Each process that
> uses
> > V8 will need a separate heap.  We could experiment with lowering the heap
> > size for extensions, if we think extensions will be less script heavy
> than
> > web pages.
> >
> > On Fri, Jul 10, 2009 at 5:37 PM, Erik Kay  wrote:
> >>
> >> As we add more subprocesses (workers, utilities, extensions, etc.), it
> >> would be great if we could reduce the minimum memory that these
> processes
> >> consume.  I know that there was some work done a while back to look at
> what
> >> was the minimum cost of a new process on Windows given our dll size,
> etc.
> >> (maruel?), but I'm sure that there's more than can be done for us to
> reduce
> >> memory usage above this level.
> >> Erik
> >>
> >> On Fri, Jul 10, 2009 at 1:03 PM, Paweł Hajdan Jr.
> >>  wrote:
> >>>
> >>> As extensions are visible in the task manager, it's also possible to
> >>> see their memory usage. I was experimenting with some sample
> >>> extensions, and the usage seems to be in range 1 MB - 12 MB. Typically
> >>> 3-5 MB.
> >>>
> >>> I wonder if it would be possible to reduce that memory usage. In case
> >>> it negatively affects performance, we could have some opt-in way for
> >>> extension developers to say "I want my extensions to run as fast as
> >>> possible, even with increased memory usage".
> >>>
> >>> What do you think?
> >>>
> >>>
> >>
> >>
> >> >>
> >
> >
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Does those VC output matter?

[Hua Su]

It seems notification leak doesn't matter.
Besides notification leak, there are 6 threads exited and 1 program exited,
is this bug or by design?

On Sat, Jul 11, 2009 at 2:40 AM, Peter Kasting  wrote:

> On Thu, Jul 9, 2009 at 7:45 PM, Hua Su  wrote:
>
>> It reads several threads exited and some notifications leaked. I don't
>> know what those line of messages mean. Although I Chrome still works well to
>> browse web pages, are there internal errors within Chrome?
>>
>
> If you can build and run the code in Visual Studio, you can probably find
> out (a) where that message gets printed and (b) what those notification
> numbers correspond to, leading to (c) who's allocating them where.
>
> But if not: these *could be* bugs but likely aren't (I rewrote all our uses
> of notifications a month or two ago to use some auto-cleanup classes, but
> there are a number of places where a singleton needs a notification).
>
> PK
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Moving LayoutTests to src/third_party/WebKit

[Ryosuke Niwa]

On Thu, Jul 9, 2009 at 3:09 PM, Victor Wang  wrote:

> If you DO NOT check out chromium source code, you can stop reading.
> *What's the change?*
> To reduce people's confusion about the LayoutTests directory, I am moving
> it from *src/webkit/data/layout_tests/LayoutTests* to *
> src/third_party/WebKit/**LayoutTests*. For details of this request, see
> issue: http://code.google.com/p/chromium/issues/detail?id=8765
>

Does this mean that in the future, all expected results will be in WebKit?
 i.e. we no longer need to update Chromium tree whenever WebKit changes
expected results.

Ryosuke

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: extensions and memory usage

[Marc-Antoine Ruel]

Yeah as long as you don't call any user32 function w.r.t. message loops it's
not too bad but as soon as you suck in win32k.sys, you've just lost a meg or
two. It's quite hard to not suck it in, com, accessibility, windows, a lot
of things are dependent on that.
Using delay dll helps too. Trim anything you don't need to load, especially
shell32.

Beside that, regression testing is the best thing to do first (hint hint)

I don't know the new processes types enough to comment more on that.

M-A

On Fri, Jul 10, 2009 at 8:37 PM, Erik Kay  wrote:

> As we add more subprocesses (workers, utilities, extensions, etc.), it
> would be great if we could reduce the minimum memory that these processes
> consume.  I know that there was some work done a while back to look at what
> was the minimum cost of a new process on Windows given our dll size, etc.
> (maruel?), but I'm sure that there's more than can be done for us to reduce
> memory usage above this level.
> Erik
>
>
> On Fri, Jul 10, 2009 at 1:03 PM, Paweł Hajdan Jr.  > wrote:
>
>>
>> As extensions are visible in the task manager, it's also possible to
>> see their memory usage. I was experimenting with some sample
>> extensions, and the usage seems to be in range 1 MB - 12 MB. Typically
>> 3-5 MB.
>>
>> I wonder if it would be possible to reduce that memory usage. In case
>> it negatively affects performance, we could have some opt-in way for
>> extension developers to say "I want my extensions to run as fast as
>> possible, even with increased memory usage".
>>
>> What do you think?
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: extensions and memory usage

[Paweł Hajdan Jr .]

How big the V8 heap is? I think that it would be very useful to know
how the memory is used inside the extension process. Are there good
tools to do that? I heard about "heap profilers"...

On Fri, Jul 10, 2009 at 17:57, Matt Perry wrote:
> I suspect a big chunk of the memory is the V8 heap.  Each process that uses
> V8 will need a separate heap.  We could experiment with lowering the heap
> size for extensions, if we think extensions will be less script heavy than
> web pages.
>
> On Fri, Jul 10, 2009 at 5:37 PM, Erik Kay  wrote:
>>
>> As we add more subprocesses (workers, utilities, extensions, etc.), it
>> would be great if we could reduce the minimum memory that these processes
>> consume.  I know that there was some work done a while back to look at what
>> was the minimum cost of a new process on Windows given our dll size, etc.
>> (maruel?), but I'm sure that there's more than can be done for us to reduce
>> memory usage above this level.
>> Erik
>>
>> On Fri, Jul 10, 2009 at 1:03 PM, Paweł Hajdan Jr.
>>  wrote:
>>>
>>> As extensions are visible in the task manager, it's also possible to
>>> see their memory usage. I was experimenting with some sample
>>> extensions, and the usage seems to be in range 1 MB - 12 MB. Typically
>>> 3-5 MB.
>>>
>>> I wonder if it would be possible to reduce that memory usage. In case
>>> it negatively affects performance, we could have some opt-in way for
>>> extension developers to say "I want my extensions to run as fast as
>>> possible, even with increased memory usage".
>>>
>>> What do you think?
>>>
>>>
>>
>>
>> >>
>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: extensions and memory usage

[Matt Perry]

I suspect a big chunk of the memory is the V8 heap.  Each process that uses
V8 will need a separate heap.  We could experiment with lowering the heap
size for extensions, if we think extensions will be less script heavy than
web pages.

On Fri, Jul 10, 2009 at 5:37 PM, Erik Kay  wrote:

> As we add more subprocesses (workers, utilities, extensions, etc.), it
> would be great if we could reduce the minimum memory that these processes
> consume.  I know that there was some work done a while back to look at what
> was the minimum cost of a new process on Windows given our dll size, etc.
> (maruel?), but I'm sure that there's more than can be done for us to reduce
> memory usage above this level.
> Erik
>
>
> On Fri, Jul 10, 2009 at 1:03 PM, Paweł Hajdan Jr.  > wrote:
>
>>
>> As extensions are visible in the task manager, it's also possible to
>> see their memory usage. I was experimenting with some sample
>> extensions, and the usage seems to be in range 1 MB - 12 MB. Typically
>> 3-5 MB.
>>
>> I wonder if it would be possible to reduce that memory usage. In case
>> it negatively affects performance, we could have some opt-in way for
>> extension developers to say "I want my extensions to run as fast as
>> possible, even with increased memory usage".
>>
>> What do you think?
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: extensions and memory usage

[Erik Kay]

As we add more subprocesses (workers, utilities, extensions, etc.), it would
be great if we could reduce the minimum memory that these processes consume.
 I know that there was some work done a while back to look at what was the
minimum cost of a new process on Windows given our dll size, etc. (maruel?),
but I'm sure that there's more than can be done for us to reduce memory
usage above this level.
Erik


On Fri, Jul 10, 2009 at 1:03 PM, Paweł Hajdan Jr.
wrote:

>
> As extensions are visible in the task manager, it's also possible to
> see their memory usage. I was experimenting with some sample
> extensions, and the usage seems to be in range 1 MB - 12 MB. Typically
> 3-5 MB.
>
> I wonder if it would be possible to reduce that memory usage. In case
> it negatively affects performance, we could have some opt-in way for
> extension developers to say "I want my extensions to run as fast as
> possible, even with increased memory usage".
>
> What do you think?
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] base::string16 / WebCore::String incompatibility

[Jeremy Orlow]

WebCore::String has the interesting property of differentiating between an
empty string and a null string. In string16, however, there is no such thing
as null.

The LocalStorage implementation I'm working on proxies data between the
rednerer processes and browser process. Some of this data is in the form of
WebCore::Strings that need to differentiate between empty and null.

I could add a boolean to all IPC messages where the string could be null and
then add explicit checking (rather than using the elegant and implicit type
conversions that normally happen from WebCore::String <-> WebKit::WebString
<-> base::string16) but that seems pretty ugly. I think a better solution is
adding a new type to base, adding serializing code to
common/ipc_message_utils, and adding implicit type conversions between
WebKit::WebString and this new type.

First of all, is that a good idea? Second of all, what would be a good name
for it? NullableString16?

Thanks!
Jeremy

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Meeting Notes From 2/9/2009 Now Posted!

[Jeremy Orlow]

On Fri, Jul 10, 2009 at 4:48 AM, Mohamed Mansour  wrote:

> An OWP seems an excellent thing. The thing is, there seems to be a
> separation between internal Google developers and External developers. For
> instance, we are not brought into the loop regarding some processes. I know
> some of you use the mailing list to bring out ideas which is awesome, and do
> a discussion. But many features just come out of nowhere.


Even if you work at Google, many of the features come out of nowhere.  :-)

I think roadmaps could help here, but honestly I'm not sure how much it
actually matters that everyone is in the loop...especially since
being/keeping people in the loop uses up "resources" that could otherwise be
"spent" working on new features.  I actually think it's better that we move
quickly to get new features out there (sometimes behind flags) and then
iterate from there.

Already, almost all technical discussion happens on the external mailing
list or IRC.  The Google Chrome team is geographically distributed, which
definitely helps in more communication being done via mailing lists and thus
externally.

Besides meetings, I'm not really sure what other "processes" your talking
about though.  And I think roadmaps will bring 90% of the benefits to
meeting minutes.


> Would be cool to know the path of what chromium is going to become (I know
> stability, security, etc, etc), and our (external) voice would matter on how
> the development / discussion is going. More involvement into the project
> would be better than just being considered as a "programmer" only.


Most technical discussion already happens in bugs.  There are definitely too
many bugs flying by to keep track of all of them, which is why a roadmap
might help: it could give a high level overview and then point to specific
bugs for further discussion.

As for "being considered as a programmer": this is pretty much how open
source projects work.  "Power" is gained by being the go-to person for
stuff.  It just so happens that all the go-to people are at Google right
now.  Hopefully that'll change over time.  :-)

I think UI decisions are the only exception to this rule...and there are
both pros and cons to that.


> Some projects do weekly or biweekly quick online meetings on IRC. Its
> productive because its like a quick weekly scrum where we discuss next
> release goals etc etc. I don't know how Chromium is organized or if it
> applies to us.
>

I'm sure a number of developers here would be open to trying this out, but
I'm not sure how useful it'd be.

Can you think of a sample agenda for such a meeting?

J



> On Fri, Jul 10, 2009 at 12:48 AM, Brian Rakowski wrote:
>
>> We stopped posting because (a) the notes seemed not to be very useful out
>> of context and (b) removing any Google-specific info, though it was minimal,
>> was pretty labor intensive. I think it may be more productive to try to keep
>> some public roadmaps and tasklists updated. Ian is working on creating an
>> OWP roadmap that will be updated weekly with the status of the main areas of
>> work. If that works out, perhaps we can do the same for other areas of the
>> project. It seems like that would be more helpful and also more practical.
>> Does that seem like it would meet the needs of the external developers? I
>> want to make sure contributors have the info they need to be productive, but
>> I don't want to create unnecessary work.
>> Brian
>>
>>
>> On Thu, Jul 9, 2009 at 8:10 PM, Evan Stade  wrote:
>>
>>>
>>> Is it possible to continue posting these? external developers have
>>> requested it.
>>>
>>> -- Evan Stade
>>>
>>>
>>>
>>> On Wed, Feb 11, 2009 at 10:18 AM, Peter Kasting
>>> wrote:
>>> > On Tue, Feb 10, 2009 at 6:19 PM, Glenn Wilson 
>>> wrote:
>>> >>
>>> >> Meeting notes from February 9, 2009 are now posted on the Chromium
>>> >> developer documentation:
>>> >>
>>> >>
>>> http://sites.google.com/a/chromium.org/dev/developers/meeting-notes#02092009
>>> >> Please contact me if you have any questions, and enjoy!
>>> >
>>> > It might be nice to post these on a blog somewhere, primarily so they
>>> can be
>>> > grabbed via RSS; various Mozilla meeting notes are posted this way.
>>> >
>>> > PK
>>> > >
>>> >
>>>
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Point the browser to an URL

[Roberto Perez]

I keep working on it,
The basic functionality of DnD is very simple, but call a browser method
isn't so :)

On Mac ( and i think that the same on windows and linux ) there is a
BaseView subclass called RenderWidgetHostViewMac that has an atributte of
the type RenderWidgetHost. I believe that i can use RenderWidgetHost to
communicate with RenderProcessHost in order to reach Browser class and call
OpenURL.

am I in the right direction to reach Browser class and make it to open an
URL?

Indeed, is there any document explaining the core architechture of
chromium?, I think it would be very useful to newbies :)

Roberto.

On Tue, Jul 7, 2009 at 6:58 AM, PhistucK  wrote:

> If it is using the same functions as the Windows version uses for opening
> URLs (and I believe it does, since this is a very basic core functionality
> that should be unified), then search for the way the Go button goes to the
> URL in toolbar. Generally, I found it in browser.h\cc (
> http://src.chromium.org/svn/trunk/src/chrome/browser/browser.cc)-
> OpenURL(url, referrer, disposition, transition);
> For example -
> OpenURL(file_url, GURL(), CURRENT_TAB, PageTransition::TYPED);
>
> Actual function -
>
> void Browser::OpenURL(const GURL& url, const GURL& referrer,
>   WindowOpenDisposition disposition,
>   PageTransition::Type transition) {
>   OpenURLFromTab(NULL, url, referrer, disposition, transition);
> }
>
>
> ☆PhistucK
>
>
> On Mon, Jul 6, 2009 at 23:54, Roberto  wrote:
>
>>
>> Hello,
>>
>> I'm working in Drag'n Drop missing feature in Mac version. (issue
>> #12263)
>> I'm pretty new in Chrome develop and I'm very lost in many things.
>>
>> Now, I capture de "drop" events and take the URL to navigate, ( I
>> place the code in cocoa/base_view.mm ) but i dont know how can I make
>> the browser to open that URL.
>>
>> I'm investigating how autocomplete bar does the work hoping to find
>> light in it.
>>
>> If you have any clues I would appreciate it :)
>>
>> Greets
>> Roberto.
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Theme re-encoding

[Aaron Boodman]

Doh. For some reason I always thought it had options to be used either way.

On Fri, Jul 10, 2009 at 1:32 PM, Avi Drissman wrote:
> PNG is lossless, so we should be good there.
>
> Avi
>
> On Fri, Jul 10, 2009 at 4:30 PM, Aaron Boodman  wrote:
>>
>> On this same subject -- do we do any lossy compression in our png
>> encoding? I think we should *not*. Developers will be peeved if their
>> carefully compressed images come out looking different because of our
>> internal implementation details.
>>
>> - a
>>
>> On Fri, Jul 10, 2009 at 1:17 PM, Avi Drissman wrote:
>> > Nailed: http://codereview.chromium.org/149473
>> >
>> > Avi
>> >
>> > On Fri, Jul 10, 2009 at 4:15 PM, Amanda Walker 
>> > wrote:
>> >>
>> >> On Fri, Jul 10, 2009 at 3:54 PM, Avi Drissman wrote:
>> >> > Two things. First, this doesn't happen on Windows. Second, how do you
>> >> > get an
>> >> > image shifted one pixel to the right? On the Mac,
>> >> > ImageDecoder::Decode
>> >> > uses
>> >> > the webkit decoders which on the Mac return a CGImage, and then
>> >> > gfx::CGImageToSkBitmap is called.
>> >>
>> >> Well, all platforms use the webkit decoders (as of Darin's refactoring
>> >> in January), they just return different the image differently.
>> >> gfx::CGImageToSkBitmap does sound like a likely culprit, though :-).
>> >>
>> >> --Amanda
>> >
>> >
>> > >> >
>> >
>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Theme re-encoding

[Avi Drissman]

PNG is lossless, so we should be good there.

Avi

On Fri, Jul 10, 2009 at 4:30 PM, Aaron Boodman  wrote:

> On this same subject -- do we do any lossy compression in our png
> encoding? I think we should *not*. Developers will be peeved if their
> carefully compressed images come out looking different because of our
> internal implementation details.
>
> - a
>
> On Fri, Jul 10, 2009 at 1:17 PM, Avi Drissman wrote:
> > Nailed: http://codereview.chromium.org/149473
> >
> > Avi
> >
> > On Fri, Jul 10, 2009 at 4:15 PM, Amanda Walker 
> wrote:
> >>
> >> On Fri, Jul 10, 2009 at 3:54 PM, Avi Drissman wrote:
> >> > Two things. First, this doesn't happen on Windows. Second, how do you
> >> > get an
> >> > image shifted one pixel to the right? On the Mac, ImageDecoder::Decode
> >> > uses
> >> > the webkit decoders which on the Mac return a CGImage, and then
> >> > gfx::CGImageToSkBitmap is called.
> >>
> >> Well, all platforms use the webkit decoders (as of Darin's refactoring
> >> in January), they just return different the image differently.
> >> gfx::CGImageToSkBitmap does sound like a likely culprit, though :-).
> >>
> >> --Amanda
> >
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Moving LayoutTests to src/third_party/WebKit

[Dimitri Glazkov]

Right. Victor is just switching the tests to reside where they needed
to be, not dealing with test results. Test results is somewhat of a
longer story and we're not tackling this yet.

:DG<

On Fri, Jul 10, 2009 at 12:07 PM, Victor Wang wrote:
>
>
> On Fri, Jul 10, 2009 at 11:11 AM, Ryosuke Niwa  wrote:
>>
>> On Thu, Jul 9, 2009 at 3:09 PM, Victor Wang  wrote:
>>>
>>> If you DO NOT check out chromium source code, you can stop reading.
>>> What's the change?
>>> To reduce people's confusion about the LayoutTests directory, I am moving
>>> it from src/webkit/data/layout_tests/LayoutTests
>>> to src/third_party/WebKit/LayoutTests. For details of this request, see
>>> issue: http://code.google.com/p/chromium/issues/detail?id=8765
>>
>> Does this mean that in the future, all expected results will be in WebKit?
>>  i.e. we no longer need to update Chromium tree whenever WebKit changes
>> expected results.
>
> I think eventually we will get rid of chrome and upstream platform. For now,
> I just move the LayoutTests directory. Ojan or Dimitri can correct me if I
> am wrong.
>
>>
>> Ryosuke
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Theme re-encoding

[Aaron Boodman]

On this same subject -- do we do any lossy compression in our png
encoding? I think we should *not*. Developers will be peeved if their
carefully compressed images come out looking different because of our
internal implementation details.

- a

On Fri, Jul 10, 2009 at 1:17 PM, Avi Drissman wrote:
> Nailed: http://codereview.chromium.org/149473
>
> Avi
>
> On Fri, Jul 10, 2009 at 4:15 PM, Amanda Walker  wrote:
>>
>> On Fri, Jul 10, 2009 at 3:54 PM, Avi Drissman wrote:
>> > Two things. First, this doesn't happen on Windows. Second, how do you
>> > get an
>> > image shifted one pixel to the right? On the Mac, ImageDecoder::Decode
>> > uses
>> > the webkit decoders which on the Mac return a CGImage, and then
>> > gfx::CGImageToSkBitmap is called.
>>
>> Well, all platforms use the webkit decoders (as of Darin's refactoring
>> in January), they just return different the image differently.
>> gfx::CGImageToSkBitmap does sound like a likely culprit, though :-).
>>
>> --Amanda
>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Theme re-encoding

[Avi Drissman]

Nailed: http://codereview.chromium.org/149473

Avi

On Fri, Jul 10, 2009 at 4:15 PM, Amanda Walker  wrote:

> On Fri, Jul 10, 2009 at 3:54 PM, Avi Drissman wrote:
> > Two things. First, this doesn't happen on Windows. Second, how do you get
> an
> > image shifted one pixel to the right? On the Mac, ImageDecoder::Decode
> uses
> > the webkit decoders which on the Mac return a CGImage, and then
> > gfx::CGImageToSkBitmap is called.
>
> Well, all platforms use the webkit decoders (as of Darin's refactoring
> in January), they just return different the image differently.
> gfx::CGImageToSkBitmap does sound like a likely culprit, though :-).
>
> --Amanda
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Theme re-encoding

[Amanda Walker]

On Fri, Jul 10, 2009 at 3:54 PM, Avi Drissman wrote:
> Two things. First, this doesn't happen on Windows. Second, how do you get an
> image shifted one pixel to the right? On the Mac, ImageDecoder::Decode uses
> the webkit decoders which on the Mac return a CGImage, and then
> gfx::CGImageToSkBitmap is called.

Well, all platforms use the webkit decoders (as of Darin's refactoring
in January), they just return different the image differently.
gfx::CGImageToSkBitmap does sound like a likely culprit, though :-).

--Amanda

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Enforcing try job success

[Marc-Antoine Ruel]

Hi

http://src.chromium.org/viewvc/chrome?view=rev&revision=20397 now enforces
try job execution and success for commit (at least for gcl).This is what I
call *An el' cheapos **presubmit queue*.

I plan to be on vacation in the next weeks so I may not answer fast.
This is what I call "Good timing (tm)".
Feel free to bypass the check whenever needed (as it will be needed some
times).

At least, that forced me to write some doc, including a troubleshooting
guide, for try server usage:
http://sites.google.com/a/chromium.org/dev/developers/try-server-usage
(Hey, I'm just 10 months late)

Thanks,

M-A

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] extensions and memory usage

[Paweł Hajdan Jr .]

As extensions are visible in the task manager, it's also possible to
see their memory usage. I was experimenting with some sample
extensions, and the usage seems to be in range 1 MB - 12 MB. Typically
3-5 MB.

I wonder if it would be possible to reduce that memory usage. In case
it negatively affects performance, we could have some opt-in way for
extension developers to say "I want my extensions to run as fast as
possible, even with increased memory usage".

What do you think?

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Theme re-encoding

[Avi Drissman]

A...

Two things. First, this doesn't happen on Windows. Second, how do you get an
image shifted one pixel to the right? On the Mac, ImageDecoder::Decode uses
the webkit decoders which on the Mac return a CGImage, and then
gfx::CGImageToSkBitmap is called.

I'm going to go over gfx::CGImageToSkBitmap carefully. It does the
conversion by drawing the image into the bitmap...

Avi

On Fri, Jul 10, 2009 at 3:38 PM, Avi Drissman  wrote:

> Even with a jpg source we get column 0 invisible, so it's a PNG encoder
> issue. In addition, in an imaged editor it looks like the image is shifted
> over one pixel, not that the first column was overwritten.
>
> Avi
>
>
> On Fri, Jul 10, 2009 at 12:21 PM, Avi Drissman  wrote:
>
>> I'm building an extension with a jpg source. If it gets the column then
>> it's an encoder issue, else decoder issue. I'll let you know as soon as I
>> find out.
>>
>> Avi
>>
>>
>> On Fri, Jul 10, 2009 at 12:18 PM, Glen Murphy  wrote:
>>
>>> This may be a PNGEncoder/Decoder bounce issue, and I don't think the
>>> base gfx unittests check the first vertical column of pixels.
>>>
>>> I landed some changes to PNGEncoder/Decoder in the last week, but it
>>> seems like the problem existed before then. Not sure whether the issue
>>> is that the first column gets corrupted, or whether everything gets
>>> right-shifted by one. I suspect the former, as our favicons go through
>>> this bounce process and we'd probably have noticed clipping there.
>>>
>>>
>>> On Fri, Jul 10, 2009 at 9:04 AM, Avi Drissman wrote:
>>> > We re-encode the pngs in themes. Somewhere in the the process we break
>>> them;
>>> > we're encoding them off by one pixel, so that we have a vertical line
>>> on the
>>> > left, one pixel wide, that's transparent. It isn't obvious on Windows
>>> (but
>>> > it is there; look for it!) but it's glaringly obvious on the Mac. I'm
>>> going
>>> > to look at it after I land the first pass at theming today, but can you
>>> > think of an obvious cause?
>>> >
>>> > Avi
>>> >
>>> > >>> >
>>> >
>>>
>>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Theme re-encoding

[Avi Drissman]

Even with a jpg source we get column 0 invisible, so it's a PNG encoder
issue. In addition, in an imaged editor it looks like the image is shifted
over one pixel, not that the first column was overwritten.

Avi

On Fri, Jul 10, 2009 at 12:21 PM, Avi Drissman  wrote:

> I'm building an extension with a jpg source. If it gets the column then
> it's an encoder issue, else decoder issue. I'll let you know as soon as I
> find out.
>
> Avi
>
>
> On Fri, Jul 10, 2009 at 12:18 PM, Glen Murphy  wrote:
>
>> This may be a PNGEncoder/Decoder bounce issue, and I don't think the
>> base gfx unittests check the first vertical column of pixels.
>>
>> I landed some changes to PNGEncoder/Decoder in the last week, but it
>> seems like the problem existed before then. Not sure whether the issue
>> is that the first column gets corrupted, or whether everything gets
>> right-shifted by one. I suspect the former, as our favicons go through
>> this bounce process and we'd probably have noticed clipping there.
>>
>>
>> On Fri, Jul 10, 2009 at 9:04 AM, Avi Drissman wrote:
>> > We re-encode the pngs in themes. Somewhere in the the process we break
>> them;
>> > we're encoding them off by one pixel, so that we have a vertical line on
>> the
>> > left, one pixel wide, that's transparent. It isn't obvious on Windows
>> (but
>> > it is there; look for it!) but it's glaringly obvious on the Mac. I'm
>> going
>> > to look at it after I land the first pass at theming today, but can you
>> > think of an obvious cause?
>> >
>> > Avi
>> >
>> > >> >
>> >
>>
>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Moving LayoutTests to src/third_party/WebKit

[Victor Wang]

On Fri, Jul 10, 2009 at 11:11 AM, Ryosuke Niwa  wrote:

> On Thu, Jul 9, 2009 at 3:09 PM, Victor Wang  wrote:
>
>> If you DO NOT check out chromium source code, you can stop reading.
>> *What's the change?*
>> To reduce people's confusion about the LayoutTests directory, I am moving
>> it from *src/webkit/data/layout_tests/LayoutTests* to *
>> src/third_party/WebKit/**LayoutTests*. For details of this request, see
>> issue: http://code.google.com/p/chromium/issues/detail?id=8765
>>
>
> Does this mean that in the future, all expected results will be in WebKit?
>  i.e. we no longer need to update Chromium tree whenever WebKit changes
> expected results.
>
I think eventually we will get rid of chrome and upstream platform. For now,
I just move the LayoutTests directory. Ojan or Dimitri can correct me if I
am wrong.


>
> Ryosuke
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Does those VC output matter?

[Evan Martin]

http://code.google.com/p/chromium/issues/detail?id=11010

I looked into this and found that cleaning some of them up will be
annoying to implement.
I think it would be good to turn off the message if we're not going to fix it.

On Thu, Jul 9, 2009 at 7:45 PM, Hua Su wrote:
> Hi,
> I manage to build debug version of 3.0.190.2 on WinXP with VS2005. After I
> hit F5 to run Chrome, VS output a couple of lines about dlls loaded and
> followed by lines below:
> ...
> 'chrome.exe': Loaded 'C:\WINDOWS\system32\imm32.dll', No symbols loaded.
> 'chrome.exe': Loaded 'C:\WINDOWS\system32\lpk.dll', No symbols loaded.
> 'chrome.exe': Loaded 'C:\WINDOWS\system32\usp10.dll', No symbols loaded
> ...
> The thread 'Chrome_IOThread' (0x100c0) has exited with code 0 (0x0).
> The thread 'Chrome_FileThread' (0x1277c) has exited with code 0 (0x0).
> [76960:73860:8609:WARNING:notification_service.cc(128)] 1 notification
> observer(s) leaked of notification type 87
> [76960:73860:8609:WARNING:notification_service.cc(128)] 1 notification
> observer(s) leaked of notification type 90
> The thread 'BrokerEventThread' (0x12d38) has exited with code 0 (0x0).
> The thread 'Win32 Thread' (0x12568) has exited with code 0 (0x0).
> The thread 'Win32 Thread' (0x12c98) has exited with code 0 (0x0).
> The thread 'Win32 Thread' (0x1154c) has exited with code 0 (0x0).
> The program '[76960] chrome.exe: Native' has exited with code 0 (0x0).
> It reads several threads exited and some notifications leaked. I don't know
> what those line of messages mean. Although I Chrome still works well to
> browse web pages, are there internal errors within Chrome?
> --
> Hua
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Does those VC output matter?

[Peter Kasting]

On Thu, Jul 9, 2009 at 7:45 PM, Hua Su  wrote:

> It reads several threads exited and some notifications leaked. I don't know
> what those line of messages mean. Although I Chrome still works well to
> browse web pages, are there internal errors within Chrome?
>

If you can build and run the code in Visual Studio, you can probably find
out (a) where that message gets printed and (b) what those notification
numbers correspond to, leading to (c) who's allocating them where.

But if not: these *could be* bugs but likely aren't (I rewrote all our uses
of notifications a month or two ago to use some auto-cleanup classes, but
there are a number of places where a singleton needs a notification).

PK

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Moving LayoutTests to src/third_party/WebKit

[Victor Wang]

If you DO NOT check out chromium source code, you can stop reading.
*What's the change?*
To reduce people's confusion about the LayoutTests directory, I am moving it
from *src/webkit/data/layout_tests/LayoutTests* to *src/third_party/WebKit/*
*LayoutTests*. For details of this request, see issue:
http://code.google.com/p/chromium/issues/detail?id=8765

The first patch  related to this
directory moving has been committed. The patch allows run_webkit_tests.py to
support both src/webkit/data/layout_tests/LayoutTests and
src/third_party/WebKit/LayoutTests directories

I have a pending patch  that actual
moves the directory. I am planning to move the directory next Monday after
Nicholas updates the buildbot gclient configurations.

*What do you need to do NOW?*
-. If you have LayoutTests as part of your client or don't care the size of
your working copy, you DO NOT need to do anything *now*.
-. If you excluded LayoutTests from your client and want continue to exclude
them, please add the following line to custom_deps section in your .gclient
file:
 "src/third_party/WebKit/LayoutTests": None,

For example, if you have an old .gclient like this:
   "custom_deps" : {
  "src/webkit/data/layout_tests/LayoutTests": None,
}

You need to change it to:
"custom_deps" : {
  "src/webkit/data/layout_tests/LayoutTests": None,
  "src/third_party/WebKit/LayoutTests": None,
 }

*What's Next?*
I will send out email once the patch is committed (planned for next Monday).
You may want sync your client and do following after sync: -. For those who
exclude LayoutTests in their client, remove the following line from .gclient
file. No need to have the old one anymore.
"src/webkit/data/layout_tests/LayoutTests": None,
You still need this line: "src/third_party/WebKit/LayoutTests": None,
-. For those who include LayoutTests in their client, manually remove
directory "src/webkit/data/layout_tests/LayoutTests" to save space.

Let me know if you have any questions.

Thanks,
Victor


*
*

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Theme re-encoding

[Avi Drissman]

I'm building an extension with a jpg source. If it gets the column then it's
an encoder issue, else decoder issue. I'll let you know as soon as I find
out.

Avi

On Fri, Jul 10, 2009 at 12:18 PM, Glen Murphy  wrote:

> This may be a PNGEncoder/Decoder bounce issue, and I don't think the
> base gfx unittests check the first vertical column of pixels.
>
> I landed some changes to PNGEncoder/Decoder in the last week, but it
> seems like the problem existed before then. Not sure whether the issue
> is that the first column gets corrupted, or whether everything gets
> right-shifted by one. I suspect the former, as our favicons go through
> this bounce process and we'd probably have noticed clipping there.
>
>
> On Fri, Jul 10, 2009 at 9:04 AM, Avi Drissman wrote:
> > We re-encode the pngs in themes. Somewhere in the the process we break
> them;
> > we're encoding them off by one pixel, so that we have a vertical line on
> the
> > left, one pixel wide, that's transparent. It isn't obvious on Windows
> (but
> > it is there; look for it!) but it's glaringly obvious on the Mac. I'm
> going
> > to look at it after I land the first pass at theming today, but can you
> > think of an obvious cause?
> >
> > Avi
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Theme re-encoding

[Glen Murphy]

This may be a PNGEncoder/Decoder bounce issue, and I don't think the
base gfx unittests check the first vertical column of pixels.

I landed some changes to PNGEncoder/Decoder in the last week, but it
seems like the problem existed before then. Not sure whether the issue
is that the first column gets corrupted, or whether everything gets
right-shifted by one. I suspect the former, as our favicons go through
this bounce process and we'd probably have noticed clipping there.


On Fri, Jul 10, 2009 at 9:04 AM, Avi Drissman wrote:
> We re-encode the pngs in themes. Somewhere in the the process we break them;
> we're encoding them off by one pixel, so that we have a vertical line on the
> left, one pixel wide, that's transparent. It isn't obvious on Windows (but
> it is there; look for it!) but it's glaringly obvious on the Mac. I'm going
> to look at it after I land the first pass at theming today, but can you
> think of an obvious cause?
>
> Avi
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Theme re-encoding

[Avi Drissman]

We re-encode the pngs in themes. Somewhere in the the process we break them;
we're encoding them off by one pixel, so that we have a vertical line on the
left, one pixel wide, that's transparent. It isn't obvious on Windows (but
it is there; look for it!) but it's glaringly obvious on the Mac. I'm going
to look at it after I land the first pass at theming today, but can you
think of an obvious cause?

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Meeting Notes From 2/9/2009 Now Posted!

[Mohamed Mansour]

An OWP seems an excellent thing. The thing is, there seems to be a
separation between internal Google developers and External developers. For
instance, we are not brought into the loop regarding some processes. I know
some of you use the mailing list to bring out ideas which is awesome, and do
a discussion. But many features just come out of nowhere. Would be cool to
know the path of what chromium is going to become (I know stability,
security, etc, etc), and our (external) voice would matter on how the
development / discussion is going. More involvement into the project would
be better than just being considered as a "programmer" only.
Some projects do weekly or biweekly quick online meetings on IRC. Its
productive because its like a quick weekly scrum where we discuss next
release goals etc etc. I don't know how Chromium is organized or if it
applies to us.

-- Mohamed Mansour


On Fri, Jul 10, 2009 at 12:48 AM, Brian Rakowski  wrote:

> We stopped posting because (a) the notes seemed not to be very useful out
> of context and (b) removing any Google-specific info, though it was minimal,
> was pretty labor intensive. I think it may be more productive to try to keep
> some public roadmaps and tasklists updated. Ian is working on creating an
> OWP roadmap that will be updated weekly with the status of the main areas of
> work. If that works out, perhaps we can do the same for other areas of the
> project. It seems like that would be more helpful and also more practical.
> Does that seem like it would meet the needs of the external developers? I
> want to make sure contributors have the info they need to be productive, but
> I don't want to create unnecessary work.
> Brian
>
>
> On Thu, Jul 9, 2009 at 8:10 PM, Evan Stade  wrote:
>
>>
>> Is it possible to continue posting these? external developers have
>> requested it.
>>
>> -- Evan Stade
>>
>>
>>
>> On Wed, Feb 11, 2009 at 10:18 AM, Peter Kasting
>> wrote:
>> > On Tue, Feb 10, 2009 at 6:19 PM, Glenn Wilson 
>> wrote:
>> >>
>> >> Meeting notes from February 9, 2009 are now posted on the Chromium
>> >> developer documentation:
>> >>
>> >>
>> http://sites.google.com/a/chromium.org/dev/developers/meeting-notes#02092009
>> >> Please contact me if you have any questions, and enjoy!
>> >
>> > It might be nice to post these on a blog somewhere, primarily so they
>> can be
>> > grabbed via RSS; various Mozilla meeting notes are posted this way.
>> >
>> > PK
>> > >
>> >
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Fwd: 1) Roll WebKit DEPS to 45685...

[Michael Nordman]

Fyi: In case your wondering why the webkit canary is red and DEPs have not
been rolled...

Forwarded conversation
Subject: 1) Roll WebKit DEPS to 45685...


From: ** 
Date: Thu, Jul 9, 2009 at 10:14 PM
To: j...@chromium.org
Cc: chromium-revi...@googlegroups.com, da...@chromium.org, j...@chromium.org


Reviewers: John Abd-El-Malek,

Message:
Crossing my fingers I don't see a sea of red in the webkit canary after
this. The try-bots are happy so far, comipiles on all and passes tests
on linux and mac, win is still chewing on the ui tests.

If the try succeeds I'm going to submit TBR, then look to see
wha'happens next... what could possible go wrong :)

John, please take a closer look at correctness here. I'm getting things
to build but thats about it.

Doh... the try just failed on windows!

test_shell_tests: PluginVisibility is RED



PluginTest.PluginVisibilty:
c:\b\slave\win\build\src\webkit\tools\test_shell\plugin_tests.cc(48):
error: Value of: file_util::CopyDirectory(plugin_src_,
plugin_file_path_, true)
 Actual: false
Expected: true



Guessing we failed to make a new copy because a previous copy is pinned
open.



Description:
1) Roll WebKit DEPS to 45685

This roll picks up changes to WebCore::Widget which make that a
RefCounted class.

2) Mods to plugin handling in our "glue" needed to recover from the
above



Please review this at http://codereview.chromium.org/149443

SVN Base: svn://chrome-svn/chrome/trunk/src/

Affected files:
 M DEPS
 M webkit/glue/webframeloaderclient_impl.h
 M webkit/glue/webframeloaderclient_impl.cc
 M webkit/glue/webplugin_impl.h
 M webkit/glue/webplugin_impl.cc



--
From: ** 
Date: Thu, Jul 9, 2009 at 10:35 PM
To: j...@chromium.org
Cc: chromium-revi...@googlegroups.com, da...@chromium.org, j...@chromium.org


Huh... surpsised that it shows up as a green try despite the RED plugin
test?

Not sure how to proceed honestly. Its not like I can revert the change
in webkit. So we can't pick any new webkit changes w/o coming to terms
with this change first.

Ouch... just ran a local build and got a crashing YouTube page when
navigating away...

For now I'm NOT rolling DEPs :(

--
From: *Michael Nordman* 
Date: Thu, Jul 9, 2009 at 10:46 PM
To: j...@chromium.org
Cc: chromium-revi...@googlegroups.com, da...@chromium.org


John, could use your help with this tomorrow please.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---