We probably leak some threads and resources, e.g. when the script task crashes
and doesn't get a chance to send layout data back to layout to be deallocated.
Not tested with iframes yet.
In order to support line-break by new-line character,
Fist, calculate new-line character's position.(fn flush_clump_to_list)
Second, split box(which includes new-line character) and do line-break.(fn scan_for_lines)
assign-heights phases.
This uses the new work-stealing deque. By default, 3/4 of a thread per
logical CPU is used. This can be tuned with the `-y` flag.
I measured a 65% reflow speedup on `perf-rainbow.html` and a 247% reflow
speedup on `http://en.wikipedia.org/wiki/South_China_Sea` on a 4-core
HyperThreaded Core i7. However, numbers were fairly volatile, especially
for the latter.
* add servo_util::task::{spawn_named,spawn_with_named} functions
* add name param for spawn_listener and spawn_conversation functions
this should resolve#1169
* Using .connect(", ") just to use .split(",") later is silly. Keep it a vector.
* The 'font-style' property can not be both italic and oblique. Use an enum instead of two booleans.
1. We've aimed to android 4.3 Jellybean devices like Galaxy 10.1 and Galaxy Nexus, etc. I think it could still support android 4.1
2. Needs android ndk r9(not r9b) and latest android sdk
3. Needs some device list update on sdk for apk build.
4. Currently we can not build android port on mac because compiler build problem like https://github.com/mozilla/rust/pull/10921. Hopefully I expect that it could be resolved at next rust upgrade.
* Using .connect(", ") just to use .split(",") later is silly.
Keep it a vector.
* The 'font-style' property can not be both italic and oblique.
Use an enum instead of two booleans.
This reverts commit e8ffac13d7, reversing
changes made to db923feffe.
Reverting this change because FreeType is *not* thread safe. See the
documentation here:
http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html
"In multi-threaded applications, make sure that the same FT_Library
object or any of its children doesn't get accessed in parallel."
We will need to use a `MutexArc` instead.
The shaper code referenced in this issue is no longer being used. It
was removed in commit a535f22146, but
later reintroduced due to a merge conflict in commit
d64d987e1d.
Fixes#163.