177 captures
29 Apr 2017 - 10 Apr 2026
Jun
JUL
Aug
25
2017
2018
2019
success
fail
About this capture
COLLECTED BY
Collection:
Twitter Outlinks
This is a Collection of URLs (and Outlinked URLs) extracted from a random feed of 1% of all Tweets.
TIMESTAMPS
The Wayback Machine - https://web.archive.org/web/20180725012032/https://blog.chromium.org/2011/05/
Chromium Blog
News and developments from the open source browser project
Chrome Developer Tools: Put JavaScript memory under control
Friday, May 27, 2011
Modern web applications are becoming increasingly complex. To achieve functionality previously only available in desktop applications, they often comprise many frameworks glued together. As a result, memory usage by an application can grow unexpectedly. That’s why it is important to keep memory usage under control from the moment you start building it. In this post, we will cover four tools in Google Chrome that can help you understand how your application makes use of JavaScript memory.
The simplest one is the built-in
Task Manager
. It is available under
> Tools > Task Manager. The “JavaScript memory” column isn't visible by default, but you can turn it on via the context menu [1]:
The numbers are updated in the real time.
If you’d like to visualise memory usage over time, try the
Memory Graph
of Chrome Developer Tools’
Timeline panel
. To start using it,
open Developer Tools
, switch to the Timeline panel, and click on the “Memory” item. After you start capturing Timeline events, the graph starts updating itself:
The most functional tool in controlling JavaScript memory usage and finding leaks is the new powerful
Heap Profiler
available in
Chrome Dev Channel
. To get a heap snapshot, open the Profiles panel in Developer Tools and press the “Take heap snapshot” button:
Snapshots contain every object from the JavaScript heap, so you can explore them in detail and find out how much memory every object of your application consumes. The heap profiler also offers the following features:
snapshots diffing
grouping objects by constructor
calculating retained sizes of objects
showing dominators tree
revealing paths to GC roots or window objects
In addition, the heap profiler takes into account native DOM nodes, and allows you to uncover DOM-related memory leaks.
It is also possible to measure how much JavaScript memory is currently used from within the page itself. You can sample values from the
performance.memory
window property at different points of your application lifetime. Please note, that the property does not report anything, unless you run Chrome with
--enable-memory-info
command-line argument.
For a more complete reference on working with the Chrome Developer Tools heap profiler, check out the
tutorial
.
[1]: How to invoke the context menu in the Chrome Task Manager:
Windows: Right click on any part of the grid;
Linux: Right click on the grid itself;
Mac: Ctrl+Right click on column headers
Posted by Mikhail Naganov, Software Engineer
WebP in Chrome, Picasa, Gmail With a Slew of New Features and Improvements
Friday, May 20, 2011
Since we
announced
WebP
, a new image format based on WebM technology and the VP8 codec, we’ve been working hard with the open web community to improve and enhance it. Today we are happy to share news about a few new features and expanded support for WebP.
New Features
WebP's compression algorithms have been significantly improved while remaining completely
compatible with the previous releases. We hope the quality of a few sample images in the new gallery will
delight you
.
On the decoding side, we have integrated a fancy upsampler. Fancy upsampling reduces the pixelation of strong edges. You can see this feature when you zoom in, for example on a
WebP image with red edges
converted from this PNG original:
Original image in PNG format
Without fancy upsampling: strong stair-like pattern
With fancy upsampling: smoother edge
We also introduced the ability to incrementally decode the data as your computer downloads it from the web, a feature that allows the browser to display images without having to wait for the whole file to download. This feature is already enabled in Chrome 12.
On the encoding side, to further improve quality, we focused on segmenting the picture into areas with similar compressibility. For each of these segments, we tune the amount of compression and filtering differently, and bits are redistributed where they are most useful. Take for instance the image reproduced below [1]:
The easy segment contains lot of disparate signals and can be compressed more than the difficult one, which will be assigned more bits. In this example, the encoder only used two segments. By using even more segments (up to four), WebP is now able to retain many of the original
details
of the image [2]. This is in contrast to the frequent
ringing artifacts
one can clearly
see in JPEG
images.
The uneven distribution of bits between difficult and easy area is controlled in the new encoder using the
-sns
parameter, short for Spatial Noise Shaping. Its value can be set from 0 to 100 (0 meaning OFF) and with a default of 80. Note that when you enable SNS,
PSNR
may be degraded, but the overall visual quality is much improved.
We’ve added simple encoding and decoding example binaries to the
libwebp library
. In addition, we’ve added JNI support that allows Java programs to decode WebP images. Next up is transparency, also known as Alpha channel; we’re experimenting with it
now
and planning to add it to the next stable version of the codec. In parallel, we continue to improve the codec’s speed and will release a complete specification for the metadata format.
Increased adoption
WebP is now natively supported in Chrome and
Opera
. Google products including Gmail and Picasa Web Albums, have also added support to WebP so you can share, send and receive WebP images. WebP support is coming to AppEngine. In addition,
Google Instant Previews
now store images in WebP to reduce their storage needs.
Users that want to manipulate WebP images can now do so using software developed by the community including
Pixelmator
,
ImageMagick
, the
WebP format plugin
for Photoshop and the
Java VP8 decoder
. The open-source community has also contributed support for Mac OS X with
MacPorts packages
, Linux
Debian
,
OpenSUSE
and
Gentoo
packages and the
Apache HTTP Server
. On Windows, users who want to view WebP images natively, can download the
WebP codec
. This codec brings WebP support to such software as Microsoft Office 2010, Windows Media Center and Photo Edit.
The new features,
quality improvements
and increased adoption of WebP get us excited about its future. As always, we’re looking for more feedback as well as code contributions from the community. Let us know on the
mailing list
how your experiments are panning out and what new features you’d like to see in the future.
Image credits:
[1]: "Kayaker at Ekstremsportveko 2010, Voss". Image Author: Kjetil Birkeland Moe. Reproduced with permission of the author.
PNG source
, and
Blog post
by author with comparison of JPEG and WebP.
[2]: A storm at Pors-Loubous,
Plogoff
,
Finistère
, France. Image Author: Henri Camus. Permission: CC-BY; CC-BY-1.0. Source:
http://commons.wikimedia.org/wiki/File:A_storm_at_Pors-Loubous.jpg
Posted by Richard Rabbat, Product Manager and Pascal Massimino, Software Engineer
ChromeVox: Built-In Spoken Feedback For Chrome OS
Thursday, May 19, 2011
Cross posted at the
Google Code
blog
We recently unveiled
ChromeVox
— a built-in screen reader for Chrome OS — during Google I/O 2011. This is an early developer beta that is designed to help authors of web applications come up to speed with platform accessibility on Chrome OS.
ChromeVox is built as a Chrome extension — this means that unlike most accessibility software, it is built using only web technologies like HTML5, CSS and Javascript. As the built-in accessibility solution for Chrome OS, it can help users with special needs access modern web apps, including those that utilize
W3C ARIA
(Access to Rich Internet Applications) to provide a rich, desktop-like experience.
ChromeVox leverages two of Chrome's experimental extension APIs, the
experimental.tts API
for cross-platform text-to-speech, and the experimental.accessibility API that lets an extension listen for accessibility events in Chrome's menus and toolbars. In turn, ChromeVox exposes a
simple screen reader API
to web developers who wish to further customize the ChromeVox user experience. Thus, within your application, you can:
Automatically generate spoken messages and earcons.
Set ChromeVox to synchronize with your application's current focus.
ChromeVox also comes with an interactive
online tutorial
that demonstrates how users of spoken feedback interact with webpages. Examples range from static content to interactive applications. You can test these same navigation techniques within your own applications to quickly verify users can reach all portions of your application using the keyboard and obtain meaningful feedback. You can then annotate your application with the necessary ARIA properties and other accessibility enhancements to ensure that blind and visually impaired users gain complete access to your application. Please see our
Google I/O 2011 talk
for more.
Details on enabling accessibility in Chrome OS can be found on the
Accessibility help page
, and the Chrome extension is available for download from
our Wiki page
. For now, ChromeVox is targeted at end-users on Chrome OS, but it may also prove a useful tool to web developers using Chrome on all major platforms. We welcome your feedback via our Open Source project website at
http://google-axs-chrome.googlecode.com
.
Posted by T.V. Raman, Research Scientist
SSL FalseStart Performance Results
Wednesday, May 18, 2011
Last year, Google’s Adam Langley, Nagendra Modadugu, and Bodo Moeller proposed
SSL False Start
, a client-side only change to reduce one round-trip from the
SSL
handshake.
We implemented SSL False Start in Chrome 9, and the results are stunning, yielding a significant decrease in overall SSL connection setup times. SSL False Start reduces the latency of a SSL handshake by 30%
1
. That is a big number. And reducing the cost of a SSL handshake is critical as
more
and
more
content providers move to SSL.
Our biggest concern with implementing SSL False Start was backward compatibility. Although nothing in the SSL specification (also known as TLS) explicitly prohibits FalseStart, there was no easy way to know whether it would work with all sites. Speed is great, but if it breaks user experience for even a small fraction of users, the optimization is non-deployable.
To answer this question, we compiled a list of all known https websites from the Google index, and tested SSL FalseStart with all of them. The result of that test was encouraging: 94.6% succeeded, 5% timed out, and 0.4% failed. The sites that timed out were verified to be sites that are no longer running, so we could ignore them.
To investigate the failing sites, we implemented a more robust check to understand how the failures occurred. We disregarded those sites that failed due to certificate failures or problems unrelated to FalseStart. Finally, we discovered that the sites which didn’t support FalseStart were using only a handful of SSL vendors. We reported the problem to the vendors, and most have fixed it already, while the others have fixes in progress. The result is that today, we have a manageable, small list of domains where SSL FalseStart doesn’t work, and we’ve added them to a list within Chrome where we simply won’t use FalseStart. This list is public and posted in the chromium source code. We are actively working to shrink the list and ultimately remove it.
All of this represents a tremendous amount of work with a material gain for Chrome SSL users. We hope that the data will be confirmed by other browser vendors and adopted more widely.
1
Measured as the time between the initial TCP SYN packet and the end of the TLS handshake.
Posted by Mike Belshe, Software Engineer
Chrome Web Store in 41 languages and In-App Payments
Friday, May 13, 2011
Since we
launched
the Chrome Web Store, we’ve been working on several new improvements. Today, we’re happy to share our progress towards making the Chrome Web Store available to all Chrome users worldwide and the availability of Google In-App Payments for web app developers.
First, as we
announced
at Google I/O, the
In-App Payments API
is now available for app developers. We demo-ed the way
Graphicly
uses this API and
Angry Birds
announced that they will use it to offer users the Mighty Eagle for in-app purchase on the web. Integrating the API into your app is as simple as adding a single line of code and provides a frictionless user experience for making purchases within the app. We hope to gather
feedback
on the API before making it fully available this summer.
Second, the Chrome Web Store is now available in 41 languages. This is our second step towards launching
Chrome Web Store in 15 additional countries
. Developers interested in targeting international users can now go to the Chrome Web Store and publish free apps in these countries in preparation for launch. We will also support publishing paid apps in selected countries later this year.
Localizing your apps will expose them to many more users and allow them to be featured in the local Chrome Web Store homepages. We hope this expanded functionality will allow you to create brand new international apps or to
localize your existing apps
.
If you have additional questions, please take a look at our
FAQ
or join our
developer discussion group
.
Posted by Alexandra Levich, Product Manager
Remote debugging with Chrome Developer Tools
Monday, May 9, 2011
Google Chrome Developer Tools (or DevTools) front-end is implemented as an HTML + CSS + JavaScript web application. It uses a serialized message channel in order to communicate with the inspected page. Originally, we were working on establishing this serialized asynchronous interaction in order to bring DevTools front-end out of the inspected page process. But once it was done, we could take it even further and run DevTools front-end outside the browser. Here is how you can give it a try:
Run the Chrome instance that you will be debugging remotely with the remote debugging
command line switch
:
chrome.exe --remote-debugging-port=9222 --user-data-dir=remote-profile.
It is essential that you use a different instance of Chrome for the remote session and that is why we run it with the
--user-data-dir
argument.
Navigate to the pages you intend to debug.
Now run a regular (client) Chrome instance and navigate to
http://localhost:9222
there.
You will see a number of links that will bring you to the remote debugging sessions for the corresponding pages. Click them and enjoy debugging your Chrome pages over the wire:
We implemented the remote debugging infrastructure in the WebKit repository (or as we say “upstream”), so that other WebKit port owners could expose remote debugging capabilities with a minimal effort. See more information on remote debugging in our
WebKit blog post
. For more information on the remote debugging and Chrome Developer Tools in general, see our
documentation page
.
Posted by Pavel Feldman, Software Engineer
Updating JavaScript Benchmarks for Modern Browsers
Wednesday, May 4, 2011
Benchmarks are incredibly important for influencing the direction of JavaScript engines. Over the past two years, JavaScript has gotten dramatically faster across all major browsers, particularly in areas that popular benchmarks measure. As it turns out, browser developers are a competitive bunch. However, as JS engines get faster, benchmarks must evolve in order to keep pushing them in the right direction.
We’ve been constantly updating our
V8 benchmark suite
to force us to get faster in areas that are important to web developers. We’ve fixed bugs and added new tests for
regular expressions
and
memory management
. We’re very focused on JavaScript performance, so we scrutinize our benchmark carefully to make sure that it’s as useful a measuring stick as possible.
The two other widely cited JS benchmarks are
SunSpider
from Apple, and
Kraken
, a new benchmark from Mozilla.
SunSpider was one of the first suites of tests, first appearing in 2007. It’s done a lot to help improve JS engines, but many of the tests in the suite are less relevant to the web in 2011. Even for the more relevant tests, JavaScript has gotten so fast that many finish in only a few milliseconds. This just isn’t long enough to figure out which engine is faster--a golf cart and a Tesla will finish a 10-foot race in nearly the same time.
To make the benchmark more meaningful, we’ve experimented by making the race longer by running each of the tests in SunSpider 50 times consecutively. While repeating a trivial test many times isn’t a great solution, it does provide an opportunity for some optimization. With this change, the results begin to reflect Chrome’s true performance. It’s more than 30% faster on the SunSpider suite overall and up to 4x faster on some of the individual tests.
Kraken, a more modern benchmark, is in better shape. Unfortunately, the
canonical
version of the benchmark has not been updated to reflect all the latest changes which address at least
one important bug
. As a result, the benchmark is less useful and has even (mis)led us to spend time making some
irrelevant optimizations
in Chrome. To help us focus on the right things, we’re now testing the latest version of Kraken built directly from Mozilla’s source code repository.
We’re posting a
modified version of SunSpider
and the
latest version of Kraken
to make it easy to run the benchmarks in your own browser and compare results.
Posted by Mike Belshe, Software Engineer
Adding more yellow to the Mac color scheme
Monday, May 2, 2011
We’re pleased to announce that
Google Chrome Canary for Mac
is now available.
When we
released
Google Chrome Canary for Windows last year to help get more feedback on crashes from the bravest Chrome users, we weren’t sure how many people would tolerate using a completely untested build of Chrome. Since then, hundreds of thousands of Windows users have contributed to Chrome’s development by using the Canary and sending us valuable feedback. Thanks!
The Mac version of Google Chrome Canary follows the same philosophy: it automatically updates more frequently than the Dev channel, and does not undergo any manual testing before each release. Because we expect it to be unstable and, at times, unusable, you can run it concurrently with a Dev, Beta, or Stable version of Google Chrome. Your Canary data remains separate, but if you
set up Sync
in each version of Chrome that you use, you can automatically continue using the same set of bookmarks, extensions, themes, and more.
If you’re a Mac user and want to help us test the bleeding edge, or if you just want to see our icon in shades of yellow,
take it for a spin!
Posted by Mark Mentovai, Software Engineer
Labels
accessibility
1
benchmarks
1
beta
8
blink
1
chrome apps
3
Chrome Frame
1
chrome web store
26
chromeframe
3
chromeos
3
chromium
3
cloud print
1
dart
8
devtools
11
extensions
23
gdd
1
googlechrome
12
html5
11
incognito
1
javascript
3
linux
2
mac
1
mobile
2
na
1
native client
8
New Features
5
octane
1
open web
2
releases
2
rlz
1
security
30
spdy
2
ssl
2
v8
5
web intents
1
webaudio
3
webgl
7
webkit
5
webp
5
webrtc
4
websockets
5
webtiming
1
Archive
2018
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2010
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2009
Dec
Nov
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2008
Dec
Nov
Oct
Sep
Feed
Google
on
Follow @ChromiumDev
Give us feedback in our
Product Forums
.
