[chromium-dev] using gold for faster linking
gold is a new linker (coincidentally, written by engineers at Google) that is much faster than the standard binutils one. I wrote up some instructions on how to use it here: http://code.google.com/p/chromium/wiki/LinuxFasterBuilds Feel free to edit that it if I got any of my notes wrong, or add your own notes on building more quickly. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: LayoutTests results under Linux
> (Note: Running the layout tests currently requires changelist 11455,
> reapplying mmoss's revision 5567 which added lighthttpd binaries, and
> commenting out some cygwin specific stuff in http_server.py,
> specifically, the line "env['PATH'] = '%s;%s' %
> (PathFromBase('third_party', 'cygwin', 'bin'), env['PATH'])". I'm
> going to work on getting everything working out of trunk on an
> unmodified build next.)
I think everything needed to run the tests is on trunk now.
Michael
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---
[chromium-dev] LayoutTests results under Linux
The Linux team now has the entire LayoutTests running from start to
finish...and we don't do half bad for a first pass:
=> Tests we want to pass (10186):
4595 test cases (45.1%) Passed
5415 test cases (53.2%) Text diff mismatch
1820 test cases (17.9%) Simplified text diff mismatch
130 test cases (1.3%) Test timed out
24 test cases (0.2%) Test shell crashed
22 test cases (0.2%) No expected results found
=> All tests (10186):
4595 test cases (45.1%) Passed
5415 test cases (53.2%) Text diff mismatch
1820 test cases (17.9%) Simplified text diff mismatch
130 test cases (1.3%) Test timed out
24 test cases (0.2%) Test shell crashed
22 test cases (0.2%) No expected results found
(Note: Running the layout tests currently requires changelist 11455,
reapplying mmoss's revision 5567 which added lighthttpd binaries, and
commenting out some cygwin specific stuff in http_server.py,
specifically, the line "env['PATH'] = '%s;%s' %
(PathFromBase('third_party', 'cygwin', 'bin'), env['PATH'])". I'm
going to work on getting everything working out of trunk on an
unmodified build next.)
-- Elliot Glaysher
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---
[chromium-dev] Re: Quick and dirty chrome embedding test
Hi Brett, On Tue, Nov 18, 2008 at 2:27 PM, Brett Wilson <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 18, 2008 at 11:19 AM, Marshall Greenblatt > <[EMAIL PROTECTED]> wrote: > > > Thanks for your input, I think I understand now. Both the Windows > message > > loop and the chrome task queue co-exist in the MessageLoop class via > > Delegate and Dispatcher implementations. Chrome uses the Windows message > > loop as a means for managing the task queue (via WM_TIMER calls), so > there > > should be no need for me to post Windows messages directly to the UI > > thread. Instead, to call a Browser object method (like GoBack()) from a > > separate thread I should execute MessageLoopForUI::current()->PostTask() > > (which is itself thread-safe) to have the UI thread execute a method that > I > > provide, which would in turn make the Browser method call. > > Kind of. MessageLoopForUI doesn't give ui the UI message loop. It > gives you the current message loop assuming that it's a UI "type" of > loop. You'll have to track independently which message loop the UI > message loop is. We usually pass this information into the objects > that live on the secondary threads when they start. Am I correct in thinking that there's only one UI message loop per process (created in BrowserMain())? If so, I'd be curious to know why a pointer to the UI message loop isn't available from the global BrowserProcess instance. > > > Brett Thanks, Marshall > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
On Tue, Nov 18, 2008 at 3:16 PM, Brett Wilson <[EMAIL PROTECTED]> wrote: > That's what I was saying may or may not be worth it, and what the > decision really comes down to. OK. The change that I'm currently finishing up is, in essence, a more generalized form of the SkBitmap/CGImage converter we're already using in glue/image_decoder. I have a few loose ends to tie up, but it should remove the current sources of pain around images (and simplify things like cursor handling that also depend on them). I'll send it to you for review as soon as it's happy :-). --Amanda --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
On Tue, Nov 18, 2008 at 12:13 PM, Amanda Walker <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 18, 2008 at 2:05 PM, Brett Wilson <[EMAIL PROTECTED]> wrote: >> This is not platform-specific on any other architecture, and it >> doesn't need to be. The difference is that font and form control >> rendering have to be native for us to look correct. This is not the >> case for images or any other part of GraphicsContext. > > But font and form control drawing *use* GraphicsContext, which is what > prompted turning on PLATFORM(CG) in the first place. We can turn off > PLATFORM(CG), which resolves the type mismatches for images--but also > means forking FontMac, FontMacATSUI, and so on (a total of a dozen or > so files, last time I tried it) or upstream a patch that replaces a > lot of code like "CGContextRef cgContext = context->platformContext()" > with platform-specific macro (a type of patch that WebKit has been > resistant to so far, from what I've seen). That's what I was saying may or may not be worth it, and what the decision really comes down to. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Quick and dirty chrome embedding test
On Tue, Nov 18, 2008 at 11:59 AM, Marshall Greenblatt <[EMAIL PROTECTED]> wrote: > Hi Brett, > > On Tue, Nov 18, 2008 at 2:27 PM, Brett Wilson <[EMAIL PROTECTED]> wrote: >> >> On Tue, Nov 18, 2008 at 11:19 AM, Marshall Greenblatt >> <[EMAIL PROTECTED]> wrote: >> >> > Thanks for your input, I think I understand now. Both the Windows >> > message >> > loop and the chrome task queue co-exist in the MessageLoop class via >> > Delegate and Dispatcher implementations. Chrome uses the Windows >> > message >> > loop as a means for managing the task queue (via WM_TIMER calls), so >> > there >> > should be no need for me to post Windows messages directly to the UI >> > thread. Instead, to call a Browser object method (like GoBack()) from a >> > separate thread I should execute MessageLoopForUI::current()->PostTask() >> > (which is itself thread-safe) to have the UI thread execute a method >> > that I >> > provide, which would in turn make the Browser method call. >> >> Kind of. MessageLoopForUI doesn't give ui the UI message loop. It >> gives you the current message loop assuming that it's a UI "type" of >> loop. You'll have to track independently which message loop the UI >> message loop is. We usually pass this information into the objects >> that live on the secondary threads when they start. > > Am I correct in thinking that there's only one UI message loop per process > (created in BrowserMain())? If so, I'd be curious to know why a pointer to > the UI message loop isn't available from the global BrowserProcess instance. The BrowserProcess object is not threadsafe and can only be used on the UI thread. The UI thread could be stored, but it's worked fine to pass it when we need it. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
On Tue, Nov 18, 2008 at 2:05 PM, Brett Wilson <[EMAIL PROTECTED]> wrote: > This is not platform-specific on any other architecture, and it > doesn't need to be. The difference is that font and form control > rendering have to be native for us to look correct. This is not the > case for images or any other part of GraphicsContext. But font and form control drawing *use* GraphicsContext, which is what prompted turning on PLATFORM(CG) in the first place. We can turn off PLATFORM(CG), which resolves the type mismatches for images--but also means forking FontMac, FontMacATSUI, and so on (a total of a dozen or so files, last time I tried it) or upstream a patch that replaces a lot of code like "CGContextRef cgContext = context->platformContext()" with platform-specific macro (a type of patch that WebKit has been resistant to so far, from what I've seen). I'm happy to spend a day or so to perform that experiment if that'll be a useful reference point, but based on our initial porting effort, it doesn't actually remove any complexity in the port--it just pushes it around and forks more files. Allowing easy conversion between SkBitmaps and CGImages (a technique we already use, with good effect, since it can be done without copying the actual bits) seems a lot simpler to me over overall. For that matter, it might even be straightforward to write copy constructors that would let code pass them around interchangeably (as long as we make sure to keep track of who owns the pixel data). --Amanda --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Quick and dirty chrome embedding test
On Tue, Nov 18, 2008 at 11:19 AM, Marshall Greenblatt <[EMAIL PROTECTED]> wrote: > Hi Brett, > > On Tue, Nov 18, 2008 at 11:12 AM, Brett Wilson <[EMAIL PROTECTED]> wrote: >> >> On Tue, Nov 18, 2008 at 7:14 AM, Marshall Greenblatt >> <[EMAIL PROTECTED]> wrote: >> > Hi Brett, >> > >> > On Tue, Nov 18, 2008 at 9:56 AM, Brett Wilson <[EMAIL PROTECTED]> >> > wrote: >> >> >> >> On Tue, Nov 18, 2008 at 6:50 AM, Marshall Greenblatt >> >> <[EMAIL PROTECTED]> wrote: >> >> > Hi All, >> >> > >> >> > Is it safe to create (via Browser::Create*()) and/or access Browser >> >> > object >> >> > instances from multiple threads? In other words, I need to choose >> >> > one >> >> > of >> >> > the following options: >> >> >> >> No, the entire UI of Chrome is single-threaded and is not threadsafe. >> >> If you need things to access it from multiple threads, you will need >> >> to synchronize everything. >> > >> > Is there a thread-safe method equivalent to the PostMessage() WinAPI >> > call >> > for adding events to the browser MessageLoop? >> >> PostMessage should already be thread safe. > > Thanks for your input, I think I understand now. Both the Windows message > loop and the chrome task queue co-exist in the MessageLoop class via > Delegate and Dispatcher implementations. Chrome uses the Windows message > loop as a means for managing the task queue (via WM_TIMER calls), so there > should be no need for me to post Windows messages directly to the UI > thread. Instead, to call a Browser object method (like GoBack()) from a > separate thread I should execute MessageLoopForUI::current()->PostTask() > (which is itself thread-safe) to have the UI thread execute a method that I > provide, which would in turn make the Browser method call. Kind of. MessageLoopForUI doesn't give ui the UI message loop. It gives you the current message loop assuming that it's a UI "type" of loop. You'll have to track independently which message loop the UI message loop is. We usually pass this information into the objects that live on the secondary threads when they start. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Quick and dirty chrome embedding test
Hi Ben, On Tue, Nov 18, 2008 at 1:37 PM, Ben Goodger (Google) <[EMAIL PROTECTED]>wrote: > > Why are you creating a Browser object? What does that have to do with > embedding? > > -Ben Please review the reference implementation for a better understanding of how I'm currently using Browser objects: http://codereview.chromium.org/10973 Regards, Marshall --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
On Tue, Nov 18, 2008 at 11:02 AM, Amanda Walker <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 18, 2008 at 1:54 PM, Brett Wilson <[EMAIL PROTECTED]> wrote: >> No matter what we do each platform should have its own font and form >> control rendering. I don't think unifying these has ever been on the >> table. When I talk about unifying I mean the overall architecture. >> Each platform will have some of its own code to render fonts and form >> controls into the underlying buffer. > > Hmm, OK. Why are images different, then? I'm missing something--the > architecture's already unified--NativeImagePtr is just a WebKit > platform-specific type that's typedefed inconveniently at the moment. This is not platform-specific on any other architecture, and it doesn't need to be. The difference is that font and form control rendering have to be native for us to look correct. This is not the case for images or any other part of GraphicsContext. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Quick and dirty chrome embedding test
Hi Brett, On Tue, Nov 18, 2008 at 11:12 AM, Brett Wilson <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 18, 2008 at 7:14 AM, Marshall Greenblatt > <[EMAIL PROTECTED]> wrote: > > Hi Brett, > > > > On Tue, Nov 18, 2008 at 9:56 AM, Brett Wilson <[EMAIL PROTECTED]> > wrote: > >> > >> On Tue, Nov 18, 2008 at 6:50 AM, Marshall Greenblatt > >> <[EMAIL PROTECTED]> wrote: > >> > Hi All, > >> > > >> > Is it safe to create (via Browser::Create*()) and/or access Browser > >> > object > >> > instances from multiple threads? In other words, I need to choose one > >> > of > >> > the following options: > >> > >> No, the entire UI of Chrome is single-threaded and is not threadsafe. > >> If you need things to access it from multiple threads, you will need > >> to synchronize everything. > > > > Is there a thread-safe method equivalent to the PostMessage() WinAPI call > > for adding events to the browser MessageLoop? > > PostMessage should already be thread safe. Thanks for your input, I think I understand now. Both the Windows message loop and the chrome task queue co-exist in the MessageLoop class via Delegate and Dispatcher implementations. Chrome uses the Windows message loop as a means for managing the task queue (via WM_TIMER calls), so there should be no need for me to post Windows messages directly to the UI thread. Instead, to call a Browser object method (like GoBack()) from a separate thread I should execute MessageLoopForUI::current()->PostTask() (which is itself thread-safe) to have the UI thread execute a method that I provide, which would in turn make the Browser method call. I also found this document helpful in understanding the message system: http://dev.chromium.org/developers/design-documents/threading > > > Brett Thanks, Marshall > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
On Tue, Nov 18, 2008 at 1:54 PM, Brett Wilson <[EMAIL PROTECTED]> wrote: > No matter what we do each platform should have its own font and form > control rendering. I don't think unifying these has ever been on the > table. When I talk about unifying I mean the overall architecture. > Each platform will have some of its own code to render fonts and form > controls into the underlying buffer. Hmm, OK. Why are images different, then? I'm missing something--the architecture's already unified--NativeImagePtr is just a WebKit platform-specific type that's typedefed inconveniently at the moment. --Amanda --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
On Tue, Nov 18, 2008 at 10:44 AM, Amanda Walker <[EMAIL PROTECTED]> wrote: > > NativeImagePtr is a WebKit type, and is designed to be the platform's > native representation. We're all still fighting hidden assumptions > about what PLATFORM(XXX) flags mean. Skia and CG are graphics APIs, > but webkit (and chromium currently) presume that they are 1:1 with > platforms, which they aren't (so, as a result, NativeImagePtr gets > typedefed to CGImageRef instead of SkBitmap* by an accident of #ifdef > ordering). In the short term, I have a patch in flight that should > fix the NativeImagePtr compatibility, but fonts will no doubt present > the same problem, and will be much harder to solve (a "no significant > differences between platforms" approach will require a major overhaul > on all 3 platforms (well, maybe not Linux, since they don't have much > rendering code yet) to use something like Pango + FreeType + Cairo for > rendering instead of GDI, CG, or Gtk). No matter what we do each platform should have its own font and form control rendering. I don't think unifying these has ever been on the table. When I talk about unifying I mean the overall architecture. Each platform will have some of its own code to render fonts and form controls into the underlying buffer. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
NativeImagePtr is a WebKit type, and is designed to be the platform's native representation. We're all still fighting hidden assumptions about what PLATFORM(XXX) flags mean. Skia and CG are graphics APIs, but webkit (and chromium currently) presume that they are 1:1 with platforms, which they aren't (so, as a result, NativeImagePtr gets typedefed to CGImageRef instead of SkBitmap* by an accident of #ifdef ordering). In the short term, I have a patch in flight that should fix the NativeImagePtr compatibility, but fonts will no doubt present the same problem, and will be much harder to solve (a "no significant differences between platforms" approach will require a major overhaul on all 3 platforms (well, maybe not Linux, since they don't have much rendering code yet) to use something like Pango + FreeType + Cairo for rendering instead of GDI, CG, or Gtk). There are good arguments on each side of that, but if we're going to make that decision, we should do so with all of the costs and benefits we know about laid out so that we can make it rationally, rather than out of frustration that it makes a particular patch more complex. I started a design doc about this at the end of last week, at your suggestion; I'll put up a draft tonight or tomorrow that we can all use as a basis for that discussion (and for talking with the webkit folks, once we're all on the same page ourselves). --Amanda On Tue, Nov 18, 2008 at 12:35 PM, Brett Wilson <[EMAIL PROTECTED]> wrote: > > I just broke the build again with more NativeImagePtr problems. Right > now, this is making me feel much less like tolerating significant > differences between our Mac & Windows ports. > > Brett > > > -- --Amanda "Big Brother is hallucinating." --Elizabeth D. Zwicky --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Quick and dirty chrome embedding test
Why are you creating a Browser object? What does that have to do with embedding?
-Ben
On Tue, Nov 18, 2008 at 6:50 AM, Marshall Greenblatt
<[EMAIL PROTECTED]> wrote:
> Hi All,
>
> Is it safe to create (via Browser::Create*()) and/or access Browser object
> instances from multiple threads? In other words, I need to choose one of
> the following options:
>
> A) Synchronize all Browser object creation and access via the main process
> thread ("single thread model" in COM parlance)
> B) Allow each Browser object to be created and managed by its own separate
> thread ("single-threaded apartment model" in COM parlance), or
> C) Allow any thread to create and/or access any Browser object at any time
> ("multi-threaded apartment model" in COM parlance)
>
> For background information on COM threading models see these documents:
> http://msdn.microsoft.com/en-us/library/ms809971.aspx
> http://msdn.microsoft.com/en-us/library/9t07f8b4(VS.80).aspx
>
> Thanks,
> Marshall
>
>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
I just broke the build again with more NativeImagePtr problems. Right now, this is making me feel much less like tolerating significant differences between our Mac & Windows ports. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Quick and dirty chrome embedding test
On Tue, Nov 18, 2008 at 7:14 AM, Marshall Greenblatt <[EMAIL PROTECTED]> wrote: > Hi Brett, > > On Tue, Nov 18, 2008 at 9:56 AM, Brett Wilson <[EMAIL PROTECTED]> wrote: >> >> On Tue, Nov 18, 2008 at 6:50 AM, Marshall Greenblatt >> <[EMAIL PROTECTED]> wrote: >> > Hi All, >> > >> > Is it safe to create (via Browser::Create*()) and/or access Browser >> > object >> > instances from multiple threads? In other words, I need to choose one >> > of >> > the following options: >> >> No, the entire UI of Chrome is single-threaded and is not threadsafe. >> If you need things to access it from multiple threads, you will need >> to synchronize everything. > > Is there a thread-safe method equivalent to the PostMessage() WinAPI call > for adding events to the browser MessageLoop? PostMessage should already be thread safe. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: SCons build of chrome on Windows
You have guessed that Steven meant http://build.chromium.org/buildbot/waterfall/waterfallbuilder=Chromium%20XP%20(scons)&builder=Webkit%20(scons)&reload=30 On Mon, Nov 17, 2008 at 2:15 AM, Steven Knight <[EMAIL PROTECTED]> wrote: > SCons build of chrome on Windows has (somewhat) recovered from the webkit > merge. This means you should be able to test the SCons-generated Visual > Studio files with something that actually builds chrome.exe and the various > test executables. > There are still test failures, which usualy indicate some subtle build > difference I've overlooked: > > > http://hae14.jail:8010/waterfall?builder=Chromium%20XP%20(scons)&builder=Webkit%20(scons)&reload=30 > > The Webkit failures were introduced towards the end of last week. The > Chrome test failures may have been masked for a while. > > These are the sorts of things that take me a while to track down but are > often obvious to those of you with more knowledge of the underlying code. > If you kick the tires and can spot any fixes, it would be tremendously > helpful. > > --SK > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Quick and dirty chrome embedding test
Hi Brett, On Tue, Nov 18, 2008 at 9:56 AM, Brett Wilson <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 18, 2008 at 6:50 AM, Marshall Greenblatt > <[EMAIL PROTECTED]> wrote: > > Hi All, > > > > Is it safe to create (via Browser::Create*()) and/or access Browser > object > > instances from multiple threads? In other words, I need to choose one of > > the following options: > > No, the entire UI of Chrome is single-threaded and is not threadsafe. > If you need things to access it from multiple threads, you will need > to synchronize everything. Is there a thread-safe method equivalent to the PostMessage() WinAPI call for adding events to the browser MessageLoop? > > > Brett Thanks, Marshall > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Quick and dirty chrome embedding test
On Tue, Nov 18, 2008 at 6:50 AM, Marshall Greenblatt <[EMAIL PROTECTED]> wrote: > Hi All, > > Is it safe to create (via Browser::Create*()) and/or access Browser object > instances from multiple threads? In other words, I need to choose one of > the following options: No, the entire UI of Chrome is single-threaded and is not threadsafe. If you need things to access it from multiple threads, you will need to synchronize everything. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Quick and dirty chrome embedding test
Hi All,
Is it safe to create (via Browser::Create*()) and/or access Browser object
instances from multiple threads? In other words, I need to choose one of
the following options:
A) Synchronize all Browser object creation and access via the main process
thread ("single thread model" in COM parlance)
B) Allow each Browser object to be created and managed by its own separate
thread ("single-threaded apartment model" in COM parlance), or
C) Allow any thread to create and/or access any Browser object at any time
("multi-threaded apartment model" in COM parlance)
For background information on COM threading models see these documents:
http://msdn.microsoft.com/en-us/library/ms809971.aspx
http://msdn.microsoft.com/en-us/library/9t07f8b4(VS.80).aspx
Thanks,
Marshall
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
On Mon, Nov 17, 2008 at 11:37 PM, Brett Wilson <[EMAIL PROTECTED]> wrote: > Native_theme is a little more tricky since there is some desire to > eventually unify theme drawing with the rest of WebKit. If we did > that, it would probably be undesirable from WebKit's perspective to > have this file in our directory with our funny rules. We can choose to > duplicate the code in this case (I think only a fraction of it is > actually needed by the app layer, since it uses actual native controls > for most thing), so this wouldn't be as bad as it may sound. That seems reasonable; I agree with Ojan that theming web content and theming the app UI should be completely separable (even if they end up calling the same system libraries). > There are other options: > (1) Move the files in question to Skia. This would be bad, presuming we want to unfork Skia at some point (rather than maintaining our own snapshot). > (2) Duplicate the files in both places. I don't like this just on general principles :-). > (3) Move the files to port but include headers in base/gfx that > include those files, so chrome code doesn't have to directly include > files from webkit, which looks a little odd. This doesn't strike me as being as bad as a dependency in the other direction, but I think it's better to completely separate the two even if there's a bit of overlap. Another alternative would be a standalone "theme utils" library that both sets of code could use, but it would raise the same question about where it should live. --Amanda --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
