Discussion:
[jcid-h2S9ffZSyN3YtjvyW6yDsg@public.gmane.org: Commit 3626. Redraw problems]
Jorge Arellano Cid
2014-04-22 23:08:14 UTC
Permalink
Hi,

FYI.
--
Cheers
Jorge.-
Sebastian Geerken
2014-04-23 11:13:03 UTC
Permalink
Hi Jorge,
Today I saw commit 3626, and checked whether the pages I see to
produce redraw storms and CPU hogs were gone, and... no :-P
I got one of them and worked reducing it to try to produce a good
test case, that's the attachment. If you open it with embedded CSS
disabled, it's OK, then enable it and voila: redraw storm and CPU
hog.
I hope this helps the cause. Please let me know whether you can
work on it, or give me some clues to try to start digging further.
Yes, I can reproduce the problem. Thanks for the test.

This change (revision 3626) was for the opposite problem: in some
cases, there is no redraw. It seems that I'll have to care about the
TODO of the commit message soon: "Cleanup and document lastWordDrawn
and redrawY!".

I'll work on this soon, after an issue I'll hope to finish today.

Sebastian
Sebastian Geerken
2014-04-24 12:38:41 UTC
Permalink
Post by Sebastian Geerken
Hi Jorge,
Today I saw commit 3626, and checked whether the pages I see to
produce redraw storms and CPU hogs were gone, and... no :-P
I got one of them and worked reducing it to try to produce a good
test case, that's the attachment. If you open it with embedded CSS
disabled, it's OK, then enable it and voila: redraw storm and CPU
hog.
I hope this helps the cause. Please let me know whether you can
work on it, or give me some clues to try to start digging further.
Yes, I can reproduce the problem. Thanks for the test.
This change (revision 3626) was for the opposite problem: in some
cases, there is no redraw. It seems that I'll have to care about the
TODO of the commit message soon: "Cleanup and document lastWordDrawn
and redrawY!".
I'll work on this soon, after an issue I'll hope to finish today.
I'm now working on this, and have already found out that this is not a
redrawing problem: the only change in 3626 is that the CPU load is
shifted from dillo to Xorg. (It seems that more redrawing is done, but
this is rather a symptom of another problem, probably with resizing.)

I noted this several times, so please observe CPU load (e. g. with
top(1)): if it stays high, even if dillo is responsive this is a
problem you should send to the list.

Sebastian

PS: Cleaning up lastWordDrawn/redrawY is still an issue, but with
lower priority. Who did actually implement this?
Johannes Hofmann
2014-04-24 13:25:37 UTC
Permalink
That was me. Sorry I didn't follow this. Can you point me to the
problem?
The idea with redrawY is that when loading long pages we don't
keep redrawing the currently visible (top) part of the page while
adding text on the bottom.
Obviously this only works as long as the newly incoming HTML doesn't
affect the layout of the already drawn (top) part of the page.

Cheers,
Johannes
Post by Sebastian Geerken
Hi Jorge,
   Today I saw commit 3626, and checked whether the pages I see to
produce redraw storms and CPU hogs were gone, and...  no   :-P
   I got one of them and worked reducing it to try to produce a good
test case, that's the attachment. If you open it with embedded CSS
disabled, it's OK, then enable it and voila: redraw storm and CPU
hog.
   I hope this helps the cause. Please let me know whether you can
work on it, or give me some clues to try to start digging further.
Yes, I can reproduce the problem. Thanks for the test.
This change (revision 3626) was for the opposite problem: in some
cases, there is no redraw. It seems that I'll have to care about the
TODO of the commit message soon: "Cleanup and document lastWordDrawn
and redrawY!".
I'll work on this soon, after an issue I'll hope to finish today.
I'm now working on this, and have already found out that this is not a
redrawing problem: the only change in 3626 is that the CPU load is
shifted from dillo to Xorg. (It seems that more redrawing is done, but
this is rather a symptom of another problem, probably with resizing.)

I noted this several times, so please observe CPU load (e. g.  with
top(1)): if it stays high, even if dillo is responsive this is a
problem you should send to the list.

