[jcid@dillo.org: Commit 3626. Redraw problems]
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
On Wed, Apr 23, 2014, Sebastian Geerken wrote:
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?
On Tue, Apr 22, 2014, Jorge Arellano Cid wrote:
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
On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote:
On Tue, Apr 22, 2014, Jorge Arellano Cid wrote:
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.-
On Fr, Apr 25, 2014, Jorge Arellano Cid wrote:
On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote:
On Tue, Apr 22, 2014, Jorge Arellano Cid wrote:
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. :-)
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
On Tue, Apr 29, 2014, Sebastian Geerken wrote:
On Fr, Apr 25, 2014, Jorge Arellano Cid wrote:
On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: [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
On Wed, Apr 30, 2014 at 05:16:07PM +0200, Sebastian Geerken wrote:
On Tue, Apr 29, 2014, Sebastian Geerken wrote:
On Fr, Apr 25, 2014, Jorge Arellano Cid wrote:
On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: [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.-
On Mi, Apr 30, 2014, Jorge Arellano Cid wrote:
On Wed, Apr 30, 2014 at 05:16:07PM +0200, Sebastian Geerken wrote:
On Tue, Apr 29, 2014, Sebastian Geerken wrote:
On Fr, Apr 25, 2014, Jorge Arellano Cid wrote:
On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: [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).
Works now, too; a problem with the "clear" attribute. (Actually rather similar to the previous problem.) Sebastian
On Thu, May 01, 2014 at 09:22:42PM +0200, Sebastian Geerken wrote:
On Mi, Apr 30, 2014, Jorge Arellano Cid wrote:
On Wed, Apr 30, 2014 at 05:16:07PM +0200, Sebastian Geerken wrote:
On Tue, Apr 29, 2014, Sebastian Geerken wrote:
On Fr, Apr 25, 2014, Jorge Arellano Cid wrote:
On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: [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).
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.-
On Do, Mai 01, 2014, Jorge Arellano Cid wrote:
On Thu, May 01, 2014 at 09:22:42PM +0200, Sebastian Geerken wrote:
On Mi, Apr 30, 2014, Jorge Arellano Cid wrote:
On Wed, Apr 30, 2014 at 05:16:07PM +0200, Sebastian Geerken wrote:
On Tue, Apr 29, 2014, Sebastian Geerken wrote:
On Fr, Apr 25, 2014, Jorge Arellano Cid wrote:
On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: [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).
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.
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
On Thu, May 01, 2014, Sebastian Geerken wrote:
On Do, Mai 01, 2014, Jorge Arellano Cid wrote:
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.
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
On Thu, May 01, 2014 at 11:02:54PM +0200, Sebastian Geerken wrote:
On Thu, May 01, 2014, Sebastian Geerken wrote:
On Do, Mai 01, 2014, Jorge Arellano Cid wrote:
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.
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_").
I still get something like that with http://slashdot.org Cheers, Johannes
On Do, Mai 01, 2014, Johannes Hofmann wrote:
On Thu, May 01, 2014 at 11:02:54PM +0200, Sebastian Geerken wrote:
On Thu, May 01, 2014, Sebastian Geerken wrote:
On Do, Mai 01, 2014, Jorge Arellano Cid wrote:
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.
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_").
I still get something like that with http://slashdot.org
I can confirm this. I'll work on this. Sebastian
On Thu, May 01, 2014 at 11:11:22PM +0200, Johannes Hofmann wrote:
On Thu, May 01, 2014 at 11:02:54PM +0200, Sebastian Geerken wrote:
On Thu, May 01, 2014, Sebastian Geerken wrote:
On Do, Mai 01, 2014, Jorge Arellano Cid wrote:
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.
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_").
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.-
On Do, Mai 01, 2014, Johannes Hofmann wrote:
On Thu, May 01, 2014 at 11:02:54PM +0200, Sebastian Geerken wrote:
On Thu, May 01, 2014, Sebastian Geerken wrote:
On Do, Mai 01, 2014, Jorge Arellano Cid wrote:
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.
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_").
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
On Sat, May 03, 2014 at 01:32:35PM +0200, Sebastian Geerken wrote:
On Do, Mai 01, 2014, Johannes Hofmann wrote:
On Thu, May 01, 2014 at 11:02:54PM +0200, Sebastian Geerken wrote:
On Thu, May 01, 2014, Sebastian Geerken wrote:
On Do, Mai 01, 2014, Jorge Arellano Cid wrote:
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.
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_").
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; } ----------------------------------------------------------------------
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/
On Thu, May 01, 2014 at 10:55:36PM +0200, Sebastian Geerken wrote:
On Do, Mai 01, 2014, Jorge Arellano Cid wrote:
On Thu, May 01, 2014 at 09:22:42PM +0200, Sebastian Geerken wrote:
On Mi, Apr 30, 2014, Jorge Arellano Cid wrote:
On Wed, Apr 30, 2014 at 05:16:07PM +0200, Sebastian Geerken wrote:
On Tue, Apr 29, 2014, Sebastian Geerken wrote:
On Fr, Apr 25, 2014, Jorge Arellano Cid wrote:
On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: [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).
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.
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.-
On Thu, May 01, 2014 at 09:22:42PM +0200, Sebastian Geerken wrote:
On Mi, Apr 30, 2014, Jorge Arellano Cid wrote:
On Wed, Apr 30, 2014 at 05:16:07PM +0200, Sebastian Geerken wrote:
On Tue, Apr 29, 2014, Sebastian Geerken wrote:
On Fr, Apr 25, 2014, Jorge Arellano Cid wrote:
On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: [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).
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.-
Hi Jorge, On Fr, Mai 02, 2014, Jorge Arellano Cid wrote:
On Thu, May 01, 2014 at 09:22:42PM +0200, Sebastian Geerken wrote:
On Mi, Apr 30, 2014, Jorge Arellano Cid wrote:
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
participants (3)
-
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
sgeerken＠dillo.org