| Age | Commit message (Collapse) | Author |
|---|
|
We change to a graph coverage model, with pruning.
|
|
This helps to avoid unnecessary resize calls.
|
|
This was three year old bug, that went undiscovered (hg#2863).
The patch is simpler than it looks, it's just a while cycle enclosing
the body, indentation makes it look large.
How to reproduce:
1. Load [5] at normal size, wait for most images to load, search for "re-re"
with Find Text, press page down (you'll see an image), go Bck/Fwd, check
the image is there. If not, you can place the cursor where the image was,
if you get a hand cursor, Dillo thinks it is there. Wait for the tooltip
and drag it a bit downwards to the right, Dillo will repaint from the image
data.
[5] http://tinyurl.com/huvf6pn
|
|
|
|
A simple code order changes, which is not relevant in this case,
but pleases cppcheck:
- for (a,b; ; )
+ for (b,a; ; )
|
|
|
|
|
|
|
|
|
|
|
|
|
|
slightly more complex (but more correct) implementatin for Textblock.
|
|
|
|
|
|
|
|
|
|
|
|
This is a race condition. When loading [1], tables under the form date camp,
may dissapear and some overlapping text be shown below.
How to reproduce: load the site (network effect may be enough), or
go back and forward a few times, or maximize then back and forward.
[1] http://www.btgpactual.mdgms.com/www/chile/resume.html
FWIW this is the only regression I've found so far.
|
|
This patch fixes a cpu-hog regression of GROWS2 with respect to dillo-3.0.5.
The problem arises with some deeply nested elements. e.g.:
(for i in $(seq 1 20); do echo '<div style="float:left"><div></div><div
style="display:table"><span></div></div>'; done) > t0.html
(for i in $(seq 1 20); do echo '<div style="float:left"><div></div><div
style="display:table"></div>'; done) > t1.html
For both, taking away the SPAN or float is much faster.
Note: Some "unrelated" sited (i.e. not clearly hogging the CPU) have been
measured to render near two times faster with the patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
value. This fixes too small return values of getGeneratorRest().
|
|
|
|
Now:
getPart(): can't receive out-of-range values for "index" and "sectionIndex".
setValues(): below-range indexes go to START and above-range to END.
prev(), next(): have a single value-checked entry-point to getPart().
PD: it's easier to read the source of these functions than the diff.
|
|
https://linux.slashdot.org/comments.pl?sid=5852295&cid=48188823
It was hard to find, sometimes backtraces gave near 85 or more nested calls,
full of different functions. There was no CPU lock because it finally solved
the page (after more than two minutes in my machine).
Finding the bug: > 99,9% of the effort.
Actual fix : ~ 0.01% of the effort.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rewrote FltkViewport::draw() into a much cleaner style, fixing 3 problems.
Bug fixes:
1. The mouse button FL_RELEASE event over the scrollbars area
triggered an unnecessary redraw.
2. The mouse button FL_RELEASE event, after scrolling,
triggered an unnecessary redraw.
3. The FL_RELEASE event, after {horiz|vert}scrolling
was passed upwards although already handled.
|
|
Now there's a single fl_scroll() call for each scroll operation,
instead of calling fl_scroll() and then draw().
The patch also fixes support for FL_DAMAGE_EXPOSE in FltkViewport::draw().
Test data:
FL_DAMAGE_CHILD = 0x01, 1
FL_DAMAGE_EXPOSE = 0x02, 2
FL_DAMAGE_SCROLL = 0x04, 4
FL_DAMAGE_OVERLAY = 0x08, 8
FL_DAMAGE_USER1 = 0x10, 16
FL_DAMAGE_USER2 = 0x20, 32
FL_DAMAGE_ALL = 0x80 128
-----------------------------------------------------------------------------.
| scroll: keys | focus click | Alt-Tab | unfocus|
| or mousewheel | viewport | statusbar | unfocus | focus | click |
-----------------------------------------------------------------------------|
d4235 | 5,5 | 16 | | 128 |128,128,128| |
d4529 | 5,5 | 16 | | 128 |128,128,128| |
dpatch | 5 | 16 | | 128 |128,128,128| |
-----------------------------------------------------------------------------'
</pre>
The first column means dillo version (hg rev). The second one
the FLTK damage bits received by FltkViewport::draw() per scroll
operation (also viewable at dillo's stdout).
The other columns show excessive calls, but that's another bug
that is not as relevant as scrolling now, so feel free to ignore
them by now.
|
|
|
|
|
|
|