Sebastian

PS: Cleaning up lastWordDrawn/redrawY is still an issue, but with
lower priority.  Who did actually implement this?

_______________________________________________
Dillo-dev mailing list
Dillo-dev-***@public.gmane.org
http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev
Sebastian Geerken
2014-04-25 09:19:33 UTC
Permalink
Today I saw commit 3626, and checked whether the pages I see to
produce redraw storms and CPU hogs were gone, and... no :-P
I got one of them and worked reducing it to try to produce a good
test case, that's the attachment. If you open it with embedded CSS
disabled, it's OK, then enable it and voila: redraw storm and CPU
hog.
I hope this helps the cause. Please let me know whether you can
work on it, or give me some clues to try to start digging further.
Has been fixed now (really stupid bug).

Sebastian
Jorge Arellano Cid
2014-04-25 13:25:41 UTC
Permalink
Post by Sebastian Geerken
Today I saw commit 3626, and checked whether the pages I see to
produce redraw storms and CPU hogs were gone, and... no :-P
I got one of them and worked reducing it to try to produce a good
test case, that's the attachment. If you open it with embedded CSS
disabled, it's OK, then enable it and voila: redraw storm and CPU
hog.
I hope this helps the cause. Please let me know whether you can
work on it, or give me some clues to try to start digging further.
Has been fixed now (really stupid bug).
Good.

BTW, I've come to like this kind of bugs along the way, a
simple change, great benefit, and no major work involved.


OTOH, there're still some problems. The original URL [1] still
hogs the CPU. This time the page keeps increasing its length on
an on ("ad eternum").

When loaded with remote CSS disabled, it behaves OK (like the
reduced test case). If you enable remote CSS, the page length
tarts increasing (press End key and check the scrollbar).


