Tag Archives: about:flags
The latest Chromium open source builds are now at version 14, proving that perhaps version numbers in the Chrome ecosystem are indeed irrelevant. I would love to say that is the case, but it seems that with every new version we see a new feature or tweak that necessitates having numbers to keep track of everything that is going on.
One new feature we’re seeing in these Chromium builds is something called Preload Instant Search under the “about:flags” experimental section that appears when you type into the Omnibox. There is a continued effort to make searching even faster than ever before within the Omnibox with this new setting.
According to the Chromium projects site, Preload Instant Search allows the search page to preload even before a user starts to type a query. This reduces latency by making sure that the page is ready to go well before the intention to search has even been initiated – it starts the process whenever the Omnibox is clicked on.
Does that sound fast enough for you?
We’re seeing an increased amount of activity in the graphics department when it comes to Chrome. I’m aware of this because there are now two new “about:flags” experiments with the newest builds of Chromium: override software rendering list, and GPU compositing on all Pages.
Instead of using software rendering, the first new flag using GPU-provided capabilities in order to increase overall performance. Using this flag is a welcome replacement from using the command line “–ignore-gpu-blacklist” that allows usage with whatever hardware and drivers your machine has loaded. However, the one drawback may be chronic crashes as a result.
For the GPU compositing on all pages, this is a feature that Google has long been working on and has decided to enable in experiments as it will benefit the video tag in HTML5 as well as make page loading more efficient when dealing with large blocks of data. Want to learn more about GPU compositing? Check out this Chromium document that will give you all of the information you need.
Are we going to be seeing some great new graphical apps and games coming to Chrome soon as a result of some of this work?
via Chrome Story
When Google Instant was first unveiled to the masses, it was given a mixed reception. But at this point it appears that Instant has become another indispensible way to get to Google Search queries as fast as possible. It became a part of Chrome after version 9 of the browser was releaed, bringing it right inside the Omnibox for easy access.
I have noticed that the most recent Chromium builds are showing a new experimental feature in the “about:flags” section called Restrict Instant to Search.
By disabling this, only your searches are brought up below the Omnibox. Google is testing a variation of the feature perhaps because some of the results that display are coming up as an undesired result. This may be because of bad history matching, which was actually suppposed to be addressed in another experimental feature. It is also possible that nonessential URLs were just popping up in the Instant queue – ever noticed that?
Whatever the reason, it’s probably best that Google Instant has its own degree of settings that users can then dial up or down how they see fit. Sure, it’s adding another menu to a series of menus in Chrome but this one is probably worth it to Google since the key element to the company’s success is happy browsing.
Would you like more options that you can toggle on or off in Google Instant?
The newest builds of Chromium (here if you want to download) include a new experimental feature that is in the “about:flags” menu you can access by putting that text into the Omnibox. It’s called Run PPAPI Flash in the renderer process.
This new PPAPI will be used for running Native Client securely, and is why it has been added to Chromium’s experiments. In February, a new Native Client SDK was released that supported Pepper for developers to work on.
This is all in a goal of running Native Client in a secure fashion. It’s important that plugins don’t have any sort of elevated security privileges since that could result in problems down the line seeing as Native Client has direct access to hardware resources.
Are you developing with the Native Client SDK?
The latest builds of the Chromium browser are showing a new feature that can be enabled: add grouping to tab context menu. This is yet another feature that increases the functionality of Chrome’s tabs, and is something that attempts to rival what Firefox has done in its newest release, Firefox 4.
A common problem in modern browser is simply too many tabs. How do we better organize tabs when there are so many of them open that you cannot see what each individual one has in it? Firefox’s Panorama tries to confront this problem by offering an integrated visual interface as well as a way to group tabs by subject or website.
The tabs context menu is what you see when you right click on a tab. With this new feature enabled, you can see that there are some new options available
The overall look of the new tab page in Chromium is being changed, possibly to reflect an addition of touch capabilities. You can see the new look in this screenshot taken from a recent Chromium build with the “Experimental new tab page” switched on in “about:flags”. The main differences appear to be larger icons, a toggle system for multiple pages of app and a garbage can to get rid of unused icons.
This may be an indication that Google wants Chrome to offer touch for hardware devices. A hybrid gadget that entails both a laptop and a tablet may be in the works, but most computers like that are priced somewhat high. I’m not sure that the price point of Chrome OS will allow for a device like that, at least not in the near future.
One of the most challenging things about this is making the operating system work with both touch and a mouse. Designers must find a balance between the two and there are nuances to consider when doing this. Nevertheless, a product like the Samsung Sliding 7 would be a great fit for Chrome OS.
Would you buy a hybrid Chrome OS device?
The newest (or freshest, whichever way you say it) builds of Chromium are now coming with two new experimental features that previously required command line flags. By going to “about:flags” in the Omnibox, you can see there is now an “FPS counter” and “Focus on existing tab on open” in the list of options that you can turn on.
The FPS counter will allow you to gauge how well hardware acceleration when it is on by showing you the frames per second. Looking at some of the technical documents on the Chromium site suggests that this is to be used with composited render layer borders. If one of our esteemed developers/readers can tell us how to use it in the comments, that would be appreciated. Thanks for your feedback in advance.
The focus existing tab is a useful feature when you have a ton of tabs open. I have this problem all the time. Instead of Chromium opening a page, if you already have it loaded in a tab it will instantly switch to that tab. This one’s a keeper, at least for me, so hopefully it will be added to Chrome at some point.
So this is being implemented likely to test its compatibility with Native Client. It’s also possible that it’s being used to test Chromoting, another experimental feature in about:flags that doesn’t work unless you are on the dev team for Chromium.
Along with the recently changed “about:flags” Omnibox UI, a new experimental feature has come to the newest builds of Chromium. It’s called Enable Better Omnibox History Matching, and we’re going to suspect that the description is fitting enough when it says “enables substring and multi-fragment matching within URLs from history”.
Judging by this Chromium bug report, there have been issues with the Omnibox not returning the right results. It looks like for some users whenever they enter in some terms the box returns Google Search results over history. That’s probably because if you just enter in a few letters of a query, the Instant Search just kicks in as opposed to looking through your history.
The latest available builds of Chromium feature a striking difference from the older versions. With so many experimental flags available in “about:flags” Omnibox menu, the Chromium team has grayed out those that are not enabled and kept white those that are currently enabled.
These experiments are an easier way to toggle them on than having to use command line switches. There area a ton of command line switches available for experimental Chrome features, but it’s clear that when these move to the “about:flags” menu that a lot of people are likely working on that feature.
Take Native Client or Remoting as an example. These two features are important to Chrome OS’s development, and while to regular users they don’t do a whole lot right now, they will have an impact on the future.
Do you use any of the “about:flags” features, and what do you think about the UI change?
The newest builds of Chromium feature a Chrome Experiment via “about:flags” that I have not seen before: composited render layer borders. When I first looked at this, I assumed it must have something to do with the increased use of graphical capabilities being added into Chrome, and I was right.
According to the Chromium documentation regarding WebKit rendering basics, a RenderObject is associated with a RenderLayer. The purpose of these layers is to allow content to overlap each other as they are composited. The problem, however, is that oftentimes these layers are either semi-transparent or not visible at all.
The ability to use the option for experimental location features has arrived as an option that can be entered into Chromium’s “about:flags” option menu. This feature’s description was a bit wordy, so I stacked the text on top of itself in order for it to fit into your screen.
This allows developers to work with geolocation paired with their extensions. And the reference to operating system location APIs? Sounds like something that would be prepped for a mobile OS like Chrome OS.
Regardless, Google’s planning on making geolocation coupled with mobile an integral business going forward. Consider the rumored acquisition of daily deals site Groupon and the movement of Marissa Meyer, formally VP of search products, into heading the geographic and local services are of the company.