Hi, somtimes the end of italic words get cut off e.g. in <html> <body> <i><a href="foo">FUU</a>BAR</i> </body> </html> when seen with vw_fontname="helvetica". This is due to a change in html.cc (I think it was introduced with rev 1.36). This change sets the backgroundColor for all words which means that for each word, the bounding box get's drawn before the actual text. This obviously has a performance impact too. I'm not sure how to get back to the original behaviour (backgroundColor == NULL for normal words) without breaking anything. Can someone please have a look? Cheers, Johannes
Johannes wrote:
somtimes the end of italic words get cut off e.g. in
<html> <body> <i><a href="foo">FUU</a>BAR</i> </body> </html>
when seen with vw_fontname="helvetica".
This is due to a change in html.cc (I think it was introduced with rev 1.36). This change sets the backgroundColor for all words which means that for each word, the bounding box get's drawn before the actual text. This obviously has a performance impact too.
I'm not sure how to get back to the original behaviour (backgroundColor == NULL for normal words) without breaking anything. Can someone please have a look?
I've had the idea lately (not yet explored) that maybe I could rip out all of my backgroundColor setting and get the background color for the fltk widgets if it should turn out that getEmbed()->getBgColor() has what I want. I'll dig into it. PS Is this the same reason that the tops of bold 5's are thin and the right edge of fixed-width %'s are cut off (using DejaVu fonts, at least)?
On Fri, Sep 19, 2008 at 03:05:17PM +0000, corvid wrote:
Johannes wrote:
somtimes the end of italic words get cut off e.g. in
<html> <body> <i><a href="foo">FUU</a>BAR</i> </body> </html>
when seen with vw_fontname="helvetica".
This is due to a change in html.cc (I think it was introduced with rev 1.36). This change sets the backgroundColor for all words which means that for each word, the bounding box get's drawn before the actual text. This obviously has a performance impact too.
I'm not sure how to get back to the original behaviour (backgroundColor == NULL for normal words) without breaking anything. Can someone please have a look?
I've had the idea lately (not yet explored) that maybe I could rip out all of my backgroundColor setting and get the background color for the fltk widgets if it should turn out that getEmbed()->getBgColor() has what I want. I'll dig into it.
PS Is this the same reason that the tops of bold 5's are thin and the right edge of fixed-width %'s are cut off (using DejaVu fonts, at least)?
Not sure. But you can easily check by completely disabling word backgrounds as in attached patch. Cheers, Johannes
Jorge encouraged me to add that preference in case anyone wanted it back when the, ahh, 'nonstandard' widget colors came along some months ago, but I have no idea whether anyone uses it.
On Tue, Sep 23, 2008 at 09:17:28PM +0000, corvid wrote:
Jorge encouraged me to add that preference in case anyone wanted it back when the, ahh, 'nonstandard' widget colors came along some months ago, but I have no idea whether anyone uses it.
I'm running with standard_widget_colors=NO all the time and like it. Cheers, Johannes
On Wed, Sep 24, 2008 at 04:36:48PM +0200, Johannes Hofmann wrote:
On Tue, Sep 23, 2008 at 09:17:28PM +0000, corvid wrote:
Jorge encouraged me to add that preference in case anyone wanted it back when the, ahh, 'nonstandard' widget colors came along some months ago, but I have no idea whether anyone uses it.
I'm running with standard_widget_colors=NO all the time and like it.
Me too! -- Cheers Jorge.-
On Wed, Sep 24, 2008 at 04:36:48PM +0200, Johannes Hofmann wrote:
I'm running with standard_widget_colors=NO all the time and like it.
I've been surfing with the default so I just tried switching to standard_widget_colors=YES and... I don't see much difference. What does it affect? So far I'm indifferent to it. Regards, Jeremy Henty
On Wed, Sep 24, 2008 at 06:18:02PM +0100, Jeremy Henty wrote:
On Wed, Sep 24, 2008 at 04:36:48PM +0200, Johannes Hofmann wrote:
I'm running with standard_widget_colors=NO all the time and like it.
I've been surfing with the default so I just tried switching to standard_widget_colors=YES and... I don't see much difference. What does it affect? So far I'm indifferent to it.
Check the form inputs at the top of www.freshmeat.net for example. They should have the current background color with standard_widget_colors=NO. Regards, Johannes
On Wed, Sep 24, 2008 at 07:16:16PM +0200, Johannes Hofmann wrote:
On Wed, Sep 24, 2008 at 06:18:02PM +0100, Jeremy Henty wrote:
I've been surfing with the default so I just tried switching to standard_widget_colors=YES and... I don't see much difference. What does it affect? So far I'm indifferent to it.
Check the form inputs at the top of www.freshmeat.net for example. They should have the current background color with standard_widget_colors=NO.
OK, I see. In this case I slightly prefer standard_widget_colors=YES, but I wouldn't make a fuss about it. So, I am still pretty indifferent at the moment. Are we proposing to remove this preferences option? What behaviour will we get if we do? Regards, Jeremy Henty
Jeremy wrote:
On Wed, Sep 24, 2008 at 07:16:16PM +0200, Johannes Hofmann wrote:
On Wed, Sep 24, 2008 at 06:18:02PM +0100, Jeremy Henty wrote:
I've been surfing with the default so I just tried switching to standard_widget_colors=YES and... I don't see much difference. What does it affect? So far I'm indifferent to it.
Check the form inputs at the top of www.freshmeat.net for example. They should have the current background color with standard_widget_colors=NO.
OK, I see. In this case I slightly prefer standard_widget_colors=YES, but I wouldn't make a fuss about it. So, I am still pretty indifferent at the moment. Are we proposing to remove this preferences option? What behaviour will we get if we do?
I was trying to speak neutrally so that no one would feel like they're standing in the way of anything if they prefer it. (Don't want to take care of code if it isn't being used.) So, all right, I have nothing to propose, then. [off topic: I realized yesterday that, in my mind, dillo has a three-dimensional shape. I think part of that comes from where different files appear when src/ is ls'ed. Weird.]
On Fri, Sep 19, 2008 at 04:09:44PM +0200, Johannes Hofmann wrote:
Hi,
somtimes the end of italic words get cut off e.g. in
<html> <body> <i><a href="foo">FUU</a>BAR</i> </body> </html>
when seen with vw_fontname="helvetica".
This is due to a change in html.cc (I think it was introduced with rev 1.36). This change sets the backgroundColor for all words which means that for each word, the bounding box get's drawn before the actual text. This obviously has a performance impact too.
I'm not sure how to get back to the original behaviour (backgroundColor == NULL for normal words) without breaking anything. Can someone please have a look?
I can't reproduce the problem here... -- Cheers Jorge.-
Johannes wrote:
somtimes the end of italic words get cut off e.g. in
<html> <body> <i><a href="foo">FUU</a>BAR</i> </body> </html>
when seen with vw_fontname="helvetica".
This is due to a change in html.cc (I think it was introduced with rev 1.36). This change sets the backgroundColor for all words which means that for each word, the bounding box get's drawn before the actual text. This obviously has a performance impact too.
I'm not sure how to get back to the original behaviour (backgroundColor == NULL for normal words) without breaking anything. Can someone please have a look?
This - reverts all of the style->backgroundColor to current_bg_color - sets backgroundColor for fltk widgets because NULL is already taken to mean standard_widget_colors - sets backgroundColor for image inputs and <button>s since they use a new Layout. - changes table_cell_style's backgroundColor at the bottom of Html_tag_open_tr() if the TR specifies one. I don't know why the original code didn't need that. Maybe it was broken. I wasn't feeling too sure about doing this before release, but Johannes says "currently an unnecessary XFillRectangle() command is sent to the X Server for every word" and I haven't had problems running on it so far, so it seems worthy of putting on the list for consideration. PS How do you monitor X to get an idea of what a client might be spending too much time on?
On Thu, Sep 25, 2008 at 08:25:12PM +0000, corvid wrote:
Johannes wrote:
somtimes the end of italic words get cut off e.g. in
<html> <body> <i><a href="foo">FUU</a>BAR</i> </body> </html>
when seen with vw_fontname="helvetica".
This is due to a change in html.cc (I think it was introduced with rev 1.36). This change sets the backgroundColor for all words which means that for each word, the bounding box get's drawn before the actual text. This obviously has a performance impact too.
I'm not sure how to get back to the original behaviour (backgroundColor == NULL for normal words) without breaking anything. Can someone please have a look?
This - reverts all of the style->backgroundColor to current_bg_color - sets backgroundColor for fltk widgets because NULL is already taken to mean standard_widget_colors - sets backgroundColor for image inputs and <button>s since they use a new Layout. - changes table_cell_style's backgroundColor at the bottom of Html_tag_open_tr() if the TR specifies one. I don't know why the original code didn't need that. Maybe it was broken.
Very nice! Thanks. I think this step would have become necessary anyway if we would try to support background images.
I wasn't feeling too sure about doing this before release, but Johannes says "currently an unnecessary XFillRectangle() command is sent to the X Server for every word" and I haven't had problems running on it so far, so it seems worthy of putting on the list for consideration.
PS How do you monitor X to get an idea of what a client might be spending too much time on?
I use xtrace (http://xtrace.alioth.debian.org/). In one window I call: xtrace In the other: export DISPLAY=:9 ./dillo-fltk Cheers, Johannes
On Thu, Sep 25, 2008 at 08:25:12PM +0000, corvid wrote:
Johannes wrote:
somtimes the end of italic words get cut off e.g. in
<html> <body> <i><a href="foo">FUU</a>BAR</i> </body> </html>
when seen with vw_fontname="helvetica".
This is due to a change in html.cc (I think it was introduced with rev 1.36). This change sets the backgroundColor for all words which means that for each word, the bounding box get's drawn before the actual text. This obviously has a performance impact too.
I'm not sure how to get back to the original behaviour (backgroundColor == NULL for normal words) without breaking anything. Can someone please have a look?
This - reverts all of the style->backgroundColor to current_bg_color - sets backgroundColor for fltk widgets because NULL is already taken to mean standard_widget_colors - sets backgroundColor for image inputs and <button>s since they use a new Layout. - changes table_cell_style's backgroundColor at the bottom of Html_tag_open_tr() if the TR specifies one. I don't know why the original code didn't need that. Maybe it was broken.
I wasn't feeling too sure about doing this before release, but Johannes says "currently an unnecessary XFillRectangle() command is sent to the X Server for every word" and I haven't had problems running on it so far, so it seems worthy of putting on the list for consideration.
Committed. -- Cheers Jorge.-
participants (4)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org