- Dillo-dev - lists.mailman3.com

Re: commit 3e01d83fd6d1 draws too large background box

by Johannes.Hofmann＠gmx.de

Hi, sorry for the delay... On Tue, Apr 27, 2010 at 11:40:11PM +0200, Johannes Hofmann wrote: > On Tue, Apr 27, 2010 at 09:04:49PM +0000, corvid wrote: > > > commit 3e01d83fd6d1 (draw background for all Words, not just text) > > > draws a too large background box e.g. in this example: > > > > > > <html><body> > > > foo <div style="background-color: blue; margin-top: 100px">bar</div> > > > </body></html> > > > > > > The margin should not be blue. > > > What is the reason for this change anyway? Shouldn't each widget be > > > responsible for it's drawing (including the background)? > > > > This is when I was looking at the rectangles of color on the fltk.org > > page around, e.g., "FLTK Apps", "FLTK Library"... > > > > The rectangle of color (which came from the style of the A element, iirc) > > is "supposed" to be taller than the little rounded-corner images, judging > > by what firefox does. > > Ah, I think I see the problem now. Textblock has to draw the > background for the <A> element - even at places where it is covered > by child widgets, as they might be transparent. > On the other hand margins are always transparent (see > http://www.w3.org/TR/CSS2/box.html) so there is a problem in the > current implementation. > I guess I need some time to think about this. > > > > > So if the margin is part of the child, then... > > how should this be disentangled? > > Does it come down to being one of those things that have to wait until > > we have more of a real box model? > > > > We already have a proper box model for block boxes, what we are missing > is proper handling of inline boxes (e.g. drawing borders around > <a>-elements). Ok, the general problem is that a single Textblock widget can handle multiple HTML elements. E.g. in this case: <a href=foo style="background-color: red">foo <b>bar</b></a> there is just a single Textblock drawing the whole thing. The style of the word "bar" would normally not have a background color set, but the red of the <a> element would shine through, but as the textblock simply draws one word after the other, we do not draw the whole <a> element and then draw the <b> element on top. To make the background color work nevertheless, I had introduced the inheritBackgroundColor hack, which will pass the red background to the style of the child element (<b> in this case). However, this hack does not work properly if the child element has a margin: <a href=foo style="background-color: red">foo <img src=foo.png alt=bar style="margin:1em"></a> So I think we should remove the whole inheritBackgroundColor() hack and replace it with some code in textblock.cc, that draws the proper background color for all words as necessary. We need to be careful though to not draw word backgrounds if they are the same color as the whole textblock to avoid excessive drawing. This would still not allow things like: <b style="border: 1px solid black">foo</b> but I currently don't see a simple way to make that work. Cheers, Johannes

May 9, 2010

[rogerx@sdf.org: Bug in Dillo Text Entry]

by jcid＠dillo.org

-- Cheers Jorge.-

May 8, 2010

setting image buffer and queueing resize

by corvid＠lavabit.com

I had just fixed the dw simple image test that hadn't requested a resize when setting the imgbuf. And now I just found that one of the scaled2 test's images needs it as well. Perhaps we should make the resize argument to setBuffer() mandatory. But, better yet, how about if Image::setBuffer() just does a queueResize() if either of its dimensions are LENGTH_AUTO?

April 28, 2010

Re: style.css font-family misses redraw

by dennisn＠dennisn.dyndns.org

On Tue, 27 Apr 2010 20:54:37 +0200, Johannes Hofmann wrote: > On Sun, Apr 25, 2010 at 11:35:20AM -0400, Dennis Nezic wrote: > > On Fri, 23 Apr 2010 23:37:31 +0200, Johannes Hofmann wrote: > > > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > > > > > * { font-family:sans-serif } > > > > > > > > And then visit a page like: > > > > > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > > > > > ... it will produce "ghost" lines from the previous rendering > > > > before the css was applied. Moving the window, or doing > > > > anything else that forces a redraw, cleans it up. (Let me know > > > > if you don't see this and I can provide a screenshot.) > > > > > > Hm, the page does not seem to contain any CSS, so it renders with > > > just the user agent style and the user style (~/.dillo/style.css) > > > even the first time it draws. Maybe it's because of the images > > > that change the layout once loaded? > > > Can you reproduce the issue with load_images=NO? > > > > > > I've alse seen "ghost" lines on some pages, but could never find > > > the real reason. I only remeber that it depended on timing > > > somehow. > > > > The issue does not appear with load_images=NO ... ie. when it only > > occurs when images are loaded, and the table cells redrawn, but > > apparently not rendered automatically. (Until one moves the window, > > etc.) > > > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines.jpg > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines-gone.jpg > > > > Can you please test this patch > http://flpsed.org/tmp/ghostlines.diff > It fixes the issue I could reproduce here. Problem solved! :D

April 28, 2010

Re: style.css font-family misses redraw

by Johannes.Hofmann＠gmx.de

On Sun, Apr 25, 2010 at 11:35:20AM -0400, Dennis Nezic wrote: > On Fri, 23 Apr 2010 23:37:31 +0200, Johannes Hofmann wrote: > > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > > > * { font-family:sans-serif } > > > > > > And then visit a page like: > > > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > > > ... it will produce "ghost" lines from the previous rendering before > > > the css was applied. Moving the window, or doing anything else that > > > forces a redraw, cleans it up. (Let me know if you don't see this > > > and I can provide a screenshot.) > > > > Hm, the page does not seem to contain any CSS, so it renders with > > just the user agent style and the user style (~/.dillo/style.css) > > even the first time it draws. Maybe it's because of the images that > > change the layout once loaded? > > Can you reproduce the issue with load_images=NO? > > > > I've alse seen "ghost" lines on some pages, but could never find > > the real reason. I only remeber that it depended on timing somehow. > > The issue does not appear with load_images=NO ... ie. when it only > occurs when images are loaded, and the table cells redrawn, but > apparently not rendered automatically. (Until one moves the window, > etc.) > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines.jpg > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines-gone.jpg > Can you please test this patch http://flpsed.org/tmp/ghostlines.diff It fixes the issue I could reproduce here. Cheers, Johannes

April 27, 2010

Re: style.css font-family misses redraw

by Johannes.Hofmann＠gmx.de

On Tue, Apr 27, 2010 at 12:41:09PM +0000, corvid wrote: > Johannes wrote: > > On Sun, Apr 25, 2010 at 11:35:20AM -0400, Dennis Nezic wrote: > > > On Fri, 23 Apr 2010 23:37:31 +0200, Johannes Hofmann wrote: > > > > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > > > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > > > > > > > * { font-family:sans-serif } > > > > > > > > > > And then visit a page like: > > > > > > > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > > > > > > > ... it will produce "ghost" lines from the previous rendering before > > > > > the css was applied. Moving the window, or doing anything else that > > > > > forces a redraw, cleans it up. (Let me know if you don't see this > > > > > and I can provide a screenshot.) > > > > > > > > Hm, the page does not seem to contain any CSS, so it renders with > > > > just the user agent style and the user style (~/.dillo/style.css) > > > > even the first time it draws. Maybe it's because of the images that > > > > change the layout once loaded? > > > > Can you reproduce the issue with load_images=NO? > > > > > > > > I've alse seen "ghost" lines on some pages, but could never find > > > > the real reason. I only remeber that it depended on timing somehow. > > > > > > The issue does not appear with load_images=NO ... ie. when it only > > > occurs when images are loaded, and the table cells redrawn, but > > > apparently not rendered automatically. (Until one moves the window, > > > etc.) > > > > > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines.jpg > > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines-gone.jpg > > > > Is anyone else seeing this issue on that page? It seems to work fine > > here, but I know that there is a problem, it's just hard to > > reproduce. > > Dennis: Do you know when the problem was introduced? I can now see a similar issue with this HTML fragment: <img src="http://flpsed.org/tmp/blank.gif" alt="Ico"> Name But it depends on your font settings. The point seems to be that the alt text is almost the same width as the image itself, so you might need to tweak the alt text for your font settings.

April 27, 2010

Re: style.css font-family misses redraw

by corvid＠lavabit.com

Johannes wrote: > On Sun, Apr 25, 2010 at 11:35:20AM -0400, Dennis Nezic wrote: > > On Fri, 23 Apr 2010 23:37:31 +0200, Johannes Hofmann wrote: > > > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > > > > > * { font-family:sans-serif } > > > > > > > > And then visit a page like: > > > > > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > > > > > ... it will produce "ghost" lines from the previous rendering before > > > > the css was applied. Moving the window, or doing anything else that > > > > forces a redraw, cleans it up. (Let me know if you don't see this > > > > and I can provide a screenshot.) > > > > > > Hm, the page does not seem to contain any CSS, so it renders with > > > just the user agent style and the user style (~/.dillo/style.css) > > > even the first time it draws. Maybe it's because of the images that > > > change the layout once loaded? > > > Can you reproduce the issue with load_images=NO? > > > > > > I've alse seen "ghost" lines on some pages, but could never find > > > the real reason. I only remeber that it depended on timing somehow. > > > > The issue does not appear with load_images=NO ... ie. when it only > > occurs when images are loaded, and the table cells redrawn, but > > apparently not rendered automatically. (Until one moves the window, > > etc.) > > > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines.jpg > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines-gone.jpg > > Is anyone else seeing this issue on that page? It seems to work fine > here, but I know that there is a problem, it's just hard to > reproduce. Dennis: Do you know when the problem was introduced?

April 27, 2010

Re: style.css font-family misses redraw

by Johannes.Hofmann＠gmx.de

On Sun, Apr 25, 2010 at 11:35:20AM -0400, Dennis Nezic wrote: > On Fri, 23 Apr 2010 23:37:31 +0200, Johannes Hofmann wrote: > > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > > > * { font-family:sans-serif } > > > > > > And then visit a page like: > > > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > > > ... it will produce "ghost" lines from the previous rendering before > > > the css was applied. Moving the window, or doing anything else that > > > forces a redraw, cleans it up. (Let me know if you don't see this > > > and I can provide a screenshot.) > > > > Hm, the page does not seem to contain any CSS, so it renders with > > just the user agent style and the user style (~/.dillo/style.css) > > even the first time it draws. Maybe it's because of the images that > > change the layout once loaded? > > Can you reproduce the issue with load_images=NO? > > > > I've alse seen "ghost" lines on some pages, but could never find > > the real reason. I only remeber that it depended on timing somehow. > > The issue does not appear with load_images=NO ... ie. when it only > occurs when images are loaded, and the table cells redrawn, but > apparently not rendered automatically. (Until one moves the window, > etc.) > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines.jpg > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines-gone.jpg Is anyone else seeing this issue on that page? It seems to work fine here, but I know that there is a problem, it's just hard to reproduce.

April 27, 2010

Re: style.css font-family misses redraw

by Johannes.Hofmann＠gmx.de

On Sun, Apr 25, 2010 at 11:35:20AM -0400, Dennis Nezic wrote: > On Fri, 23 Apr 2010 23:37:31 +0200, Johannes Hofmann wrote: > > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > > > * { font-family:sans-serif } > > > > > > And then visit a page like: > > > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > > > ... it will produce "ghost" lines from the previous rendering before > > > the css was applied. Moving the window, or doing anything else that > > > forces a redraw, cleans it up. (Let me know if you don't see this > > > and I can provide a screenshot.) > > > > Hm, the page does not seem to contain any CSS, so it renders with > > just the user agent style and the user style (~/.dillo/style.css) > > even the first time it draws. Maybe it's because of the images that > > change the layout once loaded? > > Can you reproduce the issue with load_images=NO? > > > > I've alse seen "ghost" lines on some pages, but could never find > > the real reason. I only remeber that it depended on timing somehow. > > The issue does not appear with load_images=NO ... ie. when it only > occurs when images are loaded, and the table cells redrawn, but > apparently not rendered automatically. (Until one moves the window, > etc.) > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines.jpg > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines-gone.jpg > I'm pretty sure it has to do with the redraw optimization. But it seems to be depending on download speed or timing somehow, as I don's see it here. I will try to find the problem, but I remember looking into a similar issue without success. Cheers, Johannes

April 26, 2010

Re: style.css font-family misses redraw

by dennisn＠dennisn.dyndns.org

On Fri, 23 Apr 2010 23:37:31 +0200, Johannes Hofmann wrote: > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > * { font-family:sans-serif } > > > > And then visit a page like: > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > ... it will produce "ghost" lines from the previous rendering before > > the css was applied. Moving the window, or doing anything else that > > forces a redraw, cleans it up. (Let me know if you don't see this > > and I can provide a screenshot.) > > Hm, the page does not seem to contain any CSS, so it renders with > just the user agent style and the user style (~/.dillo/style.css) > even the first time it draws. Maybe it's because of the images that > change the layout once loaded? > Can you reproduce the issue with load_images=NO? > > I've alse seen "ghost" lines on some pages, but could never find > the real reason. I only remeber that it depended on timing somehow. The issue does not appear with load_images=NO ... ie. when it only occurs when images are loaded, and the table cells redrawn, but apparently not rendered automatically. (Until one moves the window, etc.) http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines.jpg http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines-gone.jpg

April 25, 2010