On Thu, Oct 22, 2009 at 2:55 PM, cpu wrote:
> +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.
This sounds awesome to me, I'm sold.
PK
--~--~--
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 wrote:
> WILLNEED says "Hey, OS, I th
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 actua
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
everyt
2009/10/22 Hironori Bono (坊野 博典)
> 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 unacceptable for many use
+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 wrote:
> It's been awhile since I looked at this, but the email I was
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 mo
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 a
On Thu, Oct 22, 2009 at 2:30 PM, Evan Martin wrote:
> On Thu, Oct 22, 2009 at 2:22 PM, Brett Wilson 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/issue
On Thu, Oct 22, 2009 at 2:22 PM, Brett Wilson 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 the original upload
On Thu, Oct 22, 2009 at 2:22 PM, Brett Wilson wrote:
>
> On Thu, Oct 22, 2009 at 1:39 PM, Evan Stade 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 bri
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 wrote:
> If you plan to read the entire file, mmap()ing it, then faulting it in will
> be slower th
On Thu, Oct 22, 2009 at 1:39 PM, Evan Stade 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 main concern i
On Thu, Oct 22, 2009 at 2:02 PM, Chris Evans 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 Windows, I beli
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
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 wrote:
>
> Hi all,
>
>
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
dic
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,
On Wed, Oct 21, 2009 at 10:09 PM, Lei Zhang 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 browser process cra
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 wrote:
> On Thu, Oct 22, 2009 at
On Thu, Oct 22, 2009 at 9:39 AM, Ben Goodger (Google) wrote:
> 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
depending on the underl
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 wrote:
> Ah, OK. That sounds like a good solution. I don't know how to implement
> that, but maybe there is
OK, sounds good.
Thanks for your patience.
-Darin
On Thu, Oct 22, 2009 at 7:09 AM, Marshall Greenblatt wrote:
> Hi Darin,
>
> On Thu, Oct 22, 2009 at 2:50 AM, Darin Fisher wrote:
>
>> Marshall,
>>
>> For now, can you just use NPObject to access the DOM? See WebBindings for
>> implementation o
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 been
Hi Darin,
On Thu, Oct 22, 2009 at 2:50 AM, Darin Fisher 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 want to rush
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 prototy
26 matches
Mail list logo