[1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan
--
Cheers
Jorge.-
Sebastian Geerken
2014-04-29 21:28:40 UTC
Permalink
Post by Jorge Arellano Cid
Post by Sebastian Geerken
Today I saw commit 3626, and checked whether the pages I see to
produce redraw storms and CPU hogs were gone, and... no :-P
I got one of them and worked reducing it to try to produce a good
test case, that's the attachment. If you open it with embedded CSS
disabled, it's OK, then enable it and voila: redraw storm and CPU
hog.
I hope this helps the cause. Please let me know whether you can
work on it, or give me some clues to try to start digging further.
Has been fixed now (really stupid bug).
Good.
BTW, I've come to like this kind of bugs along the way, a
simple change, great benefit, and no major work involved.
I'd prefer not to have such bugs in the first place. :-)
Post by Jorge Arellano Cid
OTOH, there're still some problems. The original URL [1] still
hogs the CPU. This time the page keeps increasing its length on
an on ("ad eternum").
When loaded with remote CSS disabled, it behaves OK (like the
reduced test case). If you enable remote CSS, the page length
tarts increasing (press End key and check the scrollbar).
[1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan
Most seems fixed, at least the CPU hogging. Still much space above,
but I can reproduce it with a simple test page (attached), so this
should not take long, hopefully.

Also, sizes are generally not perfect, but that will be cleaned a bit
later (general redesign of widget sizes).

Sebastian
Sebastian Geerken
2014-04-30 15:16:07 UTC
Permalink
Post by Sebastian Geerken
Post by Jorge Arellano Cid
[1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan
Most seems fixed, at least the CPU hogging. Still much space above,
but I can reproduce it with a simple test page (attached), so this
should not take long, hopefully.
Fixed.

Sebastian
Jorge Arellano Cid
2014-04-30 21:34:26 UTC
Permalink
Post by Sebastian Geerken
Post by Sebastian Geerken
Post by Jorge Arellano Cid
[1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan
Most seems fixed, at least the CPU hogging. Still much space above,
but I can reproduce it with a simple test page (attached), so this
should not take long, hopefully.
Fixed.
Good.

Now, this one [1] hogs the CPU between two alternate layouts...
(it also happens without the patch, but in a slighty different way).


[1] http://www.bolsadesantiago.com/index.aspx
--
Cheers
Jorge.-
Sebastian Geerken
2014-05-01 19:22:42 UTC
Permalink
Post by Jorge Arellano Cid
Post by Sebastian Geerken
Post by Sebastian Geerken
Post by Jorge Arellano Cid
[1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan
Most seems fixed, at least the CPU hogging. Still much space above,
but I can reproduce it with a simple test page (attached), so this
should not take long, hopefully.
Fixed.
Good.
Now, this one [1] hogs the CPU between two alternate layouts...
(it also happens without the patch, but in a slighty different way).
[1] http://www.bolsadesantiago.com/index.aspx
Works now, too; a problem with the "clear" attribute. (Actually rather
similar to the previous problem.)

Sebastian
Jorge Arellano Cid
2014-05-01 20:44:20 UTC
Permalink
Post by Sebastian Geerken
Post by Jorge Arellano Cid
Post by Sebastian Geerken
Post by Sebastian Geerken
Post by Jorge Arellano Cid
[1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan
Most seems fixed, at least the CPU hogging. Still much space above,
but I can reproduce it with a simple test page (attached), so this
should not take long, hopefully.
Fixed.
Good.
Now, this one [1] hogs the CPU between two alternate layouts...
(it also happens without the patch, but in a slighty different way).
[1] http://www.bolsadesantiago.com/index.aspx
Works now, too; a problem with the "clear" attribute. (Actually rather
similar to the previous problem.)
Good!

It works OK now.


This one [2] still hogs the CPU between two alternate layouts.
There's no need to enable images, just the main page and remote CSS
will do.

[2] http://www.emol.com/economia/
--
Cheers
Jorge.-
Sebastian Geerken
2014-05-01 20:55:36 UTC
Permalink
Post by Jorge Arellano Cid
Post by Sebastian Geerken
Post by Jorge Arellano Cid
Post by Sebastian Geerken
Post by Sebastian Geerken
Post by Jorge Arellano Cid
[1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan
Most seems fixed, at least the CPU hogging. Still much space above,
but I can reproduce it with a simple test page (attached), so this
should not take long, hopefully.
Fixed.
Good.
Now, this one [1] hogs the CPU between two alternate layouts...
(it also happens without the patch, but in a slighty different way).
[1] http://www.bolsadesantiago.com/index.aspx
Works now, too; a problem with the "clear" attribute. (Actually rather
similar to the previous problem.)
Good!
It works OK now.
This one [2] still hogs the CPU between two alternate layouts.
There's no need to enable images, just the main page and remote CSS
will do.
[2] http://www.emol.com/economia/
I cannot reproduce this: with revision 3637, the page looks fine,
without flickering or CPU hogging. (Everything enabled, but turning
off images has the same effect.)

Sebastian
Sebastian Geerken
2014-05-01 21:02:54 UTC
Permalink
Post by Sebastian Geerken
Post by Jorge Arellano Cid
Good!
It works OK now.
This one [2] still hogs the CPU between two alternate layouts.
There's no need to enable images, just the main page and remote CSS
will do.
[2] http://www.emol.com/economia/
I cannot reproduce this: with revision 3637, the page looks fine,
without flickering or CPU hogging. (Everything enabled, but turning
off images has the same effect.)
Updates:

1. I can neither reproduce it with standard configuration ("mv .dillo
.dillo_").

2. Another bug: he headings are too narrow: this is something I
noticed already (especially in wikipedia), and which I have on my
list already.

Sebastian
Johannes Hofmann
2014-05-01 21:11:22 UTC
Permalink
Post by Sebastian Geerken
Post by Sebastian Geerken
Post by Jorge Arellano Cid
Good!
It works OK now.
This one [2] still hogs the CPU between two alternate layouts.
There's no need to enable images, just the main page and remote CSS
will do.
[2] http://www.emol.com/economia/
I cannot reproduce this: with revision 3637, the page looks fine,
without flickering or CPU hogging. (Everything enabled, but turning
off images has the same effect.)
1. I can neither reproduce it with standard configuration ("mv .dillo
.dillo_").
I still get something like that with http://slashdot.org

Cheers,
Johannes
Sebastian Geerken
2014-05-01 21:25:39 UTC
Permalink
Post by Johannes Hofmann
Post by Sebastian Geerken
Post by Sebastian Geerken
Post by Jorge Arellano Cid
Good!
It works OK now.
This one [2] still hogs the CPU between two alternate layouts.
There's no need to enable images, just the main page and remote CSS
will do.
[2] http://www.emol.com/economia/
I cannot reproduce this: with revision 3637, the page looks fine,
without flickering or CPU hogging. (Everything enabled, but turning
off images has the same effect.)
1. I can neither reproduce it with standard configuration ("mv .dillo
.dillo_").
I still get something like that with http://slashdot.org
I can confirm this. I'll work on this.

Sebastian
Jorge Arellano Cid
2014-05-01 21:58:44 UTC
Permalink
Post by Johannes Hofmann
Post by Sebastian Geerken
Post by Sebastian Geerken
Post by Jorge Arellano Cid
Good!
It works OK now.
This one [2] still hogs the CPU between two alternate layouts.
There's no need to enable images, just the main page and remote CSS
will do.
[2] http://www.emol.com/economia/
I cannot reproduce this: with revision 3637, the page looks fine,
without flickering or CPU hogging. (Everything enabled, but turning
off images has the same effect.)
1. I can neither reproduce it with standard configuration ("mv .dillo
.dillo_").
I still get something like that with http://slashdot.org
Does [2] produce flickering among two layouts for you Johannes?

Here it does. Checked twice.
--
Cheers
Jorge.-
Sebastian Geerken
2014-05-03 11:32:35 UTC
Permalink
Post by Johannes Hofmann
Post by Sebastian Geerken
Post by Sebastian Geerken
Post by Jorge Arellano Cid
Good!
It works OK now.
This one [2] still hogs the CPU between two alternate layouts.
There's no need to enable images, just the main page and remote CSS
will do.
[2] http://www.emol.com/economia/
I cannot reproduce this: with revision 3637, the page looks fine,
without flickering or CPU hogging. (Everything enabled, but turning
off images has the same effect.)
1. I can neither reproduce it with standard configuration ("mv .dillo
.dillo_").
I still get something like that with http://slashdot.org
This is working now. Unfortunately, the text is much too wide, which
is due to some CSS definitions "text-indent: 9999px".i (I don't know
whether this is a trick only working in some browsers, or whether
dillo is incomplete and should actually ignore this.) If you put this
in your ~/.dillo/style.css, slashdot becomes readable again:

----------------------------------------------------------------------
.spinner .tag-server-busy.spinner, .fhitem-editor .tag-server-busy,
article footer .tag-server-busy, #edit-busy.busy.spinner, .synd .rss,
.synd .tw, .synd .fb, .synd .gp, ui-icon.pref a, .ui-icon.edit a,
.ui-icon.rss a, #user_bio .prefs a, #commentwrap .ui-icon.search {
text-indent:0px !important;
}
----------------------------------------------------------------------

Jorge: Do you still have problems with the other pages?

Sebastian
Johannes Hofmann
2014-05-04 19:35:53 UTC
Permalink
Post by Sebastian Geerken
Post by Johannes Hofmann
Post by Sebastian Geerken
Post by Sebastian Geerken
Post by Jorge Arellano Cid
Good!
It works OK now.
This one [2] still hogs the CPU between two alternate layouts.
There's no need to enable images, just the main page and remote CSS
will do.
[2] http://www.emol.com/economia/
I cannot reproduce this: with revision 3637, the page looks fine,
without flickering or CPU hogging. (Everything enabled, but turning
off images has the same effect.)
1. I can neither reproduce it with standard configuration ("mv .dillo
.dillo_").
I still get something like that with http://slashdot.org
This is working now. Unfortunately, the text is much too wide, which
is due to some CSS definitions "text-indent: 9999px".i (I don't know
whether this is a trick only working in some browsers, or whether
dillo is incomplete and should actually ignore this.) If you put this
----------------------------------------------------------------------
.spinner .tag-server-busy.spinner, .fhitem-editor .tag-server-busy,
article footer .tag-server-busy, #edit-busy.busy.spinner, .synd .rss,
.synd .tw, .synd .fb, .synd .gp, ui-icon.pref a, .ui-icon.edit a,
.ui-icon.rss a, #user_bio .prefs a, #commentwrap .ui-icon.search {
text-indent:0px !important;
}
----------------------------------------------------------------------
Cool, thank you!
Regarding this "text-indent: 9999px", I've seen this a couple of
time and it seems to be a common trick [1].

Cheers,
Johannes

[1] http://luigimontanez.com/2010/stop-using-text-indent-css-trick/
Jorge Arellano Cid
2014-05-01 22:05:16 UTC
Permalink
Post by Sebastian Geerken
Post by Jorge Arellano Cid
Post by Sebastian Geerken
Post by Jorge Arellano Cid
Post by Sebastian Geerken
Post by Sebastian Geerken
Post by Jorge Arellano Cid
[1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan
Most seems fixed, at least the CPU hogging. Still much space above,
but I can reproduce it with a simple test page (attached), so this
should not take long, hopefully.
Fixed.
Good.
Now, this one [1] hogs the CPU between two alternate layouts...
(it also happens without the patch, but in a slighty different way).
[1] http://www.bolsadesantiago.com/index.aspx
Works now, too; a problem with the "clear" attribute. (Actually rather
similar to the previous problem.)
Good!
It works OK now.
This one [2] still hogs the CPU between two alternate layouts.
There's no need to enable images, just the main page and remote CSS
will do.
[2] http://www.emol.com/economia/
I cannot reproduce this: with revision 3637, the page looks fine,
without flickering or CPU hogging. (Everything enabled, but turning
off images has the same effect.)
Oh, it happens here...

If I download the page and load it as a local file, there's
no CPU hog nor flicker (nor CSS loaded), but from the HTTP URL,
the three of them are present.
--
Cheers
Jorge.-
Jorge Arellano Cid
2014-05-02 16:24:07 UTC
Permalink
Post by Sebastian Geerken
Post by Jorge Arellano Cid
Post by Sebastian Geerken
Post by Sebastian Geerken
Post by Jorge Arellano Cid
[1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan
Most seems fixed, at least the CPU hogging. Still much space above,
but I can reproduce it with a simple test page (attached), so this
should not take long, hopefully.
Fixed.
Good.
Now, this one [1] hogs the CPU between two alternate layouts...
(it also happens without the patch, but in a slighty different way).
[1] http://www.bolsadesantiago.com/index.aspx
Works now, too; a problem with the "clear" attribute. (Actually rather
similar to the previous problem.)
After 3638, it restarted with the CPU hogs on [1] here.

Now, if I disable remote CSS, load the URL, and afterwards
enable remote CSS, there's no problem.

So there's clearly a timing issue upon CSS data arrival that
can explain why sometimes it doesn't happen.

HTH.
--
Cheers
Jorge.-
Sebastian Geerken
2014-05-02 18:42:41 UTC
Permalink
Hi Jorge,
Post by Jorge Arellano Cid
Post by Sebastian Geerken
Post by Jorge Arellano Cid
[1] http://www.bolsadesantiago.com/index.aspx
Works now, too; a problem with the "clear" attribute. (Actually rather
similar to the previous problem.)
After 3638, it restarted with the CPU hogs on [1] here.
Now, if I disable remote CSS, load the URL, and afterwards
enable remote CSS, there's no problem.
So there's clearly a timing issue upon CSS data arrival that
can explain why sometimes it doesn't happen.
HTH.
I neither can reproduce this, unfortunately. The change 3638 was not
related to CPU hogging/layout flickering issues, but a rather simple
resizing bug (in Wikipedia, the search field is now visible again, as
an example).

I'm currently working on slashdot.org; hopefully this is another
symptom of the same bug. If not ... we'll see.

Sebastian
Loading...