Ah, OK. That sounds like a good solution. I don't know how to implement
that, but maybe there is already a way.
-Darin
On Tue, Oct 20, 2009 at 1:54 PM, Nick Baum nickb...@chromium.org wrote:
The mocks also show a preview of all the fields when hovering over or
arrowing to one of the
So, granting my name in one field, grants the page access to my credit card
in another? :-/
-Darin
On Tue, Oct 20, 2009 at 12:46 PM, Ben Goodger (Google) b...@chromium.orgwrote:
The theory is that you would start typing in one of the fields, the
traditional autofill UI (dropdown) would appear
Greetings Chromium developers,
(Please feel free to ignore this e-mail if you are not interested in Windows
7.)
To celebrate the launch of Windows 7, I have written a document that
describes my prototype implementation that integrates Tab Thumbnails and
Aero Peek into Chromium. (My current
Hi Darin,
On Thu, Oct 22, 2009 at 2:50 AM, Darin Fisher da...@chromium.org wrote:
Marshall,
For now, can you just use NPObject to access the DOM? See WebBindings for
implementation of NPRuntime methods.
Long term, I am interested in reflecting the full DOM via the WebKit API,
but I don't
Hi Hironori,
Thanks for researching this topic. On generating thumbnails, I wrote
chrome/browser/tab_contents/thumbnail_generator which tries to get the
most up-to-date thumbnail images for all tabs (except ones that
haven't ever been shown) with minimal performance overhead. The code
hasn't
OK, sounds good.
Thanks for your patience.
-Darin
On Thu, Oct 22, 2009 at 7:09 AM, Marshall Greenblatt magreenbl...@gmail.com
wrote:
Hi Darin,
On Thu, Oct 22, 2009 at 2:50 AM, Darin Fisher da...@chromium.org wrote:
Marshall,
For now, can you just use NPObject to access the DOM? See
We need to come up with a way, if we also want to implement omnibox-style
inline autocomplete for web page autofill. (a separate bug).
-Ben
On Wed, Oct 21, 2009 at 11:52 PM, Darin Fisher da...@chromium.org wrote:
Ah, OK. That sounds like a good solution. I don't know how to implement
that,
On Thu, Oct 22, 2009 at 9:39 AM, Ben Goodger (Google) b...@chromium.orgwrote:
We need to come up with a way, if we also want to implement omnibox-style
inline autocomplete for web page autofill. (a separate bug).
Passing comment: This would be really cool but potentially a lot of work
Right. I am just wanting to match the inline behavior... using the omnibox
these days I tend to notice when I have to down arrow into things to
complete, so it's definitely a pain point for in-page autocomplete.
-Ben
On Thu, Oct 22, 2009 at 9:56 AM, Peter Kasting pkast...@google.com wrote:
On
On Wed, Oct 21, 2009 at 10:09 PM, Lei Zhang thes...@chromium.org wrote:
Hi Linux folks,
This is a kind reminder to check the return values from GTK functions.
Every time you put the unchecked result from, say,
gtk_file_chooser_get_filename() into a FilePath or std::string, you
risk a
Hi all,
At its last meeting the jank task force discussed improving
responsiveness of the spellchecker but we didn't come to a solid
conclusion so I thought I'd bring it up here to see if anyone else has
opinions. The main concern is that we don't block the IO thread on
file access. To this end,
It seems like loading into memory will result in more predictable access
times for the initial set of words that get spellchecked (up to the point
where the memory-mapped file would have been entirely paged in). If you
combine this with my memory purger code that will (hopefully) result in the
There's also option 3)
Pre-fault the mmap()ed region in the file thread upon dictionary
initialization.
On Linux at least, that may give you better behaviour than malloc() + read()
in the event of memory pressure.
Cheers
Chris
On Thu, Oct 22, 2009 at 1:39 PM, Evan Stade est...@chromium.org
If you plan to read the entire file, mmap()ing it, then faulting it in will
be slower than read()ing it, at least in some Linux versions. I never
pinned down exactly why, but I think the kernel read-ahead mechanism works
slightly differently.
--
Steve
On Thu, Oct 22, 2009 at 2:02 PM, Chris Evans
On Thu, Oct 22, 2009 at 2:02 PM, Chris Evans cev...@chromium.org wrote:
There's also option 3)
Pre-fault the mmap()ed region in the file thread upon dictionary
initialization.
On Linux at least, that may give you better behaviour than malloc() +
read() in the event of memory pressure.
On
On Thu, Oct 22, 2009 at 1:39 PM, Evan Stade est...@chromium.org wrote:
Hi all,
At its last meeting the jank task force discussed improving
responsiveness of the spellchecker but we didn't come to a solid
conclusion so I thought I'd bring it up here to see if anyone else has
opinions. The
On Linux what about mmap() and then madvise() with MADV_WILLNEED? [or
posix_fadvise() with POSIX_FADV_WILLNEED on the file descriptor).
-scott
On Thu, Oct 22, 2009 at 2:06 PM, Steve Vandebogart vand...@chromium.org wrote:
If you plan to read the entire file, mmap()ing it, then faulting it in
On Thu, Oct 22, 2009 at 2:22 PM, Brett Wilson bre...@chromium.org wrote:
On Thu, Oct 22, 2009 at 1:39 PM, Evan Stade est...@chromium.org wrote:
Hi all,
At its last meeting the jank task force discussed improving
responsiveness of the spellchecker but we didn't come to a solid
On Thu, Oct 22, 2009 at 2:22 PM, Brett Wilson bre...@chromium.org wrote:
This doesn't help on Mac where we want to use the system spellchecker.
FYI, we got a patch to use the system spellchecker on Linux as well.
http://code.google.com/p/chromium/issues/detail?id=24517
I should probably ping
It's been awhile since I looked at this, but the email I was able to dig up
suggests that madvise is no faster than faulting in the mmap()ed region by
hand. However, using posix_fadvise should give the same speeds as read()ing
it into memory. IIRC though, posix_fadvise will only read so much in
Faulting it in by hand is only helpful if we're right! If we're
wrong, it could evict other stuff from memory to support a feature
which a user may not use until the memory is faulted back out anyhow.
[From the rest of the thread, though, it sounds like maybe we should
just fix hunspell to be
+1 on moving spell to the renderers.
We can memory map in the browser and map again the in renderers.
Hopefully read-only.
We eliminate the sync ipc and do not increase the memory usage.
On Oct 22, 2:42 pm, Steve Vandebogart vand...@chromium.org wrote:
It's been awhile since I looked at this,
2009/10/22 Hironori Bono (坊野 博典) hb...@chromium.org
How to treat resize events of a browser window?
The biggest problems of my current prototype are caused by my prototype
that doesn’t handle resize events of a browser window. (Figure 4 may be
acceptable. But, I think Figure 5 is
Probably a bit off topic at this point, but but your response confuses me
- MADV_WILLNEED and POSIX_FADV_WILLNEED will bring the pages into ram, just
like faulting in mmap()'ed pages by hand, or read()ing it into memory. In
my experience, read() and fadvise() are faster than mmap()+faulting
WILLNEED says Hey, OS, I think I'm going to look at these pages soon,
get yourself ready, but the OS could implement them as a nop, and can
do it async. If memory is under pressure the system can do less, if
memory is clear it can do more. Actually reading the data into memory
blocks and
That is the intention of the interface yes, but all Linux implementations
I've seen actually go and read what ever you say you will need. Of course
with a few exceptions like actually being out of memory.
--
Steve
On Thu, Oct 22, 2009 at 3:06 PM, Scott Hess sh...@chromium.org wrote:
WILLNEED
26 matches
Mail list logo
