are there any web browsers out there with full support for javascript, and can render html normally? I wouldn't need anything like flash or java applets, but full support for fancy javascript would be nice for getting through fancy web sites and such. If one doesn't exist, I think I might try to make one, and shoot for 5 - 15MB of ram usage.
yeah, I've got time on my hands, so I'm down. Thanks! I've actually been using edbrowse, which is interesting. It is basically using ed to browse the internet.
uzbl is interesting, it's simple and extensible, but unfortunately the code quality is rather low, it's being developed by some skiddies and has multiple, pretty devastatingly exploitable vulnerabilites
>>1
5-15MB of RAM usage on what? If it's 5-15MB with a 10MB page that would be very impressive. If it's 5-15MB with a 1KB page, that's not great.
>>5
uzbl uses WebKit, which means around the same amount of bloat as Chome and Safari, except with a different interface.
You could try adding JS to NetSurf.
I'll admit I've been writing a web browser myself too, in C. I've gotten not much more than the HTML tokenizer done, because it's a time-killing thing. If only there were 64KB web browser competitions...
5-15MB of RAM usage on what? If it's 5-15MB with a 10MB page that would be very impressive. If it's 5-15MB with a 1KB page, that's not great.
Hmm, that's a good point, I haven't thought about the sizes of the pages, or the images and all that. I know I could do better than firefox though. A multithreaded wget with https, with a html parser, and a simple renderer for positioned text and images, and a graphical interface, with a java script interpreter can't be that intense.
You could try adding JS to NetSurf.
I will check it out. I know there are quite a few browsers out there that work decently well but have no support for javascript. I would aim for full support of html4, or whatever. I know it is massive, but once the engine is together, it would just be filling the blanks. It might take a year of on and off work on weekends, but it would get done eventually. I might even go for html5 if I could leverage external libraries and keep overhead down, but that would be optional.
I'll admit I've been writing a web browser myself too, in C. I've gotten not much more than the HTML tokenizer done, because it's a time-killing thing. If only there were 64KB web browser competitions...
Lets start one on prog! grand prize for the one that can view youtube from a TI-83!
It is automatic memory management which means it MUST use some sort of garbage collection. You can still keep memory usage sane by implementing exponential collection strategy: start off with a small limit like 1MB. Once memory usage hits 1MB, run GC. You should have free space left over. If you don't, then double the limit to 2MB and allocate. Keep going until 4MB gets filled up, then run GC. If memory usage drops below 1/4 the current limit after any GC run then shrink (release memory back to OS).
That would be convenient for a copying collector. It might be better to use a generational collector, and when you garbage collect and find that you no longer have enough memory for the live set, allocate a new generation.
There is also mark and sweep style, which can be nice since you don't need to copy memory around. You do need to sweep through the entire heap to free the unreachable objects though, rather than just the live set. Here is lua's implementation:
why not? jpegs and pngs aren't that big, and seem to decode fast. If space for images was really a concern, one could use lower resolutions for the rendered images, but I don't think it would be a problem. And javascript isn't that complex.. And the dom is just a tree structure.
Name:
Anonymous2011-11-23 3:41
>>16
You know what, I actually just did some quick calculations in how much memory would be required to represent these pages in memory and it seems that 5-15mb per page is quite achievable.
Name:
Anonymous2011-11-23 4:05
this is currently the 3rd google result for "low resource web browser"
cool, that's encouraging. I'd probably only support one active tab at a time. Or maybe tabs could be supported, but the unviewed pages would be written explicitly to disk in a format that is quick to read and preserves the state of the running javascript. Alternatively, if running on a machine with virtual memory and an OS that can page stuff out to disk, then care could be taken such that a single web page and all state of its executing javascript would be contained within a single virtual memory page, or the fewest amount of pages possible. Then the browser could suspend the javascript execution of the web page and never refer to memory on those (memory) pages, allowing the OS to page the web page data to swap if needed. Running javascript and javascript timers would need to be suspended, which might break a few websites. But if they aren't designed to recover under such circumstances, then those websites are complete shit, although that doesn't change the fact that you may be forced to use them, so I don't know...
>>13
I was thinking of mark-compact: http://en.wikipedia.org/wiki/Mark-compact_algorithm
This allows constant-time allocations and doesn't waste half the memory doing so. Essentially the heap becomes a huge dynamic array that gets resized in amortized constant time.
>>17
You mean this thread? It's around 20KB right now. 5MB for that would be huge --- 250 bytes per byte. (I'm assuming you mean 5MB for the HTML DOM and associated data structures, not including the code.)
>>19 I'd probably only support one active tab at a time
What UI supports multiple active tabs?
The biggest source of complexity is probably the interaction of the JS with the DOM, since you want the DOM to be represented in some memory-efficient format they would not correspond to JS objects necessarily. JS can manipulate the DOM in many different ways and you would have to handle memory allocation/deallocation appropriately (e.g. a node that was created only by JS and not in the original page, would need to be freed once JS disposes of it.) Writing a browser that just renders static HTML is almost trivial in comparison.
>>21
Just have a sufficiently large browser, expansion with be 0, according to Newton
>>20
Play a youtube video. Open a new tab. Your youtube video will still be playing.
Name:
Anonymous2011-11-23 8:57
>>20 You mean this thread?
Pick any random bookmark and check the memory usage of that page. I'm assuming you mean 5MB for the HTML DOM and associated data structures, not including the code.
That's what I meant. The document itself should only be 10k-400k and the calculated form of that document shouldn't be more than 15MB in most cases.
Well that gc technique sure is nifty. Thanks for the link.
Yes, internet explorer uses reference counting for dom objects I believe. I think I'll try to leverage as much open source software as possible, but it none meet the low memory usage requirements, I'll take one and start replacing parts of it.
>>27
HTML 3.2 only, that's not too useful. At least 4.01 + CSS2.1 is common now. Expansion is the delta (i.e. the memory taken by the loaded document) divided by the size of the document itself. As of that posting this thread was 21411 bytes of HTML which gives an expansion of ~23, not bad.
Here's Dillo 3.0, and this page is now ~28KB: 3668K 4780K 1112K 39.1
(This browser is a single 1.2MB file. Unfortunately it has tons of statically linked dependencies due to being a Windows port instead of native Win32 which could make it much smaller.)
Name:
Anonymous2011-11-24 5:53
Dillo
Mor elike Dildo amirite
Name:
F R O Z E N C U D D E R !anusl5eyYc2011-11-24 5:58