[chromium-dev] Re: Is creating a custom PDF rendering backend a sound idea?
On Mon, May 18, 2009 at 05:46, Evan Martin wrote: > WebKit (but not the Chromium port) already targets Cairo via GTK, and > Cairo supports PDF output. I'm not sure anyone's using it for PDF > output yet though. Midori uses it. 'midori -s http://path.to/website' will output a pdf of the site. http://www.twotoasts.de/index.php?/pages/midori_summary.html Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Improving power usage
Hello, I'm a Summer of Code student working with Dean. My interests are the Linux port, specifically ensuring Chromium behaves well on low spec machines. So far I've spent my 'summer' (it's winter here in Australia) on the ARM port of Chromium. As of the recent v8 gyp changes, the tree can build for ARM (and thumb, for a binary that's around ~25% smaller) and I've used it to browse on real hardware; the Beagleboard, an OMAP3 based ARM board with 128MB of RAM. I've been looking into what to work on next. I'd like to investigate the possibility of reducing the amount of work being done when running on battery. On my laptop I send SIGSTOP to Firefox when I'm not using it, to save battery without losing state. This saves me 1 Watt when running Gmail in Firefox 3, or around 8% of the system power draw on my Thinkpad X300. As we're multi process with Chrome we could instead suspend any background renderers, plugin and extension processes without affecting the foreground tabs. Some obvious gotchas - when tabs share renderers, we can't indiscriminately stop background tabs - we can't just sigstop the renderer process, as the browser will think it has crashed Other things to look at would be timers that fire 'too often', and pausing animated content such as gifs and flash. Wakeups are not too bad, but any savings will mean longer lasting batteries: 28.4% (187.4) firefox-3.5 : hrtimer_start_range_ns (hrtimer_wakeup) 4.1% ( 26.9)chrome : hrtimer_start_range_ns (hrtimer_wakeup) 2.3% ( 15.0)chrome : ep_poll (process_timeout) (Powertop output of Firefox 3 vs Chromium trunk, one tab running Gmail, on Ubuntu Karmic) Perhaps we could run a powertop bot, that monitors an idle session with a few tabs opened to catch any regressions with timers. I plan to spend some time looking into this. Feedback and suggestions would be appreciated. Cheers, Joel --~--~-~--~~~---~--~~ 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: Improving power usage
On Tue, Jul 14, 2009 at 01:52, Evan Martin wrote: >> I've used it to browse on real hardware; the Beagleboard, an OMAP3 >> based ARM board with 128MB of RAM. > > Wow, impressive. How much do you think multi-process hurts us? The full story is 128MB of RAM + 128MB of swap on a slow (class 4) SD card. Multi-process changes the game, at least wrt memory. Normally once you hit the memory ceiling the system is unresponsive until the OOM killer takes out something (on the OLPC XO this would often be X, losing the entire session). With Chrome, opening a 3rd tab results in the new renderer instantly crashing (if it's even starting?), leaving you restricted to two tabs but free to continue browsing in those two. So IMO, multi-process makes us fail in much nicer ways :) But we will hit that memory ceiling sooner due to the overheads of being multi-process. The ~500Mhz CPU is pegged when rendering, but the system goes near-idle once drawing has finished. Scrolling takes it back up to 100%. I haven't used it much, but will do more often going forward now that I can build using the tree. On the topic of the ARM build, it would be great if we could have a buildbot doing cross compiles. I filed a bug at http://crbug.com/16321, is there anything else I can do to follow that up? > One piece to look at is the code that calls SetProcessBackgrounded(), > which on Windows marks the process as one that can be paged out but on > Linux is not implemented. I don't know how it decides it's ok to do > that, but it'd be good logic to examine. I'll take a look. My email was kicked off after discovering the SystemMonitor class, which I understand is only used for switching on and off high-res timers on Windows. These both sound like good switches for enabling efficient behaviour. > I think it'd be pretty interesting to fully suspend background tabs, > but doing it safely is likely tricky. For example, imagine a page > that has Javascript that is driving a Flash plugin playing background > music. I wonder if it would be possible to detect that sound is coming from a tab. Perhaps it's not worth it, as the case of IM in the background tab will be really hard to detect in a generic fashion. The only reliable way the browser will discover that a tab is inactive is for the user to tell it. Right click -> "Pause this tab"? This would be a UI win over my current `pgrep firefox | xargs kill -STOP` :) >> Other things to look at would be timers that fire 'too often', and >> pausing animated content such as gifs and flash. > > Even for stuff like gifs that don't have audio, you could imagine a > page with a very long animated gif, where I might switch away from the > tab and expect it to be farther along when I come back. > > Here's an idea: when a page is in the background don't let it repaint. > That means when you switch to it you'll have to wait for it to > repaint, but maybe that's an ok tradeoff. (Maybe we do this already.) So we do this for GIFs. Can anyone tell me if background tabs re-paint themselves? If not, I'll add it to the TODO. > A final idea is simply looking at performance overall. > We haven't yet looked at even a profile and we very well could be > doing a lot of unnecessary work. > For example, I believe the renderer spams the browser repeatedly with > "set tooltip" messages as you move the mouse around. I think I saw a > bug filed suggesting we could have the renderer only send the message > if the tooltip changed. Maybe that's not enough work to waste much > battery, though. > This is more generic, but perhaps more realistic. This would be best discovered by looking at IPC traffic going past? Thanks for the reply, Joel --~--~-~--~~~---~--~~ 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: Improving power usage
On Tue, Jul 14, 2009 at 03:09, Craig Schlenter wrote: > I've mentioned this to Joel off-list but in case anyone else is interested, > I have code that runs background tabs at lower scheduling priorities > on linux. Thanks. Are you able to post the newer version you mentioned? > Tweaks to /etc/security/limits.conf are necessary to make it work though > (to grant priority raising abilities). If we're just tweaking the priority level between 0 and 20 a normal user will have no worries. It's only when we try to take it below 0 that more capabilities are needed. $ renice +1 31404 31404: old priority 0, new priority 1 $ renice -1 31404 renice: 31404: setpriority: Permission denied $ renice +3 31404 31404: old priority 1, new priority 3 $ renice +1 31404 31404: old priority 3, new priority 1 OTOH, renicing isn't really going to help my quest to end unnecessary background work, it's just going to make sure the foreground gets more CPU share. Joel --~--~-~--~~~---~--~~ 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: Improving power usage
On Tue, Jul 14, 2009 at 00:53, Dan Kegel wrote: > It'd be nice if users didn't have to do that... > does HTML 5 specify any kind of low power idle state for applications? > Ideally when the screen blanks, we'd want all the apps to go > into some kind of low power state, wouldn't we? It would be great if Gmail (or similar) could ask Chrome if it's in the background, and do less work until it comes back into focus. Mmm and use Android style tickles to wake up when new email arrives... >> Perhaps we could run a powertop bot, that monitors an idle session >> with a few tabs opened to catch any regressions with timers. > > I like that idea a lot. Cool! I need inside help to make that happen, are you the person I can poke? I've spent today looking into collecting powertop numbers. The latest version of gnome-power-manager has a powertop-like tab, and it's scraping it's data from devicekit-power. Karmic has both of these, I thought Jaunty had devkit-power but looking again I might have been mistaken. So once we have a system that has devicekit-power, we can use a tool[1] from the source tree to dump stats: $ ./devkit-power -w Total wakeups per minute: 462 Wakeup sources: userspace:0 id:12, interrupts:216.0, cmdline:interrupt, details:i8042 userspace:0 id:4082, interrupts:91.0, cmdline:kernel-ipi, details:Rescheduling interrupts userspace:0 id:30, interrupts:64.5, cmdline:interrupt, details:PCI-MSI-edge iwlagn userspace:0 id:28, interrupts:43.0, cmdline:interrupt, details:PCI-MSI-edge i915 userspace:0 id:14, interrupts:15.0, cmdline:interrupt, details:ata_piix userspace:1 id:5971, interrupts:8.9, cmdline:/home/shenki/chrome/chrome, details:hrtimer_start_range_ns (hrtimer_wakeup) userspace:1 id:29472, interrupts:8.5, cmdline:/usr/lib/firefox-3.5/firefox-3.5, details:hrtimer_start_range_ns (hrtimer_wakeup) Next is collecting them in the same manner that other perf stats are collected... Joel [1] http://cgit.freedesktop.org/DeviceKit/DeviceKit-power/tree/tools --~--~-~--~~~---~--~~ 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: Linux developers: you need to read this
On Wed, Jul 15, 2009 at 02:12, Adam Langley wrote: > * build chrome_sandbox I think the defines got messed up somewhere... http://codereview.chromium.org/149667 fixes it for me. Joel --~--~-~--~~~---~--~~ 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: Can someone compile this patch for me?
Hello, On Mon, Aug 3, 2009 at 11:35, Anand Mistry wrote: > Hi all, > I don't have the resources (disk space + tools) to compile my patch under > Windows and OSX, so can someone on this list quickly try it before I post it > for review? And on Windows, do a sanity check on the about:memory page. > Patch is attached. The linux memory reporting code is something I have been working on recently, thanks for taking it further. If you upload the patch to codereview.chromium.org, one of the chromium devs can submit it to the tryservers which build for all supported platforms. This process is also used for code review rather than submitting patches to the mailing list. http://dev.chromium.org/developers/contributing-code Cheers, Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] jankfs
When I first got Chromium going on the beagleboard it was slow. I believe the the main slowdown is due to the limited RAM (128MB), but another factor was the slow disk I/O due to the root fs being held on a cheap SD card. To simulate the beagleboard's slow I/O on my SSD-equipped laptop, I wrote 'jankfs'; a small hack to a bind mounting FUSE filesystem that inserts a sleep before each read() and write(). This can be specified at mount time, the delay being either constant number of microseconds or a multiplier for the read or write size. Some other ideas that we had were to have some operations randomly fail, or have the delays be random, but I have not implemented those yet. To gauge the effect of slow IO I ran startup_tests on a amd64 Linux system and using a amd64 Release build. There are three runs: normally, a constant delay of 10us read delay, and a constant 10us write delay. The numbers come from Dan K's scripts (thanks Dan!). normal: median meanmax stddev warm: t= 110 259 3079 663 cold: t=1224 1223 1274 32 warm: t= 114 252 2910 625 cold: t=1246 1252 1505 77 Jankfs, write-delay-absolute=10: median meanmax stddev warm: t= 384 520 3074 601 cold: t= 375 377399 12 warm: t= 388 544 3512 698 cold: t= 377 373390 10 Jankfs, read-delay-absolute=10: median meanmax stddev warm: t= 388 518 3005 585 cold: t= 376 376400 10 warm: t= 397 528 3072 599 cold: t= 371 375401 16 The cold startup are skewed as I suspect FUSE has extra caching that /proc/sys/vm/drop_caches does not control. The warm startup numbers show a clear slowdown. To use jankfs: - Install the bindfs deb from https://launchpad.net/~shenki/+archive/ppa/ - Add 'user_allow_other' to /etc/fuse.conf, and add your user to the fuse group. For non-Ubuntu (or if your Ubuntu version is too old): - Download bindfs from http://bindfs.googlecode.com/files/bindfs-1.8.3.tar.gz - Apply http://jms.id.au/~shenki/jankfs_1.patch - ./configure && make - the binary at src/bindfs can be run in-place without installing To create a mount with a constant (ie, without depending on the write size) delay of 10 microseconds: $ bindfs --write-delay-absolute=10 src/chromium/ /tmp/test/ --~--~-~--~~~---~--~~ 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: jankfs
On Wed, Aug 19, 2009 at 19:38, Ben Laurie wrote: >> warm: t= 397 528 3072 599 >> cold: t= 371 375 401 16 >> >> >> The cold startup are skewed as I suspect FUSE has extra caching that >> /proc/sys/vm/drop_caches does not control. The warm startup numbers >> show a clear slowdown. > > I'm puzzled - even if there's skew due to extra caching, how can this > make warm _slower_ than cold? > I'm confused as well. The 'cold' run calls fdatasync() then posix_fadvise() with POSIX_FADV_DONTNEED on the binary before running the test. This is appears to be the only difference between cold and warm. I'm running 2.6.31-rc6 from Ubuntu Karmic. The tests run like this: 1. run startup test - 'warm' results collected here 2. fdatasync() and fadvise() 3. run startup test - 'cold' results collected here as fadvise is only advice - the kernel is not required to drop the file from memory - it's still cached. A run of the tests with the order reversed ...doesn't change the results :/ So much for that theory. jankfs uses usleep() to slow down the read() and write() filesystem calls. Perhaps that's interacting in unexpected ways? Joel --~--~-~--~~~---~--~~ 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: jankfs
On Wed, Aug 19, 2009 at 22:15, Evan Martin wrote: > Just to eliminate any doubt, you can manually as root > echo 3 > /proc/sys/vm/drop_caches > to force the caches to be dropped. I have been doing this. > I don't know how slow I'd expect an SD card to be, but this random > page I found (search for "latency") has it between 1 and 3ms, which is > still much faster than a disk. > http://www.symbian-guru.com/welcome/2008/09/sandisk-ultra-8gb-microsd-better.html Latency might be that fast but the chrome binary is ~30MB and with slow SD cards doing 1-4MB/s the read speed matters. > One more point of confusion: we shouldn't really do any writing on > startup -- how does that affect anything? From your patch it seems > you always call usleep(); maybe usleep(0) still has an effect? Maybe > you could try measuring with jankfs with no delay parameters? You hit the nail on the head. Setting no delay, or a write delay of 15000us (which is still pretty small), gives the same results as above. So my numbers are a illustration of the effects of FUSE and/or bindfs. I was using sleep() for the first try at doing 'jankfs'. I only changed to usleep when re-doing it to send some results to the list (I decided that I needed more precision, this line of thinking was wrong, but the results initially didn't scream that to me so I went ahead). Going back to sleeping for numbers of seconds puts the delay back into the correct order of magnitude. Delays in seconds, startup time in ms. 'sync; echo 3 > /proc/sys/vm/drop_caches' between each run. 100s 30s 10s 1s 0sno jankfs Cold1174094774427406168201719644473 Warm1139164377823888147831389411125 Delta 3493 39663518 2037 3302 33348 graphed: http://tinyurl.com/nvh5nw The strange result is that cold startup goes faster small for small delays (<10 seconds). This could be a side effect of FUSE or bindfs. Or it could be related to what you mentioned with sleeps being beneficial for disk accesses. --~--~-~--~~~---~--~~ 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: Chromium Linux 64-bit
On Fri, Aug 21, 2009 at 01:14, Dean McNamee wrote: > > The v8 team did some amazing work this quarter building a working > 64-bit port. After a handful of changes on the Chromium side, I've > had Chromium Linux building on 64-bit for the last few weeks. This is awesome. You should be knighted. Cheers, Joel --~--~-~--~~~---~--~~ 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: Chromium / Google Summer of Code
On Sat, Aug 22, 2009 at 07:31, Lei Zhang wrote: > > With the Google Summer of Code program winding down, I'm curious how > our GSoC participants are doing. Can the students and their mentors > share their experiences? (Assuming you're all done with evaluations > and all that.) My project was 'Forging a better Cr on Linux', and Dean was my mentor. I had an eye on doing performance/memory usage work motivated by my attempts to run Chromium on the Beagleboard; an ARM system with 128MB of RAM. Chromium works and you can come along to OSDC (http://2009.osdc.com.au) for my talk "There's something on my ARM" for all the details :) I didn't get as much done as I would have liked as I was attending classes and sitting exams throughout my "Summer" of Code, a downside of being a student from the southern hemisphere. This means I'm going to stick around the project to continue working on things I'm interested in. (For my record as much as anyone else) here is a summary of the patches I wrote, in chronological order: == Scale backing store cache size == This would scale the number of DIBs stored based on the system RAM. It's since been replaced by a more complex algorithm. == Set process name on Linux == This was to help distinguish the renderer from the browser (and the zygote, which was just appearing at the time). It was reverted as it broke the UI tests which iterate over the process name. I did not resubmit as 'ps f' provides the same information for less lines of code. == Jankfs == An idea Dean had; write a FUSE filesystem to simluate slow and unreliable storage. See http://groups.google.com/group/chromium-dev/browse_thread/thread/59b0440255c87ed3 == ARM build == The tree had built for ARM at some point in the past but had since bitrotted. I went through building a toolchain, and then a root filesystem, and found 3 gcc ICE (internal compiler errors) on the way. I then made a bunch of changes in working towards building and running Chromium on the Beagleboard: * Hide x86 assembly in the seccomp and chroot sandboxes from the ARM build * A Skia build fix * v8 patch for targeting the ARMv7 Cortex-A8 (found on the beagleboard) * Most significantly, re-wrote v8.gyp to make cross-compiling possible For instructions on building see http://code.google.com/p/chromium/wiki/LinuxChromiumArm == Memory usage in task manager on Linux == Calculates the memory usage of each process. This is committed and working, but the API needs to be re-worked to be less Windows-like before about:memory is ready for Linux. See http://codereview.chromium.org/159777 == Fix proxy settings for Gnome >=2.26 == Newer versions of Gnome use a different binary name, this made the "Change proxy settings" button work for both. == Add ctrl+w accelerator to close bookmark manager for linux == == Fix PR_ImplodeTime for Linux x64 == This was one of the last patches to make the chrome tree compile for x64 without patches, building on Dean's work. Beware the 2038 bug. == One liners == * gcc-4.3 / 4.4 build fixes * gitignore updates * window icons According to the logs I wrote 22 patches. Despite having been around open source projects for a number of years, Chroimum's development process taught me many new things. Having code review for all changes made was a new to me, and line by line review is great at ensuring I got detailed feedback. Dean's mentoring was the most valuable part of the experience. He was great at answering questions and explaining the concepts I was not familiar with. Having the ability to communicate via IM made this very easy and I would encourage mentors and students to follow this setup in future years. Thanks to Dean for mentoring me, and everyone else who reviewed and committed my patches. Cheers, Joel --~--~-~--~~~---~--~~ 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: private VM field on the about:memory page
Hello, On Mon, Aug 24, 2009 at 22:48, Anand Mistry wrote: > Also, in general, how useful is knowing VM size considering it's not > necessarily corollated with actual memory usage? I chatted with a few people when doing doing my memory work. Based on this, I think we should look at two criteria for what to display on the Linux port: - what we can measure accurately - information that will be useful to the user I don't think there is any use in showing the user the VM size. If a dev needs it, he can use top(1). Also, by not trying to display the exact same columns as windows does, hopefully there will be fewer uninformed comparisons of the numbers between platforms. Cheers, Joel --~--~-~--~~~---~--~~ 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: Cross-compiling on ARM
On Tue, Aug 25, 2009 at 17:06, Lei Zhang wrote: > Only x86 and x86_64 were supported at the time gold was originally > released. Does it support ARM yet? Yes, gold can link ARM binaries as of a few months ago. I have used it in my cross compiling. Ubuntu is shipping it it in Karmic (for ARM, as well as the x86 architectures) in the binutils-gold package. Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Valgrind + 64bit binaries
Hello, While attempting to run x64 unit_tests under valgrind I am hitting an error: vex: priv/guest_amd64_toIR.c:14600 (disInstr_AMD64_WRK): Assertion `sz == 2 || sz == 4' failed. vex storage: T total 4600074960 bytes allocated vex storage: P total 816 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). ==25306==at 0x3802ADC4: report_and_quit (m_libcassert.c:145) ==25306==by 0x3802AE29: panic (m_libcassert.c:227) ==25306==by 0x3802AEA2: vgPlain_core_panic_at (m_libcassert.c:232) ==25306==by 0x3802AEC1: vgPlain_core_panic (m_libcassert.c:237) ==25306==by 0x380433F2: failure_exit (m_translate.c:674) ==25306==by 0x380B2AE8: vex_assert_fail (main_util.c:220) ==25306==by 0x38117CCE: disInstr_AMD64_WRK (guest_amd64_toIR.c:14600) ==25306==by 0x3811BB42: disInstr_AMD64 (guest_amd64_toIR.c:16116) ==25306==by 0x380C0BA1: bb_to_IR (guest_generic_bb_to_IR.c:229) ==25306==by 0x380B135C: LibVEX_Translate (main_main.c:420) ==25306==by 0x380410B5: vgPlain_translate (m_translate.c:1517) ==25306==by 0x38062F68: vgPlain_scheduler (scheduler.c:844) ==25306==by 0x3808AF74: run_a_thread_NORETURN (syswrap-linux.c:91) Has anyone had success valgrinding 64bit binaries? Cheers, Joel --~--~-~--~~~---~--~~ 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: [linux] user feedback one month in
On Mon, Sep 21, 2009 at 12:22, Elliot Glaysher (Chromium) wrote: > > On Sun, Sep 20, 2009 at 7:43 PM, Evan Martin wrote: >> - CSS occasionally lost while browsing >> My response: I think I've seen this too, but I had been assuming it's >> site glitches. Does this ring any bells for anyone? > > I see this at least twice a day on my home connection. A site will > load except for the corresponding CSS. There doesn't appear to be a > pattern to it. I see it occasionally too. While we're on vague bug reports, I often have images partially load and then stop, never to complete. It doesn't happen all the time, but I have seen it often enough to suspect something is up. Is there a way to see what's going on when this happens to perhaps narrow this down? I suspected both problems might be related to being 250ms+ away from the internet, but have no evidence to back that up. Joel --~--~-~--~~~---~--~~ 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: [linux] user feedback one month in
On Mon, Sep 21, 2009 at 15:02, Peter Kasting wrote: > You're referring to crbug.com/406. This is a nasty bug, but it doesn't kick > in until you're several megabytes into a resource, so I doubt it is the > cause of the "images partially load" issue. I'd agree, I've been seeing the images issue for a while now. I opened http://crbug.com/22470 and added more (still vague) details. Joel --~--~-~--~~~---~--~~ 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: [FYI] Build errors while building Chromium with gcc 4.4.
2009/11/2 Yuta Kitamura : > IIRC specifying 'gcc_version': '44' does the same thing as above. This might > be better than specifying 'no_strict_aliasing' directly. Ah, you bet me to it. You're right; gcc_version is used to only enable -fno-strict-aliasing when building v8. Joel --~--~-~--~~~---~--~~ 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: [FYI] Build errors while building Chromium with gcc 4.4.
2009/11/2 Hironori Bono (坊野 博典) :
> 1. Creating a file "~/.gyp/inclulde.gypi'.
> 2. Adding a following lines to the file.
>
> {
>'variables': {
> 'no_strict_aliasing': 1
>}
> }
If you're only building chrome, not the unit_tests target, you can
instead define gcc_version to 44. This is picked up in v8.gyp to
enable the appropriate flags, but leaves strict aliasing on for the
rest of chrome.
{
'variables': {
'gcc_version': 44,
}
}
I figure this is a better option as regressions will be caught as they
are introduced.
Joel
--~--~-~--~~~---~--~~
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: Multiple constrained windows
On Sun, Nov 8, 2009 at 16:48, Nico Weber wrote: > some pages try to show multiple http auth dialogs at the same time ( > one example is in http://crbug.com/26900 ). On linux, that happens to > work fine, but on OS X it doesn't. I could change the OS X code to > queue constrained windows and show only one window at a time per tab, > or I could do the same thing for all platforms by putting the code in > tab_contents. Any opinions out there? As a user of HTTP auth dialogs for proxy authentication on Linux, I would appreciate changing the behaviour to only showing the window once. In fact, it would be better if there was only one auth window shown for the entire browser, but this is unique to the http proxy case - you don't want it when it's only one site requesting authentication. Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: [chromium-dev] skia floating point
On Wed, Nov 18, 2009 at 05:23, Antoine Labour wrote: > That's really a question for the Android team, not Chromium... > As far as Chrome's use of Skia, if you compile for ARMv7, you'll get NEON > acceleration when available. Except that the tree won't build for ARM, because we don't have a buildbot, so it regresses all the time. I'm in the midst of fixing the latest round of issues (reviews have gone out, some have hit the tree). Who can I poke to get an ARM buildbot set up so that once the tree builds again it has a chance of staying that way? Joel -- 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: Building chromium for arm--erroring out
On Thu, Dec 10, 2009 at 05:14, Sofia Tahseen wrote: > /home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: > skipping incompatible > /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so > when searching for -lrt The errors are indicative of trying to link against libraries from a different platform. To confirm: check the output of $ 'file /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so I suspect it will tell you it's a symbolic link to /lib/librt.so.1, which itself is a symbolic link to /lib/librt-2.10.2.so - note these paths are relative to /, not to your sysroot directory. You have two slightly solutions - adjust the symlinks in sys-root/usr/lib so they point to the files in sys-root//lib - replace the smymlinks with the actual libraries, ie copy files from sys-root/lib to sys-root/usr/lib I would be happy to hear a neater solution for this, but the above worked for me. Cheers, Joel -- 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: Building chromium for arm--erroring out
On Fri, Dec 11, 2009 at 04:08, Sofia Tahseen wrote: > You are so right, Joel... I corrected my .so and now I could build the > chrome browser ...finally!! > I copied the whole /src/out/Release directory While it's not important, that is unnecessary. This directory contains all of the object code, you only need the final binary. Copying the following list of files should be sufficient, and save you some time: chrome chrome.pak libffmpegsumo.so resources/ locales/ chrome-wrapper > to my jaunty on the BeagleBoard(256MB RAM). I try to launch chrome through: > ./chrome > It starts up chrome, and then immediately kills chrome. I get an Illegal > Instruction. Jaunty targets the ARMv5 ISA, and you are building Chromium for ARMv7 (by including the armv7=1 flag). I suspect you need to do one of the following (not both): - run Karmic, which is built for ARMv7, on your BeagleBoard - omit the armv7=1 flag when building Chromium As a data point: I regularly build and run Chromium targeting thumb2 (armv7=1 arm_thumb=1) on my BeagleBoard (RevB, 128MB RAM) running Ubuntu Karmic. It starts and can browse in multiple tabs. Joel -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] ARM Buildbot
On Wed, Dec 16, 2009 at 08:11, Antoine Labour wrote: > We now have a buildbot for it (thanks bradn!), see > http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Arm And it's on the main waterfall too. Thanks! Joel -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Browser power use
Hello Chromium, Continuing with my interest in Chromium's effect on battery life I've been playing with an ARM build of Chromium on the BeagleBoard, with power instrumentation. I've taken power measurements showing Firefox and Chromium at cold start, warm start and loading Gmail. http://jms.id.au/wiki/TheresSomethingOnMyArm I'm currently working on getting kernel power management for the device working, which will give a better indication of how idle the system really is. With pm support the system on chip will power itself down when the system is truly idle, opposed to not doing much. Joel -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
